Subject: Re: [TLS] ALPN or NPN ?

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Mar 2013 05:15:15 +0000

Nico Williams <[email-masked]> writes:

>Count me as all for this, as long as it's coupled with not leaking that the
>records following the handshake are also handshake records. We could even
>have a fast second handshake that requires just half a round trip, something
>like this:
>
> - ClientHello says "I support protecting the the record type"
> - ServerHello says "I support protecting the record type", and "I support
>negotiation of application protocols (optionally: and also these
>applications: X, Y, and Z)"
> - <handshake continues and finishes>

It'd have to be quite carefully designed, if a middlebox can tell the
difference between a (short, fixed-length) Finished and a Finished+Extensions
then they can at least tell that something else is going on.  Depends on
whether we're defending against plain interception or interception+traffic
analysis (which is much harder, no matter what we decide to do).

In any case though when it was discussed the STARTTLS-style extensions-before
and extensions-after seemed to make the most send, both in terms of generality
and being able to re-use existing specs and code.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 00:52:43 -0500

> analysis (which is much harder, no matter what we decide to do).

The new thing would externally appear to have an application record type
and would appear exactly where you expect the first application record (we
could even cater to server-speaks-first (or concurrently with the client)
by having both the client and server send such a message if need be.  We
could send both, the extensions message, and any actual app data in one
record, thou after decryption we'd have two.  Then the only clue for
middleboxes would be first app record length, and in many cases this could
be handled by fragmentation or tacking on "ignore" data.

> and being able to re-use existing specs and code.

In many cases all we'll need before is both peers to state willingness to
use the new thing.  If the credentials used in the initial handshake are
good enough then a second one isn't needed, just a "I'm using app protocol
X" first message and a "OK" and I don't speak protocol X, here's what I
speak: ..." replies.

Nico
--