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

[Michael StJohns <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls