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

[Watson Ladd <[e-mail]>]

On Fri, Jun 20, 2014 at 3:11 PM, 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.

This is just a straight-up mistake: AEAD modes already protect the
plaintext length without explicitly supplying it in the form of AAD.
Omitting it solves the problem.

>
> 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
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin