Skip to main content

Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
draft-ietf-tls-applayerprotoneg-05

Revision differences

Document history

Date Rev. By Action
2014-07-09
05 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-06-25
05 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-06-25
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-06-19
05 (System) RFC Editor state changed to EDIT from IESG
2014-05-13
(System) Posted related IPR disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg
2014-05-12
(System) Posted related IPR disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg
2014-04-30
05 (System) RFC Editor state changed to IESG from EDIT
2014-04-28
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-04-23
05 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-04-23
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-04-22
05 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-04-22
05 (System) RFC Editor state changed to EDIT
2014-04-22
05 (System) Announcement was received by RFC Editor
2014-04-21
05 (System) IANA Action state changed to In Progress
2014-04-21
05 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2014-04-21
05 Amy Vezza IESG has approved the document
2014-04-21
05 Amy Vezza Closed "Approve" ballot
2014-04-21
05 Amy Vezza Ballot approval text was generated
2014-04-21
05 Amy Vezza Ballot writeup was changed
2014-04-19
05 Stephen Farrell Ballot writeup was changed
2014-03-05
05 Cindy Morgan Shepherding AD changed to Stephen Farrell
2014-03-03
05 Stephan Friedl IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-03-03
05 Stephan Friedl New version available: draft-ietf-tls-applayerprotoneg-05.txt
2014-02-13
04 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2014-02-06
04 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2014-02-06
04 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2014-02-05
04 Pete Resnick
[Ballot comment]
I am afraid that some of the normative language in this document would require you to make this an update to 5246, and …
[Ballot comment]
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
2014-02-05
04 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-02-05
04 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-02-05
04 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-02-05
04 Adrian Farrel [Ballot comment]
Seems reasonable to me.

Nit: The ToC is missing page numbers.
2014-02-05
04 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-02-05
04 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-02-05
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-02-05
04 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2014-02-04
04 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-02-04
04 Martin Stiemerling [Ballot comment]
A nit (in multiple places):

It is not "TCP/IP port number", but only "TCP port number".
2014-02-04
04 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-02-04
04 Stephen Farrell
[Ballot comment]

These are pretty nitty comments mostly, but not quite
entirely:-)

- abstract: this is slightly wrong - the main use case here is …
[Ballot comment]

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.
2014-02-04
04 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2014-02-03
04 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-02-02
04 Joel Jaeggli
[Ballot comment]
  Finally, by managing protocol selection in the clear as part of the
  handshake, ALPN avoids introducing false confidence with respect to …
[Ballot comment]
  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.
2014-02-02
04 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-02-02
04 Joel Jaeggli
(reflowed to make it readable 2/2/14)

(1) What type of RFC is being requested BCP, Proposed Standard,
(Internet Standard, Informational, Experimental, or Historic)? Why is …
(reflowed to make it readable 2/2/14)

