Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

At this point, it seems to me that both [1] and [2] solve the padding
bug, and both are straightforward to implement.

On the plus side, [2] also offers length-hiding, which is going to be
useful in TLS 1.3, when more parts of the handshake are moved to the
encrypted stage. (E.g., the size of an encrypted certificate is
usually enough to reveal the identity; or look at the NPN ad-hoc
padding strategy to protect the next protocol name).

Actually, the padding bug could also be solved by using salsa/chacha
(which I support); additionally implementing also [1] may be less
useful (redundant) in this case; implementing [2] would still inject
padding features into salsa/chacha (and AEAD), for those who need
length-hiding.

Again, if you don't care about length hiding, you don't *have to*
implement the length-hiding interface to be compliant with [2]; just
follow the data format and you're padding-bug free and interoperable
-- and you can implement length-hiding logic at a later time when your
users ask for it.

[1] http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
[2] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

Best,
Alfredo

On Wed, Sep 25, 2013 at 2:08 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Alfredo Pironti <alfredo@pironti.eu> writes:
>
>>Fix is however not too difficult: in the MAC, include the whole
>>"plaintext+padding" length, so that it can be computed directly form the
>>ciphertext length, without need to decrypt it first.
>
> Oh, I see.  It already is, in fact I'd never even considered that you could do
> it any other way, and given the results of the interop tests so far I guess
> no-one else has either.  I'll add a clarification to the draft about this.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls