Conversation

I think I've had enough of cipher suites for a while. The good news is that no one using Go will ever have to think about cipher suite ordering again, because we take care of it now! go-review.googlesource.com/c/go/+/314609/

Lines 217 to 269 of the linked CL file, showing a list of rules for sorting cipher suites.

read image description

ALT

254

Filippo Valsorda

@FiloSottile

Apr 28, 2021

Oh hey, what a coincidence

Quote Tweet

Blink: Intent to Remove: 3DES in TLS groups.google.com/a/chromium.org

Filippo Valsorda

@FiloSottile

Apr 28, 2021

No one liked my "lower means it comes earlier in the preference list" notation, which worked great with sorting algorithms, but not with humans 😅 So here's Patch Set 2 with better language! go-review.googlesource.com/c/go/+/314609/

The updated sorting list that uses "comes before" instead of "<"

read image description

ALT

Replying to

I don't understand the comment about CBC_SHA256 having no Lucky13 countermeasures. Is that an implementation choice in Go, or is there something I'm missing about countermeasures not being possible with SHA256?

Replying to

and

Implementation choice, AFAIK. IIRC agl wrote that cipher suites are not pokemon, you don't need them all, CBC are needed for compatibility with older non-AEAD software, use the older CBC-SHA1 for that. CBC-SHA2 are kinda pointless since HMAC-SHA1 is not broken.

Replying to

and

The comment doesn't make that clear, and the links given as references don't explain it either. Also, if there's a choice not to implement a necessary countermeasure for a given ciphersuite, shouldn't it be ripped out of the code? Why leave the hazard lying around?

Replying to

and

I think because it's not a very practical attack and some people need the compatibility to talk to some legacy services. Software that connects to modern things can use PFS+AEAD only. Changing the default for which cipher suites are allowed is probably a major change.

Replying to

and

In situations where modern AEAD ciphers are available, none of this is relevant. My point here is that the comment as written is confusing and possibly misleading, and should come with stronger "we left a known hazard in here by choice and you should know about it" language.

Replying to

and

Also while I'm complaining, not everything that has AES hardware has Galois-field multiplication instructions. It sure would be nice to see the TLS 1.3 CCM suites supported in more places.

Replying to

and

ChaCha12 has a higher security margin than AES256 and would be the best fit for most of those devices. It's as fast as hardware AES on most server hardware too. There might as well be a mandatory cipher suite based on it. Once you have ChaCha20 and Poly1305 you've done the work.

11:40 PM · Apr 28, 2021Twitter Web App

Replying to

Even low-end, 32-bit Android devices don't have hardware AES. GCM isn't the only issue. en.wikipedia.org/wiki/Adiantum_ is how disk encryption is provided on those now. Smaller embedded devices have the same problem. It's even less likely those get hardware AES any time soon.

en.wikipedia.org

Adiantum (cipher) - Wikipedia

Replying to

and

ChaCha12 isn’t in a standard cipher suite yet, and I’ve certainly got a bunch of smaller embedded devices I’m working with that have AES but nothing else... (I’ll avoid invoking CAVP in this conversation but that’s certainly another common blocker to ChaCha suites)

Show replies