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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 01 Oct 2014 09:32:45 +0200

On Tue, 2014-09-30 at 18:19 -0400, Michael StJohns wrote:
> On 9/30/2014 4:28 PM, Martin Thomson wrote:
> > On 29 September 2014 09:28, Michael StJohns <[email-masked]> wrote:
> >> Question:  Is there absolutely no requirement for TLS1.3 integrity only
> >> cipher suites?
> > 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.
> 
> 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.

It's not simply too bad, it is unnecessary work, and additional bloat
to implementations which will have to carry two versions of the same
ciphersuite. One that is valid for TLS 1.2 and prior, and another that
will be valid for TLS 1.3 and later. Since SSL 3.0 is yet still in use
we can expect this duplication (of code and bugs) to last at least 15
years. The benefit of this duplication is some "niceness" that will be
observed in the TLS 1.3 protocol as everything will be marked as AEAD,
but this "niceness" has no cryptographic value (the TLS 1.2 construction
with cipher and MAC is authenticated encryption).

Hence, instead of simplifying implementations, the AEAD-only move will
add more code into implementations, duplicate code, increasing the
number of potential bugs, and adding no value.

regards,
Nikos

---

From: Michael StJohns <[email-masked]>
Date: Wed, 01 Oct 2014 12:36:21 -0400

On 9/30/2014 8:04 PM, Stephen Farrell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hiya,
>
> On 30/09/14 22:23, Joseph Salowey (jsalowey) wrote:
>> [Joe] I see your point, but its not within our current scope to
>> design for this.
> 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.

Hi Stephen -

Sorry, but this is a complete mis-statement of the problem.

1) There are places where "someone" requires the disclosure of the 
confidentiality key of traffic transiting a specific network, or point.  
That's just reality.  How that is done is not a TLS protocol issue.

2) _*Nowhere in any of the emails (or at least the in the email thread 
started by me) has there been a suggestion to "standardize MiTM attacks 
on TLS" .*__*  This is somewhat fear mongering.*_

3) TLS1.3 has exacerbated the problem of (1) by specifying AEAD as its 
sole cryptographic model because of:
      a) There are no viable integrity only AEAD cipher suites defined 
which could be used to satisfy (1)
      b) Since the only defined AEAD cipher suites couple the integrity 
key with the encryption key, it is impossible to reveal only the 
encryption key (thereby defeating the principle of least privilege).  
E.g. the command key is shared by more than two entities.

4) In a number of TLS cases that I'm aware of, the most important 
characteristic is mutual authentication (or at least sender/controller 
authentication), as TLS is used as a bearer service for command and 
control.  Confidentiality is simply a "nice to have".   That's the 
observed characteristic for most of the smart grid stuff, and I would 
expect that it will be similar for most of the IoT stuff.

The key piece here is that using TLS1.3 actually weakens the security 
guarantees (protection of the control channel) given the real world 
constraints of confidentiality key escrow/release.  For me this was an 
"unintended consequence" of the AEAD decision and one I didn't realize 
until I encountered a new requirement for (1).

Note:  I think (1) is a bad choice in pretty much all cases, but that I 
don't get to decide that, I just have to design systems that can be sold 
to customers that require it.

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

The implication that "different keys be established" is something new in 
TLS is absurd.  TLS1.3 makes changes that remove functionality and 
capabilities that have been in the protocol from the beginning.  Making 
sure that the "unintended consequences" from those removals are actually 
intended seems to me to be no more than due diligence.

As I said in my original message, the default for designers is going to 
be to fall back to TLS1.2, or use other IETF security protocols or build 
a proprietary protocol for such designs.  That may be just fine.

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

What "change" are you talking about?

By the way, RFC 7258 - you mention it above -  has this:
>   Making
>     networks unmanageable to mitigate PM is not an acceptable outcome,
>     but ignoring PM would go against the consensus documented here.  An
>     appropriate balance will emerge over time as real instances of this
>     tension are considered.
This is somewhat different than considering all concerns resolved as you 
seem to imply above.

 From the customer's POV, (1) above is both a network management issue 
and possibly a legal compliance issue.  They may own the network, and 
the traffic transiting it may mostly be machine-to-machine.  The issues 
you (since you wrote 7258) raised with respect to PM are not broadly 
applicable to the privacy of a light switch or a sluice dam.  I'd say 
that counts as a "real instance".

I asked two questions in my original email:
> 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 primary decision to remove AEAD was NOT because it made passive 
monitoring more difficult, but because it simplified the design of the 
protocol AND ensured proper integrity protection over records. The 
integrity only suites were a mostly unmourned casualty of that decision.

  I'm not aware of any earlier discussion on the subject I raised in 
this thread.   I'm also not aware that anyone has proposed a change - 
we're just talking here to figure out whether or not we missed something 
critical in making that decision.

So what exactly is the problem with this discussion?

Mike

>
> S.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUK0UMAAoJEC88hzaAX42ikfUIAJxdIBnNfQaZWjczMiz68Jsw
> +LUzR4xsPn4nosJAsUWoGEOQI6yP8aj90qPdYMEF5tYORVtdhrDtfjy9Lkl25884
> 9xep6ug86ya0JHlWmVdcjfH1gg9MIFw0MgH8XqENagCcYzXfpoCmJ6njVwimqROS
> ZuZnTV+Fa9Offx95d3eZUY1fbe9kAPD18ClXry9J0CbDxxeKWumTLIz/egSGNv1q
> kFokSJbyRmmzMBEVlUb/iY+Hx8zbqSnwR0n+BiyKIrvWiUn3ZWw5KT9HVoFuBZZS
> 4czdFaWp9//J7GdJGZg5xz5LLBzeBB6VlFjjVNwiHXoFjswJBjgEuOf5yJQPEEQ=
> =k+r4
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Oct 2014 11:47:57 -0500

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: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Michael StJohns <[email-masked]>
Date: Wed, 01 Oct 2014 13:13:14 -0400

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”?
>
> -- 
>
> IM: [email-masked] <mailto:[email-masked]> 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).

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

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 1 Oct 2014 10:36:39 -0700 (PDT)

Hi Mike,

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 1 Oct 2014 20:57:47 +0300

On Wed, Oct 01, 2014 at 01:13:14PM -0400, Michael StJohns wrote:
> 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).

Actually isolating integrity key from encryption key would require two
MACs, with inner one inner to encryption and with its own subkey.

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

What's the problem? It seems that hashing the early handshake is easy
enough (and there ARE attacks without this).

Is this something about hashing in the "identities" or something like
that?

-Ilari

---

From: Michael StJohns <[email-masked]>
Date: Wed, 01 Oct 2014 14:15:39 -0400

>    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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Oct 2014 13:30:41 -0500

Stick with TLS 1.2 The new version doesn't meet the customer needs.  Stick with the old one. Yes, some customers will be upset at not being able to use the absolute latest standard. I'm not unsympathetic to that feeling, but my empathy only goes so far. :) 
--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz