Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers

From: Michael StJohns <[email-masked]>
Date: Mon, 05 May 2014 14:43:55 -0400

I never got an answer or response on the following.

Mike

On 4/29/2014 1:46 PM, Michael StJohns wrote:
> On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote:
>> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use 
>> record layer protection of type AEAD. The Editor is requested to make 
>> the appropriate changes to the draft on github.
>
> Sorry - I'm coming late here.  Does this also imply the complete 
> elimination of the integrity only cipher suites?
>
> With respect to the AEAD approach and with respect to composited AEAD 
> cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per 
> Guttman for example), does this also imply that the key expansion 
> phase will never be used to generate MAC keys, and that the cipher 
> suite has to provide whatever mechanisms that are required to split 
> the AEAD key into underlying encryption/integrity keys if required?
>
> Next (reading from the commited editors copy), this refers to 5116 
> which uses a one-size fits all approach that doesn't really fit all 
> sizes, especially for composited AEAD.  E.g.  the draft describes this 
> generally as an incrementing value.  For AEAD suites that comply with 
> 5116, that should be part of the suite specification - not TLS.  For 
> TLS, this just needs to be an normatively opaque, per-message 
> field.    Instead,  place an Informative section which recommends how 
> to do this with AEAD suites that currently exist.
>
>  And finally, as I've noted many times before, deriving IV/nonce 
> material from the master_secret at the same time as deriving keys is 
> not securely supportable in hardware.
>
>>
>> Joe
>> [For the chairs]
>> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) 
>> <[email-masked]> wrote:
>>
>>> TLS has supported a number of different cipher types for protecting 
>>> the record layer.   In TLS 1.3 these include Stream Cipher, CBC 
>>> Block Cipher and AEAD Cipher.  The construction of the CBC mode 
>>> within TLS has been shown to be flawed and stream ciphers are not 
>>> generally applicable to DTLS. Using a single mechanism for 
>>> cryptographic transforms would make security analysis easier.   AEAD 
>>> ciphers can be constructed from stream ciphers and block ciphers and 
>>> are defined as protocol independent transforms.  The consensus in 
>>> the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If 
>>> you have concerns about this decision please respond on the TLS list 
>>> by April 11, 2014.
>>>
>>> Thanks,
>>>
>>> Joe
>>> [Speaking for the TLS chairs]
>>> _______________________________________________
>>> TLS mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 6 May 2014 05:32:13 +0000

On Apr 29, 2014, at 10:46 AM, Michael StJohns <[email-masked]> wrote:

>> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github.
> 
> Sorry - I'm coming late here.  Does this also imply the complete elimination of the integrity only cipher suites?
> 

[Joe] Its possible to have AEAD modes that provide only authentication, however I don't think that the currently defined AEAD ciphers support authentication only so its possible that some modification may need to be made to support this.  

> With respect to the AEAD approach and with respect to composited AEAD cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for example), does this also imply that the key expansion phase will never be used to generate MAC keys, and that the cipher suite has to provide whatever mechanisms that are required to split the AEAD key into underlying encryption/integrity keys if required?
> 
[Joe] Yes, the cipher suite would be responsible for deriving the appropriate keys from the key material it is given. 

> Next (reading from the commited editors copy), this refers to 5116 which uses a one-size fits all approach that doesn't really fit all sizes, especially for composited AEAD. E.g.  the draft describes this generally as an incrementing value.  For AEAD suites that comply with 5116, that should be part of the suite specification - not TLS.  For TLS, this just needs to be an normatively opaque, per-message field.    Instead,  place an Informative section which recommends how to do this with AEAD suites that currently exist.
> 
[Joe] I think I'm missing your point here. I thought the existing cipher suites did define how the nonce is generated and the TLS document just provides some guidance on nonce generation.    

> And finally, as I've noted many times before, deriving IV/nonce material from the master_secret at the same time as deriving keys is not securely supportable in hardware.
> 

[Joe]  So currently with AES-GCM and AES-CCM then nonce is  partially derived from the Client and Server IV.   If I remember correctly the TLS derivation by splitting up the derived key material into secret keys and IVs is problematic.  Can this part of the problem be solved by changing the way TLS derives keys and IVs? 

>> 
>> Joe
>> [For the chairs]
>> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <[email-masked]> wrote:
>> 
>>> TLS has supported a number of different cipher types for protecting the record layer.   In TLS 1.3 these include Stream Cipher, CBC Block Cipher and AEAD Cipher. The construction of the CBC mode within TLS has been shown to be flawed and stream ciphers are not generally applicable to DTLS. Using a single mechanism for cryptographic transforms would make security analysis easier.   AEAD ciphers can be constructed from stream ciphers and block ciphers and are defined as protocol independent transforms.  The consensus in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014.
>>> 
>>> Thanks,
>>> 
>>> Joe

---

From: Rene Struik <[email-masked]>
Date: Tue, 06 May 2014 08:51:57 -0400

Hi Joe:

In general, an AEAD mode takes as input two strings a and m and a key k, 
and authenticates a and m, while encrypting m. If m is the empty string, 
this results in an authentication-only mode.

Thus, AEAD modes can be used to provide suitable combinations of 
authentication and/or encryption. Examples hereof include the GCM mode 
and CCM mode.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 6 May 2014 15:11:00 +0000

On May 6, 2014, at 5:51 AM, Rene Struik <[email-masked]> wrote:

> Hi Joe:
> 
> In general, an AEAD mode takes as input two strings a and m and a key k, and authenticates a and m, while encrypting m. If m is the empty string, this results in an authentication-only mode.
> 
> Thus, AEAD modes can be used to provide suitable combinations of authentication and/or encryption. Examples hereof include the GCM mode and CCM mode.
> 

