On 2/21/2018 3:31 PM, R du Toit wrote:

> I have analyzed the two mechanisms proposed in the draft, with
> specific focus on the impact of middleboxes. 
> *_Assumptions:_***
> The middlebox is deployed inline, between the client and the fronting
> server, and is allowed to intercept TLS sessions.  The middlebox is
> policy-driven, and uses SNI as an input in determining whether or not
> to intercept the session; the policy must use the SNI of the hidden
> server.

We may want to be a bit more specific about middlebox assumptions, both
in the draft and in your analysis.

The big question centers on your sentence "(the middlebox)  is allowed
to intercept TLS sessions". Allowed by whom, and how? SNI encryption
deployments, today, are attempting to prevent observation and
interception by middleboxes that neither the client nor the server
authorized. It is not surprising that SNI encryption would achieve just
that, in the same way that TLS succeeds in hiding the content from
intermediaries. If it doesn't, it's a bug.

> *_Mechanism #1 : Tunnel ClientHello in 0-RTT early data._***
> (1) Mechanism #1 requires 0-RTT support, but the middlebox would not
> be violating the TLS 1.3 specification by not implementing 0-RTT.  The
> middlebox intercepts all sessions destined to a specific fronting
> server (F); the identity of F should be public knowledge, but even if
> it is not, we have to assume that the middlebox has a mechanism to
> decide when to intercept sessions destined to F. 

Yes, that's a weakness in the "0-RTT tunneling" mechanism. To work
properly, it would need some kind of fallback when 0-RTT is blocked.
That needs to be taken into account when evaluating the mechanism.

> (2) Assume that the middlebox actually supports PSK and 0-RTT, i.e.
> TLS intercept with PSK/0-RTT support in the session between the client
> and the middlebox, as well as PSK/0-RTT support in the session between
> the middlebox and the fronting server.  The middlebox will be able to
> decode ClientHello#2 sent in the 0-RTT early data because the
> client_early_traffic_secret will be known to the middlebox.  The
> middlebox would thus have access to the SNI of the hidden server, and
> would be able to evaluate policy.  The middlebox would have the option
> to pull out of the session after sending ClientHello#2 to the fronting
> server (re-encrypted with the client_early_traffic_secret shared
> between the middlebox and the fronting server).
> *_Mechanism #2: Session ticket that can be decoded by Fronting and
> Hidden server._***
> (3) Mechanism #2 relies on PSK session resumption support in the
> middlebox; this is not guaranteed.
Actually, this is not specific to the session ticket solution. The 0-RTT
mechanism also relies on PSK session resumption. In your previous
paragraph, you state that "the client_early_traffic_secret will be known
to the middlebox". But that early secret is based on the PSK in a
resumption ticket with the fronting server. So in both cases, your
middlebox only works transparently if it keeps track of session tickets
and the corresponding identities and keys.

> (4) The middlebox would not participate or interfere in any of the
> out-of-band channels between the fronting server and the hidden
> server, which implies that the middlebox will not be able to decode
> the session ticket generated by the hidden server - but it does not
> have to.  The middlebox would be able to observe the encoded session
> ticket in the NewSessionTicket message because it intercepts the
> initial TLS session between the client and the hidden server (even if
> mechanism #1 is used for the first session).  The middlebox would thus
> be able to extract the SNI of the hidden server from the
> NewSessionTicket message and build a mapping of encoded session
> tickets to hidden servers. TLS sessions (destined to the fronting
> server) that were not previously intercepted by the middlebox will use
> PSK identities that are not in the mapping table - the middlebox would
> likely force intercept of those sessions and strip the unknown PSK
> identities, which would result in a TLS session that terminates on the
> fronting server, leaving the fronting server without any knowledge of
> the hidden server.

Yes, that should be the fall back mode if the middlebox strips away the
PSK identity. The client ends up with a session with the fronting
server, and the attempt to connect to the hidden server remains secret.
I agree that it should be documented in the draft.

> (5) Ignoring middleboxes, in my opinion the infrastructure required
> for collaboration between fronting servers and hidden servers
> (stateful, shared-key, public-key, or otherwise) would be a practical
> barrier to entry for most server administrators.

The way to check that is to try some test deployments. We shall see.

-- Christian Huitema
TLS mailing list

Reply via email to