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

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

On 9/30/14, 15:44 , "Joseph Salowey (jsalowey)" <[e-mail]> wrote:

>Allowing man-in-the-middle or integrity only cipher suites is not a valid
>reason to revisit the AEAD decision.  Allowing for man-in-the-middle and
>passive monitoring is in opposition to our current mandate.   As an
>aside, if this becomes a requirement in the future I don't think that
>AEAD actually limits either of these possibilities, although your choice
>of cipher may.  

The point is that in some environments the choice is BETWEEN
man-in-the-middle (currently done by many corporations via “split SSL” or
“cracked SSL”) with no security guarantees at all, and passive monitoring
where you can have at least integrity & authenticity.

AEAD with a single key (which is my preference) is incompatible with
passive monitoring unless integrity is sacrificed as well.



>On Sep 29, 2014, at 9:28 AM, Michael StJohns <[e-mail]>
>wrote:
>> Hi -
>> 
>> This isn't a proposal to change the decision to only include AEAD
>>ciphers in TLS1.3.  But something crossed my desk that suggested I
>>should at least mention a possible issue with this.
>> 
>> Background:  There are number of countries (and private networks) that
>>have a requirement to decrypt any traffic passing through certain
>>places.  There is not a corresponding requirement to allow them to
>>imitate a sender or receiver.  This can be done through key escrow,
>>LEAF-like fields or multiple encryption of the data for example.
>> 
>> Implication:  AEAD ciphers have a single key which is broken down for
>>use both in the encryption and integrity processes.  Revealing that
>>single key (to satisfy the decryption requirement) can reveal the
>>credentials to allow masquerading.  If the TLS connection credentials
>>are also being used as credentials for control actions (e.g.
>>cyber-physical controls of power systems, control over a firewall, etc),
>>fulfilling the decryption requirement provides an unintended attack
>>surface for possibly life critical systems.
>> 
>> 
>> Thoughts:  At least one AEAD cipher (CCM) uses the exact same key for
>>both integrity and encryption.  There is no way to reveal the encryption
>>key without also revealing the integrity key.  But if you have the
>>integrity key, you can masquerade as sender or receiver (controller or
>>controlled).
>> 
>> Question:  In light of the above, should we revisit the AEAD-only
>>decision for TLS1.3?
>> 
>> 
>> Question:  Is there absolutely no requirement for TLS1.3 integrity only
>>cipher suites?
>> 
>> The fallback for systems in areas that have these requirements could be
>>either TLS1.2, one of the other IETF security protocols, or something
>>proprietary.
>> 
>> And yes, this was triggered by a real-world requirement.
>> 
>> Mike
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls