-----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex Sent: Thursday, July 20, 2017 09:29 To: Russ Housley <hous...@vigilsec.com> Cc: IETF TLS <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? I'm sorry, Russ, but I think this would be seriously deceiving. Russ Housley wrote: > > 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. Any party observing the handshake (read: a monitoring middlebox) would see whether client proposed the extension and server confirmed the extension in the clear part of the TLS handshake, and that very same monitoring middlebox very very very probably would kill/prevent all TLS handshakes without that extension being confirmed by the server from completing... Just to make sure I understand the scenario: The nation state has contacted the TLS server owner and convinced/coerced them to provide contents of communications. They've decided that instead of using options 1, 2, or 3 in my earlier message (I can resend if that would help), they tell the TLS server owner that they would like them to use the extension method. If a client attempted to connect without including the extension, they would kill the connection. That seems like it protects the client from being eavesdropped, and they could discern that someone is attempting to listen. Can you expand on how this would be deceiving? ... at which point this is no longer a "rare and occasional voluntary opt-in for debugging broken apps" but rather a policy enforcment known as "coercion". It seems a middlebox owner who is both powerful and intent enough to pursue this would instead compel the TLS server owner to use options 1, 2, or 3. I am violently opposed to standardizing enfored wire-tapping for TLS. -Martin _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
