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

[Yoav Nir <[e-mail]>]

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