[Joe] Yes, but I don't think any of the defined cipher suites for AES-GCM or AES-CCM support an authentication-only mode.  If authentication-only support is desired then additional cipher suites would have to be defined.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 06 May 2014 12:18:19 -0400

In line

> [Joe] Its possible to have AEAD modes that provide only authentication, however I don't think that the currently defined AEAD ciphers support authentication only so its possible that some modificat…

Actually, both CCM and GCM support authentication only.  Simply provide 
AAD and no plain or cipher text.

But what I probably should have asked was whether we were obsoleting all 
of the current integrity only suites (and I think from what I read in 
other responses the answer is yes), and if so what we were going to 
replace them with?

I don't know that CCM and GCM will be able to fill the existing niches, 
and I don't know that the composited AEAD functions make sense for this use.

> [Joe] Yes, the cipher suite would be responsible for deriving the appropriate keys from the key material it is given.

Note for action:  Provide a generic method for use with composited 
functions that's related to the way session keys are derived. 
Rationale:  KDFs are *hard* to get right.

 From the document :

> AEAD ciphers take as input a single key, a nonce, a plaintext, and 
> "additional data" to be included in the authentication check, as 
> described in Section 2.1 of [RFC5116] 
> <http://tlswg.github.io/tls13-spec/#RFC5116>. 

It's unclear to me that a composited AEAD function will always take a 
nonce.  And that the IV from one message to the next will be a simple 
increment of an IV field (e.g. if the underlying encryption mode for a 
composited AEAD function is something like CBC then the IV really needs 
to be more random).

The section in the editors draft 6.2.3.3 uses RFC5116 as its definition 
of how an AEAD cipher needs to look, and that was fine as long as there 
were other ways of looking at ciphers (stream, block), but its unclear 
this section is generic enough to deal with anything except CCM and GCM 
style AEAD ciphers.

My point with this section is to remove 5116 language, and abstract the 
hell out of the AEAD interface into something that will work with more 
than just CCM and GCM.  Or at least I believe this has to be done if all 
but AEAD ciphers are being removed.

> [Joe]  So currently with AES-GCM and AES-CCM then nonce is  partially derived from the Client and Server IV.   If I remember correctly the TLS derivation by splitting up the derived key material in…

Yup.  I've got a current draft on that.  The issue here is mostly about 
how the IV/nonce is generated as a keyed PRNG approach is problematic in 
a number of ways.

Mike

---

From: [email-masked] (Martin Rex)
Date: Tue, 6 May 2014 18:20:32 +0200 (CEST)

I can not correlate your most recent response to the prior question:

>Michael StJohns wrote:

I understand this to refer to these cipher suites:
    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };

which provide authentication PLUS integrity, but no confidentiality.

> authentication and/or encryption. Examples hereof include the GCM mode 

Now this seems to refer to an idea to provide only (initial) authentication,
but no integrity protection of the actual application data (m).

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Tue, 06 May 2014 12:24:21 -0400

> [Joe] Yes, but I don't think any of the defined cipher suites for AES-GCM or AES-CCM support an authentication-only mode.  If authentication-only support is desired then additional cipher suites wo…

If a message consists of 100 bytes of AAD and 0 bytes of plaintext, then the output of an AEAD cipher is the integrity tag over the 100 bytes of AAD and no cipher text.  That's pretty much authentication-only.

Not optimized for that though.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 06 May 2014 12:35:46 -0400

> which provide authentication PLUS integrity, but no confidentiality.

That and about 2 dozen others that are WITH_NULL.

> but no integrity protection of the actual application data (m).

Nope.  AEAD ciphers provide integrity protection across the entire 
message, plaintext and associated data.  So if the message consists only 
of associated data, that associated data data is still protected.

(m) and (a) together are the application data, not solely (m).  (m) is 
just the data to be encrypted.

Mike

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 06 May 2014 19:09:03 +0200

> If a message consists of 100 bytes of AAD and 0 bytes of plaintext, then the output of an AEAD cipher is the integrity tag over the 100 bytes of AAD and no cipher text.  That's pretty much authenti…
Sure, but as Joe said, within TLS you would need new ciphersuites for that.
While AES-GCM and AES-CCM in general can do authentication-only, in TLS
currently they can't because there is no way to include the payload in the AAD
and to send it in the clear.

Manuel.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 06 May 2014 13:16:33 -0400

> and to send it in the clear.

Ah.  Sorry - didn't understand that was the point being made.   And an 
absolutely correct one.

So the crypto is the same, but how its used by TLS would change as TLS 
currently defines what part of the message is encrypted and what part is 
AAD.  And to do that you'd have to define a variant of the current 
suites - OR - define some sort of extension to negotiate this.

*bleah*

Mike

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 06 May 2014 19:27:23 +0200

> and I don't know that the composited AEAD functions make sense for this use.
It seems to me there should be no problem defining new functions
NULL-HMAC-SHAXXX fitting the the AEAD interface (though the "E" would not really
mean encryption) that would do exactly the same as the current NULL ciphersuites.

Am I missing something?

> nonce.

Not taking a nonce can probably be seen as taking a nonce of length zero. So,
AEAD constructs without nonces would define SecurityParameters.record_iv_length
and SecurityParameters.fixed_iv_length as 0.

>  And that the IV from one message to the next will be a simple 
I may be misunderstanding the document, but I'm under the impression that
incrementing the IV (or a field inside it) is only a suggestion. More precisely:

> Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD
> operation is constructed,

seems to imply an AEAD suite can specify another method.

> but AEAD ciphers are being removed.
I agree that we should really make sure that the AEAD interface used covers all
the constructs one might want to use. But right now I don't see where more
generality would be needed.

Manuel.