Re: [TLS] Some missing context

Hums were taken on ALPN or NPN.  After everybody chuckled about it being 
close.  I agreed with Joe that there was a discernible preference for ALPN.

I guess the next bit is where we differ.  I think a show of hands is 
just another method the WG chairs can use to determine rough consensus, 
as documented in RFC 2818.  Sure I counted 'em but just standing there 
looking at the room it was a clear 2/1 ratio for ALPN and that I'd argue 
that was rough consensus in the room.

Then, the chairs took it to the list to confirm it on the list.

spt

On 3/15/13 7:46 PM, Yoav Nir wrote:
> Hi
>
> I think some of the people who were not in the room are missing the context for this decision.
>
> Both NPN and ALPN accomplish the same thing. It is to negotiate the application level protocol that is going to run on top of TLS. Currently such negotiation is planned to distinguish between HTTP/1, HTTP/2, and draft versions of HTTP/2, but future applications may use this for other protocols (such as SSL-VPN tunneling clients)
>
> The difference between them, is that in ALPN the client proposes a list of applications, and the server chooses - all in the clear. With NPN, the server advertises a list of applications in the clear, while the client picks one after the CCS - in an encrypted handshake record.
>
> There is no question that adding NPN to an existing implementation of TLS requires more lines of code.
>
> Concerns were raised that middleware might block connections when it doesn't like the application chosen by the server in ALPN. With NPN, middleware that is not a full TLS proxy won't know just by looking at the handshake which protocol was chosen.
>
> At the meeting there was no rough consensus for either proposal. There was, however, rough consensus that making either decision is better than not making a decision. As someone (Sean?) put it, "deciding is more important than winning". This was also the position of the proponents of both proposals. Given this, we went to an alternate means of making the decision (although one that was not described in RFC 3929) and voted. The result was 25:!2 in favor of ALPN.
>
> There was also some discussion on the need to encrypt significant parts of the TLS handshake. This was viewed as orthogonal (no need to encrypt this particular piece of data, when other, more sensitive things are still sent in the clear) and may or may not be taken up by the group separately.
>
> I hope this helps those who were not in the room respond to Ekr's call.
>
> Yoav
>
> On Mar 15, 2013, at 5:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> At today's TLS WG f2f meeting we had rough consensus to adopt
>> ALPN as the solution to the upper-layer protocol negotiation problem
>> posed to us by the HTTP WG.
>>
>> if you have an opinion on this topic and were not at the meeting,
>> please send a message to the mailing list and/or the chairs by
>> Friday March 29.
>>
>> -Ekr
>> [For the chairs]
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>