Skip to main content

Last Call Review of draft-ietf-tls-applayerprotoneg-03
review-ietf-tls-applayerprotoneg-03-opsdir-lc-kuarsingh-2013-12-30-00

Request Review of draft-ietf-tls-applayerprotoneg
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2013-12-27
Requested 2013-12-18
Authors Stephan Friedl, Andrei Popov , Adam Langley , Stephan Emile
I-D last updated 2013-12-30
Completed reviews Genart Last Call review of -03 by Joel M. Halpern (diff)
Genart Telechat review of -04 by Joel M. Halpern (diff)
Opsdir Last Call review of -03 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Request Last Call review on draft-ietf-tls-applayerprotoneg by Ops Directorate Assigned
Reviewed revision 03 (document currently at 05)
Result Has issues
Completed 2013-12-30
review-ietf-tls-applayerprotoneg-03-opsdir-lc-kuarsingh-2013-12-30-00

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