Skip to main content

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