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

[Manuel Pégourié-Gonnard <[e-mail]>]

On 06/05/2014 18:18, Michael StJohns wrote:
> 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.
> 
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?

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

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

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