Re: [TLS] AEAD only for TLS1.3 revisit

On 10/1/2014 1:36 PM, Dan Harkins wrote:
>    Hi Mike,
Hi Dan -

The issue I'm describing is not intractable, just inelegant. There's 
about 100 different ways of solving it, but most require new TLS1.3 
cipher suites.  SIV is a possibility, McGrew's draft is a better 
possibility simply because its further along.  Any AEAD mode with key 
diversity is a candidate. Or we can stick with TLS1.2 or IPSEC  or build 
our own.   All are more work than just being able to grab an already 
existing key.

Mike

> On Wed, October 1, 2014 10:13 am, Michael StJohns wrote:
>> On 10/1/2014 12:47 PM, Salz, Rich wrote:
>>> I don’t understand why you can’t sell those customers TLS 1.2.
>>>
>>> Algebraically, I view
>>>
>>> TLS 1.3 = TLS 1.2 + various_predefined_extensions –
>>> some_crypto_mechanisms + epsilon
>>>
>>> Is there something so important in that epsilon? Or is it just a case
>>> of “we must have the latest”?
>>>
>>> --
>>>
>>> Principal Security Engineer, Akamai Technologies
>>>
>>> IM: rsalz@jabber.me <mailto:rsalz@jabber.me> Twitter: RichSalz
>>>
>> Hi Rich -
>>
>> TLS1.0 and 1.1 are "obsolete" for some value of obsolete.  Once TLS1.3
>> is published, TLS1.2 will also be obsolete.  That's as much reality as
>> marketing and that causes problems with customers doing check box
>> requirements.  They say "TLS" and they mean "TLS, the latest and
>> greatest" and explaining why you're offering TLS1.2 becomes a painful
>> and sometimes business losing proposition.
>>
>> In your equation above, with respect to this thread only, the actual
>> problem is not the " + epsilon" but the "- some_crypto_mechanisms" which
>> took away all the mechanisms where the integrity key can be isolated
>> from the encryption key.  Trying to define new AEAD mechanisms that
>> provide this capability *AND* make it in to sufficient commercial stacks
>> becomes an interesting problem (and frankly a great deal of work in
>> TLS1.3 that's not necessary in TLS1.2).
>    Such an AEAD mechanism has already been defined. RFC 5297
> specifies AES in SIV mode. SIV takes a single key but it is of the "double
> wide" variety where the first half is for the integrity check key and the
> second half is the encryption key. So it's possible to isolate one half
> from the other assuming that the PRF that generated the double wide
> key prevents inferring anything about the first half from knowledge
> of the second half (I believe that will be the case for TLS 1.3).
>
>    SIV is a perfectly valid AEAD mechanism and is part of the RFC 5116
> registry. You'd just need to specify it as a TLS1.3 cipher suite.
>
>    It would be very regrettable if SIV became known as the "escrowed
> AEAD mode" especially as it has other highly desirable properties, like not
> requiring a counter and being robust in the presence of counter misuse,
> if one is provided. On the other hand, it's likely that the people requiring
> this kind of snooping are some of the very same people that really dislike
> SIV mode (and oppose its adoption in standards) so maybe this would be
> justice of the poetic kind.
>
>    Be that as it may, I think SIV solves your problem.
>
>    regards,
>
>    Dan.
>
>> We may end up with TLS1.2, or with another IETF security protocol
>> (IPSEC?) or even with something proprietary.
>>
>> The discussion really is about how we're making a number of structural
>> changes to TLS in the TLS1.3 draft.  Some of them have interesting and
>> possibly unintended consequences (cf the discussion on encrypting the
>> handshake with respect to encrypting the SNI extension; or the
>> discussion about doing the hash of the handshake mixin with key
>> derivation interacting badly with the desire for 1rtt); this particular
>> change had an unintended consequence that didn't come to light (at least
>> for me) until I got a specific request and tried to figure out how to
>> satisfy it.
>>
>> Later, Mike
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>