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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to