Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
draft-ietf-tls-applayerprotoneg-05
Yes
(Richard Barnes)
(Sean Turner)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Spencer Dawkins)
(Stewart Bryant)
(Ted Lemon)
Note: This ballot was opened for revision 04 and is now closed.
Richard Barnes Former IESG member
Yes
Yes
(for -04)
Unknown
Sean Turner Former IESG member
Yes
Yes
(for -04)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2014-02-04 for -04)
Unknown
These are pretty nitty comments mostly, but not quite entirely:-) - abstract: this is slightly wrong - the main use case here is HTTP/2.0 over port 443. That *is* the right port associated with HTTP. s/not associated/possibly not associated/ might be a good change. - Intro: "virtually the entire global" is marketing and could change quickly if middleboxes start snarfing ALPN - Intro: certificate selection at the host level can be done with SNI, I'd not mention that I think unless you want to add "in a more fine-grained manner than can be done with SNI [RFC6066]" or similar. - 3.1: The last para there is not very clear unless you have TLS stuff at the front of your brain. I'd suggest a sentence or two more to explain it might be useful and help developers do the right thing. For example, I think this means that you MUST re-do the ALPN dance on session resumption, but that is not clearly stated by just saying "only of the connection." - 3.2: Does the last sentence there mean that e.g. Tor will likely want to not conform to that "SHALL NOT"? I can well imagine them wanting to tell white lies about the protocol in use. Was that considered? (Note: I'm not asking to change the SHALL NOT.) - 4: The "typical design" phrase here contrasts with the "unlike many other" phrase in 3.1. Maybe consider a tweak? - 4: I think it'd be more clear and more correct to just say that encrypted ALPN was judged too big a change for TLS1.2 when TLS1.3 was being started since we plan to support encrypted ALPN in TLS1.3. - 5, 2nd para: suggest s/browsers/some browsers/ - 5: It could be worth saying that simple traffic analysis would in any case easily detect many protocols that encrypted ALPN would attempt to hide, e.g. HTTP/1.1's verbose binary cookie-laden requests vs. HTTP/2.0's binary stuff.
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-02-05 for -04)
Unknown
Seems reasonable to me. Nit: The ToC is missing page numbers.
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2014-02-02 for -04)
Unknown
Finally, by managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence with respect to the ability to hide the negotiated protocol in advance of establishing the connection. If hiding the protocol is required, then renegotiation after connection establishment, which would provide true TLS security guarantees, would be a preferred methodology. I think the writeup actually adds a little missing color. The main point of controversy with this document was on encryption of the extension. The working group decided a cleartext extension with the future general facility to encrypt extensions in TLS 1.3 was preferable to an extension specific encryption mechanism for ALPN. which might be appropiate for the security considerations section.
Martin Stiemerling Former IESG member
No Objection
No Objection
(2014-02-04 for -04)
Unknown
A nit (in multiple places): It is not "TCP/IP port number", but only "TCP port number".
Pete Resnick Former IESG member
No Objection
No Objection
(2014-02-05 for -04)
Unknown
I am afraid that some of the normative language in this document would require you to make this an update to 5246, and I don't think that's what you mean to do. Other normative language is just confusing. Without explaining bit-by-bit, I suggest below some changes that I think clarify and do not change the meaning at all. I am happy to explain if asked. There's a lot of text here, but really most of it is only 8 minor textual changes. Other questions inline: 3.1 OLD is defined and MAY be included by the client in its "ClientHello" NEW is defined and can be included by the client in its "ClientHello" END OLD ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value. NEW ("application_layer_protocol_negotiation(16)") extension contains a "ProtocolNameList" value. END (I'm assuming you don't really mean the above as a restriction. Otherwise, you would say: NEW ("application_layer_protocol_negotiation(16)") extension SHALL NOT contain an unregistered "ProtocolNameList" value, as defined below. END I don't think that's what you meant.) OLD Implementations MUST ensure that an empty string is not included and that no byte strings are truncated. NEW Empty strings MUST NOT be included and byte strings MUST NOT be truncated. END (But actually, I don't understand the second part: What does it mean for a byte string to be truncated in this context?) OLD Servers that receive a client hello containing the "application_layer_protocol_negotiation" extension, MAY return a suitable protocol selection response to the client. The server will ignore any protocol name that it does not recognize. A new ServerHello extension type ("application_layer_protocol_negotiation(16)") MAY be returned to the client within the extended ServerHello message. This one I'm actually not clear on. Are those really OPTIONAL? What else would I do as a server? Shouldn't it be: NEW Servers that receive a client hello containing the "application_layer_protocol_negotiation" extension will return a suitable protocol selection response to the client. The server will ignore any protocol name that it does not recognize. A new ServerHello extension type ("application_layer_protocol_negotiation(16)") is returned to the client within the extended ServerHello message. END OLD field of the ("application_layer_protocol_negotiation(16)") extension SHALL be structured the same as described above for the client NEW field of the ("application_layer_protocol_negotiation(16)") extension is structured the same as described above for the client END 3.2: It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. Not having to do with the normative language: It took me a bit to figure out the use case here. It might be nice to include, "For instance, a server might support several different versions of SPDY, and will select the highest version that the client supports." OLD In that case, the server SHOULD select the most highly preferred protocol it supports which is also advertised by the client. NEW The server selects the most highly preferred protocol it supports which is also advertised by the client. END OLD client advertises, then the server SHALL respond with a fatal NEW client advertises, then the server responds with a fatal END OLD The "no_application_protocol" fatal alert is only defined for the "application_layer_protocol_negotiation" extension and MUST NOT be sent unless the server has received a ClientHello message containing this extension. This one really sounds like you're trying to constrain other protocols and *is* an update to 5246. I think you should just strike this. What do you care if a different protocol finds a good use for that alert? OLD ServerHello SHALL be definitive for the connection, until renegotiated. NEW ServerHello is definitive for the connection, until renegotiated. END
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(for -04)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -04)
Unknown