Re: [TLS] Next Protocol Negotiation 03

[Marsh Ray <[e-mail]>]

On 04/25/2012 08:09 AM, Adam Langley wrote:
>
> We're also looking at other extensions, for example encrypted client
> certs[1] (which have been suggested by others too), that also involve
> encrypted handshake messages. So that state machine change may be be
> useful for a range of needs.

So if we are going to change the state machine in a generally more 
useful way, why not make the change more general?

I.e., instead of

> struct {
>      opaque selected_protocol<0..255>;
>      opaque padding<0..255>;
>    } NextProtocol;

We could define something closely analogous to a Hello message extension 
area, records sent immediately after the CCS in their respective directions:

struct {
     Extension extensions<0..2^16-1>;
} ClientAdditionalExtensions;
struct {
     Extension extensions<0..2^16-1>;
} ServerAdditionalExtensions;

thus re-using the definition of 'Extension' from RFC 5246.

The use of these ClientServerAdditionalExtensions record could be 
negotiated with (what else?) a new extension. We could call it the 
AdditionalExtensionsNegotiationExtension, but maybe there's a better 
name. I envision this extension could be sent on the Client Hello and 
replied to on the Server Hello if this feature is negotiated.

We could define this Client Hello extension to be empty, or it might be 
useful to have it list the ExtensionTypes for which the actual data will 
be sent in the CAE and those for which the reply is required to be sent 
in the SAE record after the CCS.

The extension sent in reply on the Server Hello reply would indicate the 
feature was negotiated successfully. It could list the ExtensionTypes 
for which the use of was negotiated successfully, but the actual reply 
payload will be found in the SAE after the CCS.

There are considerations for resumed handshakes because the server CCS 
comes before the client CCS. But there are already such considerations: 
"Most current TLS extensions are relevant only when a session is 
initiated: when an older session is resumed, the server does not process 
these extensions in Client Hello, and does not include them in Server 
Hello.  However, some extensions may specify different behavior during 
session resumption." [RFC5246]

This would enable implementors to take the pain of modifying their state 
machines once while also enabling other extensions to benefit from the 
privacy enhancement.

Thus, the definition of next_protocol remains nearly the same, except 
that it is now the "extension data" field of a proper 
next_protocol_negotiation type extension.

We'd have to decide which (if any) of the currently defined extension 
types should be considered incompatible with this new feature, but it 
seems like most would transition smoothly. Few current extensions seem 
to affect handshake messages between the Hellos and the CCS. Nor does it 
seem likely that many will specify different behavior during session 
resumption."

- Marsh