Re: [TLS] #445: Enhanced New Session Ticket

[Ilari Liusvaara <[e-mail]>]

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