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

From: Michael StJohns <[email-masked]>
Date: Mon, 29 Sep 2014 12:28:53 -0400

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Sep 2014 11:34:58 -0500

> Question:  Is there absolutely no requirement for TLS1.3 integrity only

My strong opinion is no.  Use TLS 1.2 or earlier if that's a requirement.

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 29 Sep 2014 16:48:24 +0000

My strong opinion is yes they are required - the need that brought them into TLS 1.2- does not disappear with the upgrade to 1.3. 

I agree that the majority of the installations should not enable this option - but it would be wrong to make it completely unavailable.

(And I don't understand this crusade-ish attitude towards/against the integrity-only suites.) 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Salz, Rich [mailto:[email-masked]]
Sent: Monday, September 29, 2014 12:34 PM
To: Michael StJohns <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] AEAD only for TLS1.3 revisit

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 30 Sep 2014 19:44:52 +0000

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.  

Cheers,

Joe
On Sep 29, 2014, at 9:28 AM, Michael StJohns <[email-masked]> 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.
>

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 30 Sep 2014 19:49:34 +0000

On 9/30/14, 15:44 , "Joseph Salowey (jsalowey)" <[email-masked]> 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.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 Sep 2014 16:23:52 -0400

On 9/30/2014 3:44 PM, Joseph Salowey (jsalowey) wrote:
>   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.

It depends on the cipher mode.  Unfortunately, the 
restriction/limitation  applies to both CCM and GCM; the only "native" 
AEAD ciphers in the TLS toolchest.  For CCM, the key used for encryption 
is the same one used for integrity.  For GCM, the key used for integrity 
is CIPH[sub K](128 bits of zero) where K is the encryption key - if you 
have the encryption key, you can generate the integrity key.

The only other AEAD cipher suite we have in progress is 
https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ 
which is a constructed AEAD cipher.  That basically splits the input K 
linearly into two pieces - the HMAC and AES keys, so it would be 
possible to reveal the AES subkey without revealing the HMAC key.

So the choice of AEAD effectively limits these possibilities.  For all 
the non-AEAD suites, the integrity and encryption keys are individually 
derived.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 13:28:27 -0700

> Question:  Is there absolutely no requirement for TLS1.3 integrity only

If you believe that integrity-only modes are valuable, you could
propose an AEAD formulation that does not provide confidentiality.
That's fairly trivial to do with an AEAD construction: just move
everything under the AD part.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 30 Sep 2014 21:01:48 +0000

On Sep 30, 2014, at 1:23 PM, Michael StJohns <[email-masked]> wrote:

> It depends on the cipher mode.  Unfortunately, the restriction/limitation  applies to both CCM and GCM; the only "native" AEAD ciphers in the TLS toolchest.  For CCM, the key used for encryption is the same one used for integrity.  For GCM, the key used for integrity is CIPH[sub K](128 bits of zero) where K is the encryption key - if you have the encryption key, you can generate the integrity key.
> 
> The only other AEAD cipher suite we have in progress is https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ which is a constructed AEAD cipher.  That basically splits the input K linearly into two pieces - the HMAC and AES keys, so it would be possible to reveal the AES subkey without revealing the HMAC key.
> 
> So the choice of AEAD effectively limits these possibilities.  For all the non-AEAD suites, the integrity and encryption keys are individually derived.
> 

[Joe] Many may consider this a feature rather than a problem, however, as you state above, you can develop an AEAD ciphersuite with the properties you want.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 30 Sep 2014 21:23:37 +0000

> passive monitoring unless integrity is sacrificed as well.

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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 Sep 2014 18:19:44 -0400

> everything under the AD part.

To be a bit pedantic - that's not actually how you would do it.  TLS 
treats the user data as non-AD data.  There is no provision in the 
protocol for moving everything from encryption to AAD only.

You could define an AEAD cipher such as NULL_HMAC_SHA256_AEAD could work 
if you wanted integrity only - it's too bad we can't just use the 
existing integrity only suites.

However, if you want the ability to share the privacy key without having 
to share the integrity key (and that is a real-world need in various 
circumstances), you're currently SOL with respect to the current AEAD 
suites.

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Oct 2014 01:04:28 +0100

Hiya,

> [Joe] I see your point, but its not within our current scope to

IMO Joe is fully correct. This WG has repeatedly dealt with
proposals of many kinds for standardising MiTM attacks on TLS
and has repeatedly rejected that functionality. And should it
ever be in favour while I'm the irresponsible AD, I'll be
asking for the complete analysis of the impact of that on
the literally hundreds of other IETF specifications (not to
mention non-IETF specs and running code) that depend on TLS
and implicitly on TLS not enabling a MiTM. I've raised this
point in response to the last 3 or maybe 4 (I've lost count
sadly) proposals to MiTM TLS and have yet to get a substantive
response.

This seems to me to be just another in this series of attempts
to legitimise such MiTMs, albeit in this case as a comment on
an already establish bit of WG consensus. (The MiTM part is
the suggestion that different keys be established with those
for confidentiality being "revealed.")

Yes, I know that there are deployments that do MiTM TLS. Yes,
I know that there are some people who say that is required
for some definition of required. (There are also those who
claim doing so is anathema, so the existence of an argument
is not in itself convincing.) I would ask however that those
making the MiTM argument please set that out clearly as the
change that it would represent to current IETF consensus
documents such as RFCs 2804 and the pretty recent 7258 and
others. But first try establish IETF consensus on your MiTM
principle. That (establish the principle first) would seem
to me to be the proper order required for such a change.

S.