Re: [TLS] padding bug

[Peter Gutmann <[e-mail]>]

Brian Smith <[e-mail]> writes:

>Section 3.1. (Rehandshake Issues) seems overly complex. I think this
>extension should be connection-level, not session-level. Imagine a browser
>that contains a preference that controls whether we support the extension.
>It would be best if we could create a session with that preference set to
>one value and then resume that session with the preference set to the
>opposite value. 

Uhh, isn't that a security problem if you can rehandshake and turn EtM
off?

(I don't have much of an opinion in this area since my code doesn't do
rehandshakes because I consider them too problem-prone, but if people 
have concerns over this it'd be good to discuss them on the list.  My 
solution is just "don't do that, then").

>Section 4 (Security Considerations) would be better if it listed specific
>ways that the encrypt-then-MAC construct is currently known to be better
>than state-of-the-art (i.e. Adam's constant time) implementations of the
>MAC-then-encrypt construct, in the context of TLS's CBC cipher suites. 

I didn't do that both because it'd involve tracking down a decade's worth 
of attacks on TLS to document them, and would be out of date as soon as
the next attack on MAC-then-encrypt is published.

Peter.