Re: [TLS] Is there a way forward after today's hum?

Paul, the reason to use the MiTM approach rather than simply hacking the
endpoint the attacker controls is that it may be much more convenient to be
running out-of-the-box software on the endpoint.   The MiTM isn't an
attacker from the perspective of the controlled endpoint; it is simply a
convenient way to conceal what is being done.

Having thought about it some more, as Russ points out, it might be too
expensive to be worth doing, because you'd have to hack the whole stream.
It would not, for example, be a useful passive attack, obviously.

That said, suppose this extension were added to everyone's TLS libraries.
Now the number of lines of code I'd have to #ifdef out to avoid setting the
evil bit would be much less than if it weren't.

On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner <PAUL.TURNER@venafi.com> wrote:

>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 07:25
> *To:* Paul Turner <PAUL.TURNER@venafi.com>
> *Cc:* Robin Wilton <wilton@isoc.org>; <tls@ietf.org> <tls@ietf.org>
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Paul, it would be trivial to normal that exchange to conceal from the
> client that a static key is being used. No software mods required on either
> end: just in the middle.
>
>
>
> Thanks, Ted. Can you expand on this?
>
>
>
> Also, can you also put it in the context of a threat model as Robin
> suggested? I’ve suggested some things below but may not have it right. Why
> would the attacker take this approach versus some of the readily available
> methods?
>
>
>
> Paul
>
>
>
> On Jul 20, 2017 1:04 PM, "Paul Turner" <PAUL.TURNER@venafi.com> wrote:
>
>
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Robin Wilton
> *Sent:* Thursday, July 20, 2017 05:58
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> Apologies for not replying "in thread" on this occasion, for noob
> reasons... but here's the specific comment from Russ that I wanted to
> respond to:
>
>
> ------------------------------
>
> The hum told us that the room was roughly evenly split.  In hind sight, I wish the chairs had asked a second question.  If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking.
>
>
>
> If a specification were available that used an extension that involved both the client and the server, would the working group adopt it, work on it, and publish it as an RFC?
>
>
>
> I was listening very carefully to the comments made by people in line.  Clearly some people would hum for "no" to the above question, but it sounded like many felt that this would be a significant difference.  It would ensure that both server and client explicitly opt-in, and any party observing the handshake could see the extension was included or not.
>
>
>
> Russ
>
> ====
>
>
>
> Stephen Farrell articulated a concern with that approach - namely, that if
> we are relying on a setting that is meant to ensure both parties must be
> aware that static DH is in use, then a bad actor would find ways to
> suppress that notification. In your proposal, Russ, the notification
> mechanism would take the form of an extension... so I think we would need
> to understand what the failsafe is, for instance if that extension is
> disabled, or not present, in a given deployment of TLS.
>
>
>
> There's an implicit assumption about the threat model, too, which I just
> want to call out. The assumption is that a bad actor would suppress the
> notification so that the client is not aware that static DH is in use. For
> completeness, should we also consider whether there are attacks in which
> it's the *server* whose notification is suppressed? (I can't think of such
> an attack, off the top of my head, but then, that's probably why I'm not a
> hacker. ;^, )
>
>
>
> Best wishes,
>
> Robin
>
>
>
> Robin,
>
>
>
> With respect to your threat concerns, can you be more clear about the
> threats you’re considering? Here are a few things that come to mind:
>
>
>
> 1.     TLS Server has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to the
> TLS client. This seems true TLS 1.3 today.
>
> 2.     TLS Server has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS client.
> This seems true with TLS 1.3 today.
>
> 3.     TLS Server can create a TLS server implementation that uses static
> DH keys and provide them to a third party. The client can use methods to
> detect this (though there are measures and countermeasures here). This is
> true seems TLS 1.3 today.
>
> 4.     TLS Client has all of the decrypted data and can provide that to a
> third party (whether compelled or otherwise) without any indication to the
> TLS server. This seems true in TLS 1.3 today.
>
> 5.     TLS Client has their ephemeral DH keys and session keys and can
> provide them to a third party without any indication to the TLS server.
> This seems true with TLS 1.3 today.
>
>
>
> I believe Russ was outlining a method where an extension would be added to
> TLS 1.3 that would provide for delivery of a decryption key to a third
> party during the handshake (correct me if I got that wrong, Russ). Because
> it would be during the handshake, it would seem to be visible to the TLS
> Client—in fact, the client would have to include the extension to begin
> with. If the TLS client saw the extension and did not consent, it could
> abort the connection. If the TLS Server were attempting to provide access
> to the exchanged data to a third party, it would seem they could use 1, 2,
> or 3 above and not have to go to the trouble of attempting to subvert the
> mechanism that Russ proposes (and others have previously proposed).
>
>
>
> Can you clarify?
>
>
>
> Paul
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>