(1) What type of RFC is being requested BCP, Proposed Standard,
(Internet Standard, Informational, Experimental, or Historic)? Why is
(this the proper type of RFC? Is this type of RFC indicated in the
(title page header?

The type of RFC request is Proposed Standard. Standards track is
appropriate because it is generally useful for the internet and
reflects the consensus of the TLS working group.

(2) The IESG approval announcement includes a Document Announcement
(Write-Up. Please provide such a Document Announcement Write-Up.
(Recent examples can be found in the "Action" announcements for
(approved documents. The approval announcement contains the following
(sections:


Technical Summary: This document describes a Transport Layer Security
(TLS) extension for application layer protocol negotiation within the
TLS handshake. For instances in which the TLS connection is
established over a well known TCP/IP port not associated with the
desired application layer protocol, this extension allows the
application layer to negotiate which protocol will be used within the
TLS session.

Working Group Summary: 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.

Document Quality: A number of vendors have implemented the protocol
specified in this document. This document was also reviewed by members
of the HTTPbis working group as it is useful for indicating what
protocol is carried by TLS.

Personnel: Joe Salowey is the document shepherd and Sean Turner is the
responsible AD.

(3) Briefly describe the review of this document that was performed by
(the Document Shepherd. If this version of the document is not ready
(for publication, please explain why the document is being forwarded
(to the IESG.

The document shepherd has reviewed the document and checked it for ID
nits. THe document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
(breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
(broader perspective, e.g., security, operational complexity, AAA,
(DNS, DHCP, XML, or internationalization? If so, describe the review
(that took place.

The document has been reviewed by participants of the HTTPbis working
group. They participated throughout the document development process
and held a final review at the end of TLS working group last call.

(6) Describe any specific concerns or issues that the Document
(Shepherd has with this document that the Responsible Area Director
(and/or the IESG should be aware of? For example, perhaps he or she is
(uncomfortable with certain parts of the document, or has concerns
(whether there really is a need for it. In any event, if the WG has
(discussed those issues and has indicated that it still wishes to
(advance the document, detail those concerns here.

No Concerns

(7) Has each author confirmed that any and all appropriate IPR
(disclosures required for full conformance with the provisions of BCP
(78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If
(so, summarize any WG discussion and conclusion regarding the IPR
(disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it
(represent the strong concurrence of a few individuals, with others
(being silent, or does the WG as a whole understand and agree with it?

the document represents strong consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme
(discontent? If so, please summarise the areas of conflict in separate
(email messages to the Responsible Area Director. It should be in a
(separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
(document. See http://www.ietf.org/tools/idnits/ and the Internet-
(Drafts Checklist). Boilerplate checks are not enough; this check
(needs to be thorough.

The document has passed ID-NITS

(12) Describe how the document meets any required formal review
(criteria, such as the MIB Doctor, media type, and URI type reviews.

No special formal review was required.

(13) Have all references within this document been identified as
(either normative or informative?

Yes

(14) Are there normative references to documents that are not ready
(for advancement or are otherwise in an unclear state? If such
(normative references exist, what is the plan for their completion?

All normative references are published

(15) Are there downward normative references references see RFC 3967)?
(If so, list these downward references to support the Area Director in
(the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
(existing RFCs? Are those RFCs listed on the title page header, listed
(in the abstract, and discussed in the introduction? If the RFCs are
(not listed in the Abstract and Introduction, explain why, and point
(to the part of the document where the relationship of this document
(to the other RFCs is discussed. If this information is not in the
(document, explain why the WG considers it unnecessary.

This document does not change the status of any other RFCs.

(17) Describe the Document Shepherd's review of the IANA
(considerations section, especially with regard to its consistency
(with the body of the document. Confirm that all protocol extensions
(that the document makes are associated with the appropriate
(reservations in IANA registries. Confirm that any referenced IANA
(registries have been clearly identified. Confirm that newly created
(IANA registries include a detailed specification of the initial
(contents for the registry, that allocations procedures for future
(registrations are defined, and a reasonable name for the new registry
(has been suggested see RFC 5226).

The shepherd has reviewed the IANA considerations section and it is
consistent with the document and registries clearly defined.

(18) List any new IANA registries that require Expert Review for
(future allocations. Provide any public guidance that the IESG would
(find useful in selecting the IANA Experts for these new registries.

The document defines a new Application Layer Protocol Negotiation
(ALPN) Protocol IDs registry. There are specific instructions to the
expert in the IANA section. Since it is under the TLS registries it
would make sense to select experts who know TLS.

(19) Describe reviews and automated checks performed by the Document
(Shepherd to validate sections of the document written in a formal
(language, such as XML code, BNF rules, MIB definitions, etc.

No Formal Language used in document
2014-02-02
04 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-01-31
04 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2014-01-31
04 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2014-01-31
04 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-01-31
04 Sean Turner Changed consensus to Yes from Unknown
2014-01-31
04 Sean Turner NOTE:  Getting this document to this point has been pretty contentious.  The decision to adopt this approach over the competing proposal was very rough.
2014-01-31
04 Sean Turner Ballot has been issued
2014-01-31
04 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2014-01-31
04 Sean Turner Created "Approve" ballot
2014-01-31
04 Sean Turner Ballot writeup was changed
2014-01-31
04 Sean Turner Placed on agenda for telechat - 2014-02-06
2014-01-31
04 Sean Turner State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2014-01-24
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-01-24
04 Stephan Friedl IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-01-24
04 Stephan Friedl New version available: draft-ietf-tls-applayerprotoneg-04.txt
2014-01-14
03 Sean Turner State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2014-01-14
03 Sean Turner State changed to Waiting for AD Go-Ahead from Waiting for Writeup
2013-12-30
03 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Victor Kuarsingh.
2013-12-27
03 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-12-27)
2013-12-24
03 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-12-24
03 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tls-applayerprotoneg-03. Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tls-applayerprotoneg-03. Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document there are two actions which IANA must complete.

First, in the ExtensionType Values registry in the Transport Layer Security (TLS) Extensions page at:

http://www.iana.org/assignments/tls-extensiontype-values/

the temporary registration for value 16 (application_layer_protocol_negotiation) will be made permanent as follows:

Value: 16
Extension name: application_layer_protocol_negotiation
Reference: [ RFC-to-be ]

Second, a new registry will be created in the Transport Layer Security (TLS) Extensions page at

http://www.iana.org/assignments/tls-extensiontype-values/

The new registry will be called "Application Layer Protocol Negotiation (ALPN) Protocol IDs."

Entries in this new registry will have the following fields:

Protocol: The name of the protocol.

Identification Sequence: The precise set of octet values that identifies the protocol. This could be the UTF-8 encoding [RFC3629] of the protocol name.

Specification: A reference to a specification that defines the protocol.

This registry is maintained using Expert Review as defined in RFC 5226.

There are four initial registrations:

Protocol: HTTP/1.1
Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
Specification: [RFC2616]

Protocol: SPDY/1
Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1

Protocol: SPDY/2
Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2

Protocol: SPDY/3
Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3

IANA understands these two actions to be the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-12-19
03 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2013-12-19
03 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2013-12-19
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ondřej Surý
2013-12-19
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ondřej Surý
2013-12-18
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2013-12-18
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2013-12-13
03 Cindy Morgan IANA Review state changed to IANA - Review Needed
2013-12-13
03 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transport Layer Security (TLS) Application …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) Application Layer Protocol Negotiation
  Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a Transport Layer Security (TLS) extension
  for application layer protocol negotiation within the TLS handshake.
  For instances in which the TLS connection is established over a well
  known TCP/IP port not associated with the desired application layer
  protocol, this extension allows the application layer to negotiate
  which protocol will be used within the TLS session.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-12-13
03 Cindy Morgan State changed to In Last Call from Last Call Requested
2013-12-13
03 Sean Turner Last call was requested
2013-12-13
03 Sean Turner Ballot approval text was generated
2013-12-13
03 Sean Turner Ballot writeup was generated
2013-12-13
03 Sean Turner State changed to Last Call Requested from AD Evaluation
2013-12-13
03 Sean Turner Last call announcement was generated
2013-12-11
03 Sean Turner State changed to AD Evaluation from AD Evaluation::External Party
2013-11-06
03 Sean Turner State changed to AD Evaluation::External Party from AD Evaluation
2013-11-05
03 Sean Turner State changed to AD Evaluation from Publication Requested
2013-11-05
03 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The type of RFC request is Proposed Standard. Standards track is appropriate because it is generally useful for the internet and reflects the consensus of the TLS working group.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:


Technical Summary:
This document describes a Transport Layer Security (TLS) extension
for application layer protocol negotiation within the TLS handshake.
For instances in which the TLS connection is established over a well
known TCP/IP port not associated with the desired application layer
protocol, this extension allows the application layer to negotiate
which protocol will be used within the TLS session.

Working Group Summary:
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.

Document Quality:
A number of vendors have implemented the protocol specified in this document. This document was also reviewed by members of the HTTPbis working group as it is useful for indicating what protocol is carried by TLS.

Personnel:
Joe Salowey is the document shepherd and Sean Turner is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and checked it for ID nits. THe document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document has been reviewed by participants of the HTTPbis working group. They participated throughout the document development process and held a final review at the end of TLS working group last call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No Concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

the document represents strong consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document has passed ID-NITS

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No special formal review was required.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are published

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The shepherd has reviewed the IANA considerations section and it is consistent with the document and registries clearly defined.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document defines a new Application Layer Protocol Negotiation (ALPN) Protocol IDs registry. There are specific instructions to the expert in the IANA section. Since it is under the TLS registries it would make sense to select experts who know TLS.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No Formal Language used in document
2013-11-05
03 Cindy Morgan IETF WG state changed to Submitted to IESG for Publication
2013-11-05
03 Cindy Morgan IESG state changed to Publication Requested
2013-11-05
03 Cindy Morgan Working group state set to Submitted to IESG for Publication
2013-11-05
03 Cindy Morgan IESG state set to Publication Requested
2013-11-05
03 Cindy Morgan Changed document writeup
2013-11-05
03 Cindy Morgan Document shepherd changed to Joseph A. Salowey
2013-10-15
03 Stephan Friedl New version available: draft-ietf-tls-applayerprotoneg-03.txt
2013-10-08
02 Sean Turner Intended Status changed to Proposed Standard
2013-10-08
02 Sean Turner IESG process started in state AD is watching
2013-10-08
02 (System) Earlier history may be found in the Comment Log for /doc/draft-friedl-tls-applayerprotoneg/
2013-09-30
02 Andrei Popov New version available: draft-ietf-tls-applayerprotoneg-02.txt
2013-04-25
01 Stephan Friedl New version available: draft-ietf-tls-applayerprotoneg-01.txt
2013-04-08
00 Stephan Friedl New version available: draft-ietf-tls-applayerprotoneg-00.txt