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

["Joseph Salowey (jsalowey)" <[e-mail]>]

On Sep 30, 2014, at 12:49 PM, Blumenthal, Uri - 0558 - MITLL <[e-mail]> wrote:

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

[Joe] I see your point, but its not within our current scope to design for this.  

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