Require strong TLS 1.2 cipher suites for DANE secured connections

[buffrr]

We can afford to be more picky about TLS cipher suites for DANE secured connections. Go's TLS stack is for the most part on par with web browsers but we can be even more picky than web browsers and reject some weak legacy ciphers.

I was thinking of bumping min TLS version to 1.3 but this may be too aggressive since some linux distros may still use older versions of openssl/nginx. Although, sites using fancy technologies like DANE today should probably be using TLS 1.3.

For now allowing only these cipher suites for TLS 1.2 seems appropriate (as of Go 1.17 I don't think the order is important):

CipherSuites: []uint16{
    tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
    tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
    tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
    tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
    tls.TLS_AES_128_GCM_SHA256,
    tls.TLS_AES_256_GCM_SHA384,
    tls.TLS_CHACHA20_POLY1305_SHA256,
}

[brandondees]

I'm curious why order would become unimportant? Isn't the connection negotiation performed based on ordered preference?

[buffrr]

Isn't the connection negotiation performed based on ordered preference?

Correct but since Go 1.17, the TLS stack performs automatic cipher suite ordering see here for reasoning so crypto package won't care about the order that we specify.

While Config.CipherSuites still controls which TLS 1.0–1.2 cipher suites are enabled, it is not used for ordering, and Config.PreferServerCipherSuites is now ignored. Instead, crypto/tls makes all ordering decisions, based on the available cipher suites, the local hardware, and the inferred remote hardware capabilities.

letsdane will soon require Go 1.18 once its released to take advantage of some other improvements. The plan is to do this in the coming version of letsdane v0.7

[brandondees]

Thanks for the context, seems like a great choice.