Re: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01

[Andrei Popov <[e-mail]>]

" So as long as you support ALPN, you MUST reply."
Here's an example: let's say a TLS server supports both ALPN and XPN extensions, each with its own set of application protocols. The server receives both ALPN and XPN extensions in the ClientHello. The server might find no matching ALPN protocol ID, but there is still hope that XPN will have a match. Or, perhaps the server prefers to use XPN for some reason. In these and similar situations, it makes sense for the server to ignore ALPN extension and give XPN a try, without terminating the handshake with a fatal alert. I would like the draft to allow this behavior.

Regarding the private namespace, I see no problem adding it if enough people want it. Would the protocol IDs in the private namespace not require IANA registration, just like those in the experimental namespace?

Renegotiation is used for multiple purposes, commonly including client auth, so I believe it is less revealing than the "hide" protocol ID. More importantly, what does the "hide" protocol ID achieve that we don't have already?

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:[e-mail]] 
Sent: Monday, July 1, 2013 11:40 PM
To: Andrei Popov
Cc: [e-mail] list
Subject: Re: Some comments about draft-ietf-tls-applayerprotoneg-01

Hi Andrei.

Inline.

On Jul 2, 2013, at 2:30 AM, Andrei Popov <[e-mail]> wrote:

> Hi Yoav,
> 
> Thanks for reviewing the draft.
> 
> Regarding the preference order of the protocol IDs, the language was intended to indicate that most of the time it makes sense for the server to choose according to the server's preferences; however an implementation may have valid reasons to ignore this and go with the client's order of preference (that's why SHOULD is used). We can change the wording, if this is not clear.
> 
> As for returning the protocol selection response, the idea is that an extension is optional, and can be ignored (e.g. when disabled, or for some implementation-specific reasons). I would rather retain this flexibility and keep MAY.

I know some documents specify behavior of implementations that have turned off the feature. But I believe an implementation with the feature disabled is not bound by the RFC. So as long as you support ALPN, you MUST reply.

> The current draft makes a distinction between IANA-registered protocol IDs and those not registered by IANA. The latter can be used privately, for experimentation, etc. We can devise a more elaborate namespace scheme if there is consensus in the WG that this would be desirable. Personally, I would rather keep it simple.

I like the idea to have private space in addition to experimental space. Let's raise this issue in Berlin (and here)

> "hide" protocol ID seems to defeat the very purpose of hiding:). Those who are interested in hiding the negotiated protocol, usually don't want the intermediaries to be able to treat different protocols differently. E.g. proxies could easily filter out traffic which includes "hide" protocol ID.

Doing an immediate renegotiation is as obvious a "tell" as a "hide" protocol. But there are many more fields that people would like to hide besides protocol. In fact, protocol is unlikely to be the secret information. Hiding a client certificate (that might have a user name) is a higher priority. We can't really hide the fact that we *are* hiding a user identity. But we can hide the identity itself, and I think that's a worthy thing to have.

> Does it make sense to include a protocol list in the renegotiation handshake? I believe it is possible that one would want to renegotiate to a different application protocol.

Renegotiation is supposed to be done to replace encryption keys, and it can be done unbeknownst to the application layer (which was the basis for the famous vulnerability from 2009). So negotiating a new protocol would be weird.


> Thanks,
> 
> Andrei