Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

[Alfredo Pironti <[e-mail]>]

>
> I'm going to prepare a proposal I-D to do exactly (and only) what
> Serge Vaudenay had recommended in 2001, and what TLSv1.1 failed to fix,
> change mac-pad-encrypt into pad-mac-encrypt for the GenericBlockCipher PDU.
> When doing this, we can also consistently adopt the explicit random IV
> (which can be implemented as a random confounder) to all versions of TLS.

Please don't!
I think [1] does just what you're asking for. With 2 differences we
can agree upon:
1) Adding explicit IVs everywhere is a nice idea, and I'm up to add it
to the I-D.
2) If the paragraphs on non-GenericBlockCiphers really annoy you, just
ignore them.
To get a compliant implementation with non-block ciphers, all you have to do
is to add a 2-bytes empty vector to user data when sending, and parsing it when
receiving. All TLS implementations have a function for this, and it's
then a 2-lines patch.

>
> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

I disagree with this. The more we add SSL3-compatible hacks, the more excuses
we give to vendors and to this WG to keep using SSL3.

[1] http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01

Alfredo

>
> -Martin
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls