Re: [TLS] On the possibility of AEAD modes that require padding

[Eric Rescorla <[e-mail]>]

Daniel,

Thanks for your post:

You're right that this is an issue (which has been raised by several people
in the past). The two solutions seem to be:

- As you propose, compute the integrity tag over the padded length.

- Simply remove the length field from the additional_data on the theory
that the AEAD mode itself must verify the length (or as AGL proposed
a few minutes ago, set it to 0 for any modes which pad)

If we decide to take the second direction, we might remove the length
for any AEAD algorithms which take padding in TLS 1.2 and then remove
the length for all AEAD algorithms in TLS 1.3.

I have created a github issue to track this:
https://github.com/tlswg/tls13-spec/issues/47

-Ekr


On Fri, Jun 20, 2014 at 11:11 AM, Daniel Kahn Gillmor <[e-mail]
> wrote:

> hi IETF folks--
>
> If an AEAD mode is ever defined that must pad its input to a blocksize
> before encrypting, the current spec seems like it will break.
>
> This is a currently-theoretical concern, since (fixed authentication tag
> notwithstanding) GCM does not pad its input, and OCB and
> chacha20-poly1305 (and other AEAD modes i could find data on) also don't
> pad their input.
>
> (note that this question is independent of the various proposals for
> explicitly introducing padding into TLS, which i don't go into here)
>
> The 1.3 draft currently says:
>
> > The additional authenticated data, which we denote as additional_data, is
> > defined as follows:
> >
> >        additional_data = seq_num + TLSPlaintext.type +
> >                          TLSPlaintext.version + TLSPlaintext.length;
> >
> > where "+" denotes concatenation.
> >
> > The aead_output consists of the ciphertext output by the AEAD encryption
> > operation. The length will generally be larger than TLSPlaintext.length,
> but
> > by an amount that varies with the AEAD cipher. Since the ciphers might
> > incorporate padding, the amount of overhead could vary with different
> > TLSPlaintext.length values. Each AEAD cipher MUST NOT produce an
> expansion of
> > greater than 1024 bytes.
>
> It goes on to define AEAD-Decrypt this way:
>
> >       TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce,
> >                                            AEADEncrypted,
> >                                            additional_data)
>
> Consider the decryption step.  The decryptor knows:
>
>  * the AEAD mode (including the taglength)
>  * the nonce
>  * the write key
>  * the sequence number
>  * the record type
>  * the TLS version
>  * the ciphertext (including its length)
>
> To create additional_data, it must be able to derive TLSPlaintext.length
> From the above information.
>
> All the AEAD modes i know about have a ciphertext expansion of a
> fixed-length tag.  so:
>
>  TLSPlaintext.length = TLSCiphertext.length - AEADmode.taglength
>
> But if an AEAD mode were to additionally pad its input ("Since the
> ciphers might incorporate padding, the amount of overhead could vary
> with different TLSPlaintext.length values"), there would be no clear way
> to derive additional_data because the length of the plaintext is unknown
> before doing the decryption.
>
> So i think the fix is to specify that additional_data should be derived
> From the padded length of the TLSPlaintext.fragment, not from
> TLSPlaintext.length.  For GCM (and other AEAD modes i know of) these
> values are of course identical.
>
> Making this explicit seems like it would require a bit of gymnastics in
> the spec, all for the sake of holding open the door for future modes
> with variable-length ciphertext expansion.  I can try to make a patch
> for this change, but i want to know if we think it's necessary.
>
> Alternately, we could decide that we won't accept modes that require
> this kind of padding (maybe stripping out the sentence about "might
> incorporate padding").
>
> Have i missed an obvious solution or misunderstood the situation?  What
> do people think we should do here?
>
>      --dkg
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>