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.
On Jul 20, 2017 1:04 PM, "Paul Turner" <paul.tur...@venafi.com> wrote: > > > > > *From:* TLS [mailto:tls-boun...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
