IESG, OPS-DIR, TLS Chairs and Authors,







I reviewed “Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension”  (draft-ietf-tls-applayerprotoneg-03) for operational impact.







Intended Status: Standards Track




Current Draft Status: IESG - Special Request Review







Summary:  This document defines a new TLS extension identified as the “application layer protocol negotiation” (ALPN) extension.  The purpose of this extension is to permit the TLS client and server to negotiate an agreeable protocol when it may be ambiguous (i.e. utilization of a common port number for multiple upper layer protocols).  This work seems to have initial applicability to negotiation of HTTP versions (1/2), but is scoped to be used for other protocol negation.







This document would defined a TLS (RFC5246) extension .




The new extension is designed to minimize the impact on the protocol by utilizing the TLS handshake to negotiate the protocol type.  The new extension “application_layer_protocol_negotiation” is intended to minimize the network round-trips and allows the server to associate different certificates to each application layer protocol.










Summary Feedback Points:







(1) The new extension does provide new functionality which adhere to how extensions should be added to TLS.  




(2) The new extension utilizes defined behaviours in RFC5246 in terms of behaviour of client/server in the event of one not supporting the new function (RFC5247, Section 7 - TLS Handshake) which is important operationally.




(3) From an operational management perspective, this extension utilizes the existing protocol’s behaviours and functions, so no obvious issues are identified here




 




(3)  There are, however, a couple of clarifications the authors may which to address with respect to potential operational impact.  (comments on TLS WG list also point to those points, but current document does not yet reflect these changes [if changes were planned])










Operational Impact discussion/textual requirement







(1).  It appears the question of whether revealing what protocols are available may expose systems to fingerprinting and/ or other discovery.  The current security section of the document is correct in specifying that this extension itself does not impact the security of the TLS session.   The section also states that upper layer protocols were ascertained from the port number historically.  Based on list comments, it would be my opinion, that the information expose may not supply significant risk, but  a statement in the security section noting this potential (discovery) should be made (need only be 1-2 sentences).  I think it’s premature to assume what the actual risk is







(2).  Somewhat in line with the point above, there were comments on potentially scoping this specifically for the originally intended use (HTTP/1 HTTP/2).  







Resolution/addressing of these two items would help scope the operational considerations review.  That said, no specific issues  are identifiable for migration path, deployment and setup, and interoperability. 







regards,







Victor K