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 |