On Thu, Apr 28, 2016 at 10:32:52PM +0300, Ilari Liusvaara wrote: > > - The requirement for server to validate its extensions... Hopefully > there is no security reason for that... I really don't see it being > implemented correctly (and the description looks completely screwy[1]).
Thinking some more about this, I now consider such validation to be a bad idea for _any_ current extension. Take all current extensions. Drop the following categories: - Connection control (ServerHello or hint for future) - Server auth control (no server auth) - Client auth control (CertificateRequest can alter things in all sorts of ways). - Disallowed in TLS 1.3. As these categories pretty obviously don't need to match. This leaves the following: 1) use_srtp 2) heartbeat 3) token_binding 4) application_layer_protocol_negotiation 5) server_name Looking into each in turn: 1) use_srtp This extension is arguably very much connection control (it negotiates if use of TLS-EXPORTER and TLS-MUX is OK and crypto algorithms for sideband data). It does not appear to have anything to do with 0-RTT. The type of extension in TLS 1.2 is unknown (couldn't find it in the spec). Presumably connection-type. 2) heartbeat Oh yes, this infamous extension... Also arguably very much connection control (negotiates if heartbeat mechnaism can be used). The type of extension in TLS 1.2 is unknown (couldn't find it in the spec). Presumably connection-type. 3) token_binding This extension is negotiating application-layer matters (it is TLS extension only to imporove performance). It is explicitly connection- type for TLS 1.2 (so forget reusing "session cache"). Applying this extension to 0-RTT runs into obvious difficulties, and I would not be happy to see complications in base TLS to handle the mess. It isn't published RFC yet, either. 4) application_layer_protocol_negotiation This is connection-type in TLS 1.2. Also the fact that accepted 0-RTT locks the ALP, while this extension negotiates ALP is a good reason why this extension MUST NOT be allowed in presence of accepted 0-RTT. That is, the ALP of the 0-RTT context needs to become the ALP of the new connection that accepts the context without negotiation, because there is exactly one ALP that can possibly work. 5) server_name Now this is a fun one... Serverside, this is merely ACK'd, so one would have to look at client request, not server response. This also seems like that if you get some problems with 0-RTT with different SNI, you get the same problem with just PSK without 0-RTT with different SNI. To make matters more fun, this interacts with <swearing>middleboxes </swearing> that sometimes route connections based on this. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
