Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Harlan Lieberman-Berg writes: >Couldn't you say the same about CTR mode, or stream ciphers themselves? Yep, the KSG ciphers are all equally bad, just RC4 in another form. Microsoft, and the downstream users of its APIs, were do badly burned by this over and over again that

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Note: TLS 1.3 should significantly decrease the risk of this because the record sequence number is used as the nonce, therefore if you fail to increment the sequence number, you will quickly not interoperate with other implementations which are correct. -Ekr On Sun, Mar 20, 2016 at 12:53 PM,

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Peter Gutmann writes: > This is why I referred to GCM as "brittle", you can be about as > abusive as you like with CBC and the worst you get is degradation to > ECB, while with GCM you make one mistake and you get a catastrophic > loss of security. Couldn't you say the

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny wrote: >>provokes me to bring it up. Here's the crux of it; is it really a >>security win to recommend the AEAD cipher suites for TLS 1.2 users? I'm skeptical about the benefit of padding to 16 bytes. While it does

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 2:30 PM, Adam Langley wrote: > On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny > wrote: > >>provokes me to bring it up. Here's the crux of it; is it really a > >>security win to recommend the AEAD cipher suites for TLS

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Alexandre Anzala-Yamajako wrote: > > IMO, the layer creating the plaintext shouldn't have to pad it for security > that's the job of the TLS layer. Yep. And retrofitting random padding into TLS (all protocol versions, all PDUs) could be actually pretty simple and straightforward.

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

> I hadn't seen that! I wonder is there an appetite here for including more > robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get it > into servers and browsers sooner than TLS1.3.  H2 has padding; put it there. There is probably zero interest in adding padding to TLS

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Colm MacCárthaigh wrote: > > But I take the point that AEAD modes are harder for programmers to screw > up; and that does have value. Though it is a pretty flawed assumption. I've seen an AEAD cipher implementation fail badly just recently (resulting in corrupted plaintext that went unnoticed

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Martin Rex writes: >Though it is a pretty flawed assumption. > >I've seen an AEAD cipher implementation fail badly just recently (resulting >in corrupted plaintext that went unnoticed within TLS--MACing the ciphertext >is obviously a pretty dumb idea), something that is *MUCH* more

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny wrote: > Much better would be implementing an optional padding feature for the AEAD > modes. Something like this draft proposes: > > https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 I hadn't seen that! I