Re: [TLS] Request for review: Next Protocol Negotiation Extension

[Juho Vähä-Herttua <[e-mail]>]

On 18.8.2010, at 11.42, Adam Barth wrote:
>>>> Rather than opaque<0..255>  we need defined encoded values. If not, as
>>>> someone suggested, using existing port assignments, then perhaps a
>>>> string.
>>>> These values should be assigned by IANA. There should be a convention for
>>>> private-use and experimental identifiers. The valid characters,
>>>> whitespace
>>>> rules, and the exact method of string comparison must be defined.
>>> 
>>> I believe that's how the extension works.
>> 
>> I believe in the I-D, and it says:
>> 
>>>    struct {
>>>      opaque selected_protocol<0..255>;
>>>      opaque padding<0..255>;
>>>    } NextProtocol;
>> 
>> There's no description of the contents of the selected_protocol and padding
>> elements!
> 
> Thanks for your feedback.  This looks to be an area in which we can
> improve the extension.

This is a serious concern so far, since if the selected_protocol is not very well defined, two different users of the NPN extension might be conflicting. I don't know if using the port assignments is a good idea, since there are many undocumented and conflicting port uses as well. On the other hand a string identifier just feels a bit dirty...

>>>> But if it requires a software (if not hardware) upgrade to support the
>>>> extension, wouldn't that just encourage deployments to use plain HTTP?
>>> 
>>> Plain HTTP does not support the use cases WebSockets supports.  If it
>>> did, there would be no need to invest in WebSockets.
>> 
>> I thought WebSockets could begin a handshake looking sorta like plain HTTP?
> 
> In my opinion, that handshake is garbage (to use your term).  More
> seriously, I believe we can achieve better security by using TLS+NPN
> instead of the hacky nonce/MD5 handshake that "sorta" looks like plain
> HTTP.

If that handshake is garbage, are there similar plans to "fix" the plain HTTP version of WebSockets, or is the plan that NPN would be used with TLS and the old handshake is used with HTTP? This sounds like it makes the life of WebSockets implementors a much harder, since they have to consider two completely different schemes, wouldn't it?

Since the plan of NPN is to improve the security of WebSockets, what kind of attacks it protects against, compared to simply having the HTTP style handshake negotiation inside a secure TLS connection? I understand that the protocol is much "cleaner" in a way with NPN, but in case it is to be used the earlier concerns about selecting a correct certificate based on the protocol type are valid as well. I think having the NextProtocol handshake message before the ChangeCipherSpec and using renegotiation in case the contents need to be protected could be considered.

Sorry if some questions are already answered, this is a long thread and I haven't read all the messages that carefully. I'm just trying to sum up here what I've seen so far.



Juho