Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
draft-ietf-dnsop-svcb-https-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-03-21
|
12 | Jim Reid | Request for Last Call review by DNSDIR is assigned to Matt Brown |
2023-03-21
|
12 | Jim Reid | Closed request for Last Call review by DNSDIR with state 'Overtaken by Events': Broken URL? |
2023-03-21
|
12 | Petr Špaček | Assignment of request for Last Call review by DNSDIR to Petr Špaček was rejected |
2023-03-20
|
12 | Jim Reid | Request for Last Call review by DNSDIR is assigned to Petr Špaček |
2023-03-20
|
12 | Cindy Morgan | The following Last Call announcement was sent out (ends 2023-04-03): From: The IESG To: IETF-Announce CC: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, … The following Last Call announcement was sent out (ends 2023-04-03): From: The IESG To: IETF-Announce CC: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, tjw.ietf@gmail.com, warren@kumari.net Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' 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 last-call@ietf.org mailing lists by 2023-04-03. 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. Your attention please... This is a second IETF LC for this document - it was originally approved on 2022-05-25 and sent to the RFC Editor. However, it had a reference to a reference to a document (ECH in the TLS WG) which will still be many months in the making -- and other documents are now waiting on this document. As the ECH reference was for an "optional feature", after discussions with the authors, WG, chairs, chairs of TLS, authors of ECH, authors of the other documents, IESG, etc we asked the RFC Editor to return the document. It has now had the ECH feature removed, and has had another WGLC, and this is the IETF LC on the removal of the text. It probably didn't need all of this process stuff, but I figured it is better to have transparency (and, yes, this is being coordinated with the documents that rely on this doc!) Please see the shepherd's writeup if this is confusing... Diff from the previously approved version: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html We now return you to your regularly scheduled LC text... Abstract This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ No IPR declarations have been submitted directly on this I-D. |
2023-03-20
|
12 | Cindy Morgan | IESG state changed to In Last Call from Publication Requested |
2023-03-20
|
12 | Cindy Morgan | Last call announcement was changed |
2023-03-20
|
12 | Cindy Morgan | Last call announcement was changed |
2023-03-19
|
12 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record … (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary: Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records. The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule. Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/ WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/ This document carried on to the RFC Editor's quere where it was sitting for a long time waiting for the completion of draft-ietf-tls-esni. This turned out to be taking much longer than had been expected, and this document was holding up other documents in other working groups, so after some discussion, the document was brought back from the RFC Editor's queue to the working group, the authors removed the sections referncing the ECH options to place in a new document, and republished. Their changes are here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html Also, the Area Director's discussion of this process https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/ Document Quality: While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) == Outdated reference: draft-ietf-httpbis-semantics has been published as RFC 9110 -- Possible downref: Normative reference to a draft: ref. 'HTTP' ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 7871 == Outdated reference: draft-ietf-quic-http has been published as RFC 9114 (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state (15) There is one downward normative reference to RFC 7871, which has one existing downward reference. (16) This RFC will not change any existing RFCs. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews. (19) N/A (20) No Yang Necessary |
2023-03-19
|
12 | Warren Kumari | Last call announcement was changed |
2023-03-19
|
12 | Warren Kumari | Last call announcement was changed |
2023-03-19
|
12 | Warren Kumari | Last call announcement was generated |
2023-03-19
|
12 | Warren Kumari | Last call announcement was generated |
2023-03-18
|
12 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record … (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary: Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records. The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule. Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/ WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/ This document carried on to the RFC Editor's quere where it was sitting for a long time waiting for the completion of draft-ietf-tls-esni. This turned out to be taking much longer than had been expected, and this document was holding up other documents in other working groups, so after some discussion, the document was brought back from the RFC Editor's queue to the working group, the authors removed the sections referncing the ECH options to place in a new document, and republished. Their changes are here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html Also, the Area Director's discussion of this process https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/ Document Quality: While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) == Outdated reference: A later version (-12) exists of draft-ietf-tls-esni-11 ** Downref: Normative reference to an Informational RFC: RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) (12) No formal review needed (13) All references have been identified as normative or informative. (14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement. (15) There is one downward normative reference to RFC 7871, which has one existing downward reference. (16) This RFC will not change any existing RFCs. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews. (19) N/A (20) No Yang Necessary |
2023-03-18
|
12 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2023-03-18
|
12 | Tim Wicinski | IESG state changed to Publication Requested from RFC Ed Queue |
2023-03-18
|
12 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
2023-03-18
|
12 | Tim Wicinski | Tag Holding for references cleared. |
2023-03-18
|
12 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2023-03-11
|
12 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record … (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary: Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records. The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule. Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/ WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/ This document carried on to the RFC Editor's quere where it was sitting for a long time waiting for the completion of draft-ietf-tls-esni. This turned out to be taking much longer than had been expected, and this document was holding up other documents in other working groups, so after some discussion, the document was brought back from the RFC Editor's queue to the working group, the authors removed the sections referncing the ECH options to place in a new document, and republished. Their changes are here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html Also, the Area Director's discussion of this process https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/ Document Quality: While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) == Outdated reference: A later version (-12) exists of draft-ietf-tls-esni-11 ** Downref: Normative reference to an Informational RFC: RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) (12) No formal review needed (13) All references have been identified as normative or informative. (14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement. (15) There is one downward normative reference to RFC 7871, which has one existing downward reference. (16) This RFC will not change any existing RFCs. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews. (19) N/A (20) No Yang Necessary |
2023-03-11
|
12 | Tim Wicinski | Tag Holding for references cleared. |
2023-03-11
|
12 | Tim Wicinski | IETF WG state changed to In WG Last Call from Submitted to IESG for Publication |
2023-03-11
|
12 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-12.txt |
2023-03-11
|
12 | Benjamin Schwartz | New version accepted (logged-in submitter: Benjamin Schwartz) |
2023-03-11
|
12 | Benjamin Schwartz | Uploaded new revision |
2022-10-11
|
11 | Mike Bishop | New version available: draft-ietf-dnsop-svcb-https-11.txt |
2022-10-11
|
11 | (System) | New version approved |
2022-10-10
|
11 | (System) | Request for posting confirmation emailed to previous authors: Benjamin Schwartz , Erik Nygren , Mike Bishop |
2022-10-10
|
11 | Mike Bishop | Uploaded new revision |
2022-06-02
|
10 | Cindy Morgan | Downref to RFC 7871 approved by Last Call for draft-ietf-dnsop-svcb-https-10 |
2022-05-31
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-05-30
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-05-30
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-05-30
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-05-27
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-05-27
|
10 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2022-05-27
|
10 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Brian Weis was marked no-response |
2022-05-26
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-05-25
|
10 | (System) | RFC Editor state changed to MISSREF |
2022-05-25
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-05-25
|
10 | (System) | Announcement was received by RFC Editor |
2022-05-25
|
10 | (System) | IANA Action state changed to In Progress |
2022-05-25
|
10 | (System) | Removed all action holders (IESG state changed) |
2022-05-25
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2022-05-25
|
10 | Cindy Morgan | IESG has approved the document |
2022-05-25
|
10 | Cindy Morgan | Closed "Approve" ballot |
2022-05-25
|
10 | Cindy Morgan | Ballot approval text was generated |
2022-05-24
|
10 | Francesca Palombini | [Ballot comment] Thank you for the work on this document, and for addressing my previous DISCUSS and COMMENTs. Many thanks to Cullen Jennings for his … [Ballot comment] Thank you for the work on this document, and for addressing my previous DISCUSS and COMMENTs. Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. Francesca |
2022-05-24
|
10 | Francesca Palombini | [Ballot Position Update] Position for Francesca Palombini has been changed to No Objection from Discuss |
2022-05-24
|
10 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-10.txt |
2022-05-24
|
10 | Benjamin Schwartz | New version approved |
2022-05-24
|
10 | (System) | Request for posting confirmation emailed to previous authors: Benjamin Schwartz , Erik Nygren , Mike Bishop |
2022-05-24
|
10 | Benjamin Schwartz | Uploaded new revision |
2022-05-23
|
09 | Warren Kumari | Changed action holders to Erik Nygren, Mike Bishop, Benjamin Schwartz (Better tracking of who holds the ball.) |
2022-05-23
|
09 | Francesca Palombini | [Ballot discuss] Thank you for the work on this document. Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. Thank you for … [Ballot discuss] Thank you for the work on this document. Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed v-09 and I noticed 4 points were not addressed (or I missed them). Do let me know if you think no further clarifications were necessary - just making sure these were not missed, as I have not seen any answers to them. Re: the use of SHOULD - thank you for adding context to most of them. I did not see any added context to these following two SHOULDs: > Zone-file implementations SHOULD enforce self-consistency. and > If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. If SHOULD is used, then it must be accompanied by at least one of: (1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise. Examples are fine but, except in plausible and rare cases, not enumerated lists. (2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met. (3) A statement about why it is not a MUST. Francesca |
2022-05-23
|
09 | Francesca Palombini | [Ballot comment] 4. ----- The value is then validated and converted into wire-format in a manner specific to each key. FP: Section 15.3.1 … [Ballot comment] 4. ----- The value is then validated and converted into wire-format in a manner specific to each key. FP: Section 15.3.1 states registration policy ([RFC8126], Section 4.5). The designated expert MUST ensure that the Format Reference is stable and publicly available, and that it specifies how to convert the SvcParamValue's presentation format to wire format. This covers the conversion, but does not cover the validation mentioned above. (This could be really easily addressed by making sure that not only it specifies how to convert but also how to validate). 10. ----- Table 1 FP: The table reports that | 65280-65534 | N/A | Private Use | (This document) | But that is not specified in the text above, that only talks about expert review registration policy. That should be made consistent. |
2022-05-23
|
09 | Francesca Palombini | Ballot comment and discuss text updated for Francesca Palombini |
2022-05-11
|
09 | Paul Wouters | [Ballot comment] While a little more complicated that I'd wish, it seems this does seem to be one of the simpler and more robust solutions … [Ballot comment] While a little more complicated that I'd wish, it seems this does seem to be one of the simpler and more robust solutions to the "CNAME at apex" problem. As for Ben's (former) DISCUSS, Ben is correct that this document pushes deployments towards https and makes assumptions that the http and https namespaces are providing identical context even though formally this is not the case. While technically this is a protocol issue, I do believe that in practice everyone already assumes that the content for a certain domain name would be the same for http and https unless the http just contains a redirect to https. I find this case similar to the case where everyone in the world assumes Paul@nohats.ca and paul@nohats.ca goes to the same mailbox, even though SMTP formally claims the LHS may not be interpreted in such a way and could be delivered to different people. As such, I am not taking over Ben's DISCUSS on this. |
2022-05-11
|
09 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
2022-05-09
|
09 | Murray Kucherawy | [Ballot comment] I support Francesca's DISCUSS around use of SHOULDs. Thanks for the fixes to IANA Considerations. One minor issue remains, which is that we're … [Ballot comment] I support Francesca's DISCUSS around use of SHOULDs. Thanks for the fixes to IANA Considerations. One minor issue remains, which is that we're allowing an automatically-expiring document (an I-D) to set the bar for what constitutes a valid Format Reference. Given such a registration might be permanent, a disappearing reference seems a curious choice. The discussion in the WG indicates that this is done to support experimental registrations and the like; it might be good for the text to say so. |
2022-05-09
|
09 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2022-05-09
|
09 | Erik Kline | [Ballot comment] Thanks for the changes! (Referring to 4001 seems odd to me, and maybe unnecessary.) |
2022-05-09
|
09 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to Yes from Discuss |
2022-05-06
|
09 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
2022-05-06
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-05-06
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2022-05-06
|
09 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-09.txt |
2022-05-06
|
09 | Benjamin Schwartz | New version approved |
2022-05-06
|
09 | (System) | Request for posting confirmation emailed to previous authors: Benjamin Schwartz , Erik Nygren , Mike Bishop |
2022-05-06
|
09 | Benjamin Schwartz | Uploaded new revision |
2022-04-19
|
08 | Carlos Pignataro | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2022-04-04
|
08 | Carlos Bernardos | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2022-04-04
|
08 | Carlos Bernardos | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2022-04-04
|
08 | Carlos Bernardos | Assignment of request for Telechat review by INTDIR to Suresh Krishnan was marked no-response |
2022-03-22
|
08 | Murray Kucherawy | [Ballot discuss] Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy. RFC 8126 says this of that policy: … [Ballot discuss] Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy. RFC 8126 says this of that policy: It is also important to understand that First Come First Served really has no filtering. Essentially, any well-formed request is accepted. Yet this document stipulates: [...] The Format Reference MUST specify how to convert the SvcParamValue's presentation format to wire format and MAY detail its intended meaning and use. An entry MAY specify a Format Reference of the form "Same as (other key Name)" if it uses the same presentation and wire formats as an existing key. These seem to me to be in conflict. We're asking IANA to do more than what the BCP says is valid here. Should this instead be Expert Review? |
2022-03-22
|
08 | Murray Kucherawy | [Ballot comment] I support Francesca's DISCUSS around use of SHOULDs. |
2022-03-22
|
08 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to Discuss from No Objection |
2022-03-22
|
08 | Murray Kucherawy | [Ballot comment] I support Francesca's DISCUSS around use of SHOULDs. I also support Ben's DISCUSS about IANA Considerations. I originally held a DISCUSS that noted … [Ballot comment] I support Francesca's DISCUSS around use of SHOULDs. I also support Ben's DISCUSS about IANA Considerations. I originally held a DISCUSS that noted Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy. RFC 8126 says this of that policy: It is also important to understand that First Come First Served really has no filtering. Essentially, any well-formed request is accepted. Yet this document stipulates: [...] The Format Reference MUST specify how to convert the SvcParamValue's presentation format to wire format and MAY detail its intended meaning and use. An entry MAY specify a Format Reference of the form "Same as (other key Name)" if it uses the same presentation and wire formats as an existing key. These seem to me to be in conflict. We're asking IANA to do more than what the BCP says is valid here. Should this instead be Expert Review? |
2022-03-22
|
08 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2022-03-03
|
08 | (System) | Changed action holders to Warren Kumari, Erik Nygren, Mike Bishop, Benjamin Schwartz (IESG state changed) |
2022-03-03
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-03-03
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2022-03-03
|
08 | Erik Kline | [Ballot discuss] [Appendix D.2] * Sorry to be super nitpicky/petty about this. With respect to Figure 7: IPv4-mapped IPv6 addresses have a complicated … [Ballot discuss] [Appendix D.2] * Sorry to be super nitpicky/petty about this. With respect to Figure 7: IPv4-mapped IPv6 addresses have a complicated history (see RFC 4942 S2.2 for an amuse-bouche, as well as itojun's draft-itojun-v6ops-v4mapped-harmful). Unless there is something very useful to be gained by the inclusion of this example (what?) I would strongly suggest removing it. I fear it will only cause confusion. |
2022-03-03
|
08 | Erik Kline | [Ballot comment] [S2.3; comment] * "When a prior CNAME or SVCB record has aliased to a SVCB record, each RR shall be returned under … [Ballot comment] [S2.3; comment] * "When a prior CNAME or SVCB record has aliased to a SVCB record, each RR shall be returned under its own owner name." I think this could use some explanation and a reference to Section 11. Perhaps something along the lines of This is in account of the client resolution process [Section 3]. See also discussion in [Section 11.1]. |
2022-03-03
|
08 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2022-03-02
|
08 | Murray Kucherawy | [Ballot discuss] Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy. RFC 8126 says this of that policy: … [Ballot discuss] Section 15.3.1 creates a new IANA registry with a First Come First Served registration policy. RFC 8126 says this of that policy: It is also important to understand that First Come First Served really has no filtering. Essentially, any well-formed request is accepted. Yet this document stipulates: [...] The Format Reference MUST specify how to convert the SvcParamValue's presentation format to wire format and MAY detail its intended meaning and use. An entry MAY specify a Format Reference of the form "Same as (other key Name)" if it uses the same presentation and wire formats as an existing key. These seem to me to be in conflict. We're asking IANA to do more than what the BCP says is valid here. Should this instead be Expert Review? |
2022-03-02
|
08 | Murray Kucherawy | [Ballot comment] I support Francesca's DISCUSS around use of SHOULDs. |
2022-03-02
|
08 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2022-03-02
|
08 | John Scudder | [Ballot comment] I support Francesca Palombini's discuss. |
2022-03-02
|
08 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2022-03-02
|
08 | Francesca Palombini | [Ballot discuss] Thank you for the work on this document Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. I am concerned … [Ballot discuss] Thank you for the work on this document Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. I am concerned by the use of SHOULD in this document. In several places (see 1. below for what I identified as problematic SHOULDs) the document lacks text about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who formulated it very clearly: If SHOULD is used, then it must be accompanied by at least one of: (1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise. Examples are fine but, except in plausible and rare cases, not enumerated lists. (2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met. (3) A statement about why it is not a MUST. I also have a number of non blocking comments and questions. I will appreciate answers to my questions, to improve my understanding. If any clarification comes out of it, I hope it will help improve the document. Francesca 1. ----- FP: SHOULD lacking additional context: Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller SvcPriority value SHOULD be given preference over RRs with a larger SvcPriority value. In AliasMode, the SVCB record aliases a service to a TargetName. SVCB RRSets SHOULD only have a single resource record in AliasMode. If multiple are present, clients or recursive resolvers SHOULD pick one at random. In AliasMode, records SHOULD NOT include any SvcParams, and recipients MUST ignore any SvcParams that are present. Zone-file implementations SHOULD enforce self-consistency. If the client is SVCB-optional, and connecting using this list of endpoints has failed, the client SHOULD attempt non-SVCB connection modes. If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. If the client is unable to complete SVCB resolution due to its chain length limit, the client SHOULD fall back to the authority endpoint, as if the origin's SVCB record did not exist. For compatibility with clients that require default transports, zone operators SHOULD ensure that at least one RR in each RRSet supports the default transports. Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD have a defined specification for use with SVCB. |
2022-03-02
|
08 | Francesca Palombini | [Ballot comment] 2. ----- This subsection briefly describes the SVCB RR in a non-normative manner. (As mentioned above, this all applies equally to … [Ballot comment] 2. ----- This subsection briefly describes the SVCB RR in a non-normative manner. (As mentioned above, this all applies equally to the HTTPS RR which shares the same encoding, format, and high-level semantics.) FP: I am not sure about why this section is described as non-normative but does define requirements etc. Maybe it is normatively described somewhere else? Then a pointer to that makes sense. Also why does this mention encoding and format but there is no encoding specified. 3. ----- format specific to the SvcParamKey. Their definition should specify both their presentation format and wire encoding (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys and FP: I have the feeling "should" is not the right term here, I suggest to change to "must" or "is required to". Also, it would have been useful to me to add a pointer to RFC 8499 in the terminology about "presentation format". 4. ----- The value is then validated and converted into wire-format in a manner specific to each key. FP: Section 15.4 states registration policy ([RFC8126], Section 4.4). The Format Reference MUST specify how to convert the SvcParamValue's presentation format to wire format and MAY detail its intended meaning and use. An entry This covers the conversion, but does not cover the validation mentioned above. 5. ----- SvcParams in presentation format MAY appear in any order, but keys MUST NOT be repeated. FP: Seems to contradict SvcParamKeys SHALL appear in increasing numeric order. 6. ----- If the client has an in-progress TCP connection to [2001:db8::2]:1234, it MAY proceed with TLS on that connection using ech="222...", even though the other record in the RRSet has higher priority. FP: I believe this is descriptive of the example and should not use BCP 14 MAY. 7. ----- For example, the following is a valid list of SvcParams: ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech FP: I expected this to be a comma separated list. 8. ----- length prefix. In presentation format, the value is a single ECHConfigList encoded in Base64 [base64]. Base64 is used here to FP: Please clarify that "Base 64 Encoding" (Section 4) is used (rather than "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5)) 9. ----- FP: According to 8126, the registry "Service Parameter Keys (SvcParamKeys)" should include a change controller field. 10. ----- Table 1 FP: The table reports that | 65280-65534 | N/A | Private Use | (This document) | But that is not specified in the text above, that only talks about first come first serve registration policy. That should be made consistent. # Nits and Editorials 11. ------ When the "=" is omitted, the value is interpreted as empty. FP: When the optional "=" SvcParamValue is omitted 12. ----- All protocols employing "http://" or "https://" URLs SHOULD respect HTTPS RRs. For example, clients that support HTTPS RRs and implement FP: I am not sure how the first sentence is supposed to be implemented, hence why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be the clearest wording. |
2022-03-02
|
08 | Francesca Palombini | [Ballot Position Update] New position, Discuss, has been recorded for Francesca Palombini |
2022-03-02
|
08 | Amanda Baber | IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed |
2022-03-02
|
08 | Amanda Baber | IANA issue identified by Ben Kaduk: I can confirm that IANA can't verify that a reference specifies how to convert the SvcParamValue's presentation format to … IANA issue identified by Ben Kaduk: I can confirm that IANA can't verify that a reference specifies how to convert the SvcParamValue's presentation format to wire format (a MUST in Section 15.3.1). If this is required for registration, the registration procedure needs to be changed from FCFS to Specification Required (which involves expert review). |
2022-03-02
|
08 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Important piece of work as it is related to some ADD documents as well. … [Ballot comment] Thank you for the work put into this document. Important piece of work as it is related to some ADD documents as well. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tim Wicinski for the shepherd's write-up including the detailed section about the WG consensus even if I regret the absence of intended status justification. I hope that this helps to improve the document, Regards, -éric Cosmetic one: I have seen only two "ordinary AAAA/A lookups" and too many "A or AAAA"... this hurts my IPv6 eyes ;-) ## Section 1 Just a thank you for such a well-written and clear introduction. This comment also applies to most of the document BTW ! ## Section 1.1 "Enable SRV-like benefits (e.g. apex delegation, as mentioned above) for HTTP, where SRV [SRV] has not been widely adopted", if the "old" SRV has not been adopted, then what is the probability of having the "new" SVCB adopted ? Should "HSTS" be expanded at first use ? ## Section 1.2 In "Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records)", is it assumed that only cached information (A, AAAA) will be used ? Else, it may slow down the resolution of the SVCB. In "Additional Section of the response", is it assumed that the response in this sentence is only a response to a SVCB query ? ## Section 2.2 What is the reason for using uncompressed fully-qualified targetname ? Should there be some justifications for this absence of compression ? ## Section 2.4.1 Usually when "SHOULD" is used, the specification describes the exception(s). ## Section 2.4.2 Same comment about the use of "SHOULD" (also in many other places) "In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. ", is it a "will" or a "MUST" ? Should "CNAME" also be a potential answer (at the expense of another query)? "this AliasMode record can be replaced by a CNAME" except for apex ... ## Section 2.5.2 Suggest to use a SVCB RR rather than HTTPS to ease the reading of the example. If compressed DNS name would be allowed (see my comment on sect 2.2) then using "." would bring nearly no size benefit. ## Section 3 Would a mechanism similar to happy eye ball be used to request SVCB, AAAA, and A ? It is described later in section 5 but an early hint would not hurt. "Clients resolve AAAA and/or A records for the selected TargetName, and MAY choose between them using an approach such as Happy Eyeballs" why not a "SHOULD" ? ## Section 4.1 "authoritative DNS servers SHOULD return A, AAAA, and SVCB records in the Additional Section for any TargetNames that are in the zone", shouldn't the SVCB RRs be in the Answer section? What did I misread ? ## Section 7.2 Strongly suggest not to limit ports to UDP and TCP but either cite UDP and TCP as examples or include SCTP/DCCP. ## Section 7.4 "For best performance, server operators SHOULD include an "ipv6hint" parameter whenever they include an "ipv4hint" parameter." There is a bias in the sentence for "ipv4hint" and it should only applies when both "ipv6hint" and "ipv4hint" exist. ## Section 11.1 "zone owners SHOULD choose alias target names that indicate the scheme in use", would a "it is RECOMMENDED" be more applicable and suitable ? |
2022-03-02
|
08 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-03-02
|
08 | Robert Wilton | [Ballot comment] I would like to thank Joe for the Opsdir review. I just have some minor comments (I'm not a DNS expert): In 2.3, … [Ballot comment] I would like to thank Joe for the Opsdir review. I just have some minor comments (I'm not a DNS expert): In 2.3, to indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of example.net, in turn, could publish this record: svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( alpn="bar" port="8004" ech="..." ) to indicate that these services are served on port number 8004, which supports the protocol "bar" and its associated transport in addition to the default transport protocol for "foo://". I can understand how this record indicates that it supports protocol "bar", but it is not obvious to me how this record also indicates that it also supports "foo://". 2.4.1. SvcPriority RRSets are explicitly unordered collections, so the SvcPriority field is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller SvcPriority value SHOULD be given preference over RRs with a larger SvcPriority value. Would it be helpful for this text to indicate under what conditions this SHOULD is not a MUST? Which is perhaps related to the text in section 5.1? The primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed. In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. (See Section 6 for aliasing of SVCB-compatible RR types.) The TargetName SHOULD NOT be equal to the owner name, as this would result in a loop. It was unclear to me that this is a SHOULD NOT rather than a MUST NOT. I.e., are there some circumstances where it is useful to not comply with this. In AliasMode, records SHOULD NOT include any SvcParams, and recipients MUST ignore any SvcParams that are present. Again, I wasn't sure why this isn't a MUST NOT rather than a SHOULD NOT? Finally, thank you for providing the examples in 11.3, I found them to be particularly helpful. Regards, Rob |
2022-03-02
|
08 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-03-02
|
08 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the efforts on this specification. Thanks to Kyle Rose for his TSVART reviews, my understanding is those issues are not really … [Ballot comment] Thanks for the efforts on this specification. Thanks to Kyle Rose for his TSVART reviews, my understanding is those issues are not really transport related issues and has been addressed. I am think I am sympathetic to Ben's discuss but also understand this is well within the HSTS norms. I will be watching that discussion. I have only one question: My understanding on this specification is - if there is a record _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. then _foo.example.com must not have any ServiceMode SVCB record. is that correct? it was not so obvious to me. |
2022-03-02
|
08 | Zaheduzzaman Sarker | Ballot comment text updated for Zaheduzzaman Sarker |
2022-03-02
|
08 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the efforts on this specification. Thanks to Kyle Rose for his TSVART reviews, my understanding is those issues are not really … [Ballot comment] Thanks for the efforts on this specification. Thanks to Kyle Rose for his TSVART reviews, my understanding is those issues are not really transport related issues and has been addressed. I am think I am sympathetic to Ben's discuss but also understand this is well within the HSTS norms. I would be watching that discussion. I have only one question: My understanding on this specification is - if there is a record _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. then _foo.example.com must not have any ServiceMode SVCB record. is that correct? it was not so obvious to me. |
2022-03-02
|
08 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2022-03-01
|
08 | Benjamin Kaduk | [Ballot discuss] I'd like to have a (hopefully brief!) discussion about our description of the "strict transport security" functionality the HTTPS RRtype provides, with respect … [Ballot discuss] I'd like to have a (hopefully brief!) discussion about our description of the "strict transport security" functionality the HTTPS RRtype provides, with respect to its accuracty/completeness and how explicit vs implicit we should be about the corresponding divergence from "pure" HTTP behavior. It's pretty clear that at a pure HTTP protocol level (which as far as I can tell is the scope of applicability that we claim) that resources accessed with "http" scheme and resources accessed with "https" scheme have no intrinsic relationship -- §4.2.2 of draft-ietf-httpbis-semantics-19 says: Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces. [...] But the procedures in this document (e.g., §9.5, §9) seem pretty clear that, when an HTTPS record is published, accesses for "http" scheme resources should be converted to "https" scheme accesses, with implication that the client should expect to get the same resource back from the modified query compared to the unmodified "http"-scheme one. While there is a caution in §9.5 that: If this redirection would result in a loss of functionality (e.g. important resources that are only available on the "http" origin), the operator MUST NOT publish an HTTPS RR. but in my reading it leaves some important details as only implicit! We need to care not only about resources only available on one vs the other origin, but also about whether the translation would change the semantics of the client's request/response exchange. That is, whether the resources accessible by the different schemes are actually analogous (which, per the above, is not required by HTTP and is subject to the site administrator's control or in some cases other application protocols on top of HTTP used by that origin). This (mostly implicit) requirement is a potential barrier for adoption of the HTTPS RRtype, and while the precondition is very often going to be satisfied, I wanted to get a sense for whether we should make the requirement more explicit, and possibly more prominent in the document (e.g., mention it in the Introduction). I don't know what the right answer is, but it seems important enough to ensure that the topic receives deliberate consideration. |
2022-03-01
|
08 | Benjamin Kaduk | [Ballot comment] First off, thanks for this well-written document! It was pretty clear and easy to read despite covering some fairly complex logic. I made … [Ballot comment] First off, thanks for this well-written document! It was pretty clear and easy to read despite covering some fairly complex logic. I made a github pull request with some hopefully boring editorial suggestions: https://github.com/MikeBishop/dns-alt-svc/pull/365 I did have a few high-ish-level thoughts that I either wasn't sure where to put in the section-by-section comments or wanted to make a bit more prominent. The first is a bit hard for me to describe, but basically, when we construct a QNAME for an SVCB or HTTPS query, we include information reflecting URI scheme and port, but when we get a TargetName back, that's been flattened to a single name, in some sense "using up more" of the DNS hostname namespace under the control of the alternative endpoint then in the authority's namespace. That is, if I wanted to provide service for both "foo" and "bar" schemes on two ports each, in order to serve all four combinations for a single service name, I would need to allocate four hostnames for alternative endpoints. We do mention this property as it relates to URI schemes, in §11.1 where we say that "zone owners SHOULD choose alias target names that indicate the scheme in use", but I didn't see much discussion of the port-related aspects. I know that the ServiceMode response can include a port to use in the parameters, so it's not really a concern about losing flexibility of what ports to use. It just seems "unbalanced" in some sense that I can't really put my finger on. On the other hand, it's not like hostnames are a particularly limited resource, so I don't really see any practical consequences of this setup; I'm just curious if this is a topic that the WG gave much consideration to. I was also struck by the procedure near the end of §3 where we append to the very end of the priority list an endpoint specified by the final value of $QNAME combined with the port number from the (original) authority endpoint. This seems a strange combination, since the authority port number is chosen by the origin but the final QNAME will potentially be a service operator rather far removed from the origin. Making provision for what essentially requires a tight coupling between these entities (when non-default ports are used, at least) feels somewhat at odds with the stated goal of allowing delegation of operational authority that I take to imply a more "hands-off" or independently operated approach. While I understand the utility in picking a single port to use for this last-ditch entry on the priority list, it doesn't seem like the port from the original authority is the only choice. One might imagine using the default port for the scheme, or the last 'port' SvcParam encountered in alias chasing, or probably other things as well. I suspect there are some subtleties here, but I don't think I can think about it in much depth at the moment, so I hope that the WG has already undertaken such consideration. I found it a bit surprising (though well described and in that sense well justified) that we limit ourselves to using ALPN values for which the ALPN value uniquely identifies the suite of protocols to use, most notably relating to whether TLS or DTLS is used. That is not something I typically associate as being a property that ALPN provides, though as I look through the registry, almost all of the existing entries (that I know much about) do seem to provide that property. Do we know of any ALPN values that are unusable as a result of this restriction? I'm somewhat curious what the TLS DEs would say if faced with registration requests designed to "split" an existing ALPN registration so that it would be usable with SVCB. The registration procedure for the new Service Parameters registry (Section 15.3.1) starts off saying that it's FCFS, but accompanies that with a MUST-level requirement for "MUST specify how to convert the SvcParamValue's presentation format to wire format" (plus some MAYs as well). I'm somewhat surprised that IANA is willing to accept responsibility for assessing whether the "MUST specify..." has been met. Perhaps a policy of Expert Review with directions to the experts that allocations are "shall issue" provided the MUST is satisfied would be more appropriate? Section 1.2 In ServiceMode, the SvcParams of the SVCB RR provide an extensible data model for describing alternative endpoints that are authoritative for the origin, along with parameters associated with each of these alternative endpoints. (editorial) Since the term "origin" has a specific meaning in the HTTP context, and this document covers both the generic SVCB and the HTTP-specific HTTPS records, but this section is supposed to be the "generic" one, I wonder if we can come up with a different term than "origin" to use here. Would "service" or a derived term be consistent with our definitions? Section 2.1 The presentation format of the record is: Name TTL IN SVCB SvcPriority TargetName SvcParams The SVCB record is defined specifically within the Internet ("IN") Class ([RFC1035]). Should we say something about how "Name" and "TTL" have the same meaning as in RFC 1035? alpha-lc = %x61-7A ; a-z SvcParamKey = 1*63(alpha-lc / DIGIT / "-") SvcParam = SvcParamKey ["=" SvcParamValue] SvcParamValue = char-string value = *OCTET I'd suggest putting some comments in the ABNF that is defined in Appendix A and that and are related as described in the prose. Arbitrary keys can be represented using the unknown-key presentation format "keyNNNNN" where NNNNN is the numeric value of the key type without leading zeros. A SvcParam in this form SHALL be parsed as specified above, and the decoded value SHALL be used as its wire format encoding. Being SEC AD makes me think about edge cases a lot; do we want to say anything about whether a parser is required to be able to handle "keyNNNNN" for key types defined in this document? (Not that parsing DNS presentation format is the best thing to do in the first place, but it surely happens...) Section 2.4.2 The primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed. In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. (See Section 6 for aliasing of SVCB-compatible RR types.) The TargetName SHOULD NOT be equal to the owner name, as this would result in a loop. Why is this not a "MUST NOT"? Does it ever make sense to cause such a loop? Using AliasMode maintains a separation of concerns: the owner of foosvc.example.net can add or remove ServiceMode SVCB records without requiring a corresponding change to example.com. Note that if foosvc.example.net promises to always publish a SVCB record, this AliasMode record can be replaced by a CNAME, which would likely improve performance. So this would be "_8080._foo.example.com CNAME foosvc.example.net" rather than "example.com CNAME foosvc.example.net"? I wonder if clarifying that it's not "example.com CNAME foosvc.example.net" is worthwhile. Section 3.1 For a section titled "Handling resolution failures", perhaps we should also give guidance on how resolution failures should be handled when DNS responses are not cryptographically protected? (I assume "proceed to the fallback", but for completeness' sake...) Section 4.3 For complex value types whose interpretation might differ between implementations or have additional future allowed values added (e.g. URIs or "alpn"), resolvers SHOULD limit validation to specified constraints. I'm not entirely sure what "specified constraints" is intended to mean, here. Would it be those constrains specified as always suitable for validation in the document that defines the SvcParam in question, or something else? Section 5.2 As a performance optimization, if some of the SVCB records in the response can be used without requiring additional DNS queries, the client MAY prefer those records, regardless of their priorities. This might be a performance optimization for the initial connection setup while being a performance de-optimization for the actual application traffic that goes over the connection (i.e., the authoritative's priority values might be assumed to provide actual value to the user). Did the WG discuss whether or not to go into such subtleties here? Section 7.1.2 Clients SHOULD NOT attempt connection to a service endpoint whose SVCB ALPN set does not contain any supported protocols. To ensure consistency of behavior, clients MAY reject the entire SVCB RRSet and fall back to basic connection establishment if all of the RRs indicate "no-default-alpn", even if connection could have succeeded using a non-default alpn. (editorial) Just to confirm: these two directives are only related in that they cover client ALPN handling, and there is no expectation that the "MAY reject" is preconditioned on "SVCB ALPN set does not contain any supported protocols"? I might consider splitting into two paragraphs, even though my general preference is to avoid single-sentence paragraphs. Section 7.2 The "port" SvcParamKey defines the TCP or UDP port that should be used to reach this alternative endpoint. [...] Is this intentionally excluding SCTP/DCCP/etc? Section 9.3 Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish an "ech" SvcParam for any alt-authorities. [...] Just to confirm I'm understanding this properly: this is saying that if an origin publishes an HTTPS RR with an "ech" SvcParam (any single RR in the RRset suffices to trigger the condition), then the origin should also publish HTTPS records for any alt-authorities that it would send in an Alt-Svc header field, and those other HTTPS records should all include an "ech" SvcParam as well? I'm a little confused at why the RFC 7838 "alt-authorities" keyword is used here without any specific reference to Alt-Svc itself. (There are only three instances of the string "alt-authorit" in this document, two of which are in this paragraph; the third is clearly marked as applying to the Alt-Svc usage.) Section 9.4 Clients MUST NOT use an HTTPS RR response unless the client supports TLS Server Name Indication (SNI) and indicates the origin name when negotiating TLS. This supports the conservation of IP addresses. I could sort-of see a misreading of this that says you have to put the real origin in the SNI extension and not use ECH with a separate fronting origin. Maybe we want to say something about "uses SNI (possibly in conjunction with ECH) to indicate the origin name"? Section 11.2 queries for TargetName in advance (see Section 5). Unless otherwise specified, the convention is to set TargetName to the service name for an initial ServiceMode record, or to "." if it is reached via an alias. For foo://foo.example.com:8080, this might look like: I think it would be helpful to show an example of the "set TargetName to the service name for an initial ServiceMode record" in addition to the alias example that is shown. Section 11.3.3 Suppose that svc.example's default server pool supports HTTP/2, and it has deployed HTTP/3 on a new server pool with a different configuration. This can be expressed in the following form: $ORIGIN svc.example. ; A hosting provider. pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..." The prose suggests that perhaps the new pool is h3-only and doesn't support HTTP/2, but the actual example lists both alpn values. I guess it also omits no-default-alpn, so the new pool actually supports all three http versions... Section 11.3.4 * The A, AAAA, and HTTPS resolutions are independent lookups, so clients may observe and follow different CNAMEs to different CDNs. Clients may thus find a TargetName pointing to a name other than the one which returned along with the A and AAAA lookups and will need to do an additional resolution for them. [...] (editorial) I think something went awry near "the one which returned along with", as it's not even clear whether there are separate queries vs additional-section responses in the intended scenario. Section 13 Do we want to mention the discussion in §3.2 about using caution in resolving SVCB when using a proxy? I note that draft-ietf-tls-esni has a note (its §10.2) explaining that DNSSEC or other protection is not really needed for ECH config, since an attacker that controls DNS can already defeat ECH protections. Do we want to include similar discussion or otherwise mention this topic (e.g., by reference)? Section 15.3.2 | 65535 | N/A | Reserved | (This document) | | | | ("Invalid | | | | | key") | | Do we care that 'I' is not a lowercase letter? Section 15.4 I always worry somewhat when we propose a new mechanism with no worked examples for it (in this case, protocols using SVCB per the "MUST have an entry for its scheme" requirement in §12). Perhaps the HTTPS example is close enough that my worries are groundless. Section 17.1 Why is [DNAME] classified as normative? I only see one reference to it, in a list of examples of possible ways that resolvers might follow aliases, which does not seem like a "protocol feature" of this document. I could also perhaps see an argument that references to [HSTS] are just by way of analogy or indicating that we provide equivalent behavior, which would not seem to require the reader to understand [HSTS] in order to implement this specification. RFC 6147 is referenced only as part of a "MUST NOT perform DNS64" construction, which seems to indicate that it is *not* a normative reference. Appendix D.2 [I did not carefully review the examples for internal consistency, trusting that this document has received ample review already.] |
2022-03-01
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2022-03-01
|
08 | Martin Duke | [Ballot comment] To this DNS non-expert, I found it hard to follow the motivation for AliasMode. In particular, I asked myself the following questions that … [Ballot comment] To this DNS non-expert, I found it hard to follow the motivation for AliasMode. In particular, I asked myself the following questions that could have been answered in the Introduction or in (2.4.2): - Why is it not OK for a CNAME to alias the apex, but OK for AliasMode to do so? [having asked around, it's because CNAME aliases all the record types, which is nonsensical for the apex, and AliasMode does not] - For non-apex domains, under what conditions would I use AliasMode instead of a CNAME? Is it just when I don't want to bring along record types besides A, AAAA, and SVCB? |
2022-03-01
|
08 | Martin Duke | Ballot comment text updated for Martin Duke |
2022-02-28
|
08 | Martin Duke | [Ballot comment] Two things I found confusing: (Sec 2.4.2) "Note that if foosvc.example.net promises to always publish a SVCB record, this AliasMode record can be … [Ballot comment] Two things I found confusing: (Sec 2.4.2) "Note that if foosvc.example.net promises to always publish a SVCB record, this AliasMode record can be replaced by a CNAME..." I'm not following the logic here. Why would it be insufficient for foosvc.example.net to always publish A and/or AAAA records? Put another way, how does AliasMode improve on CNAME for non-apex domains? (Sec 3) I found this paragraph confusing: "Once SVCB resolution has concluded, whether successful or not, SVCB-optional clients SHALL append to the priority list an endpoint consisting of the final value of $QNAME, the authority endpoint's port number, and no SvcParams. (This endpoint will be attempted before falling back to non-SVCB connection modes. This ensures that SVCB-optional clients will make use of an AliasMode record whose TargetName has A and/or AAAA records but no SVCB records.)" There are three resolution outcomes AFAICT: (a) A successful resolution in ServiceMode, in which case there is indeed an existing "priority list" but there is no AliasMode record to leverage. So what does the parenthetical refer to? (b) A successful resolution in AliasMode, in which case the client has no priority list to work through, and should just connect to $QNAME. (c) Unsuccessful resolution, in which case $QNAME is the original service name, which would then have to use a non-SVCB connection mode. Editorially, this paragraph seems to unhelpfully combine three quite distinct outcomes into a single model. Or perhaps I've totally misunderstood it, which is maybe worse? |
2022-02-28
|
08 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2022-02-28
|
08 | Roman Danyliw | [Ballot comment] Thanks to Kyle Rose for the security feedback in the TSVART review. ** Section 2.1. Per the ABNF (with the caveat that my … [Ballot comment] Thanks to Kyle Rose for the security feedback in the TSVART review. ** Section 2.1. Per the ABNF (with the caveat that my manual review of such syntax might be rusty): -- What role does “value = *OCTET” play in the specification of SvcParams? It doesn’t appear to be used or explained. -- Should a top-level ‘SvcParams’ rule be defined (i.e., define the formal syntax of the entire parameter which is a list of SvcParam)? -- (Editorial) To make it clear that “char-string” is defined in Appendix A, it would be helpful to: OLD SvcParamValue = char-string NEW SvcParamValue = char-string ; per Appendix A ** Section 3.1. Recommend explicit saying which connection should be abandoned – s/the client SHOULD abandon the connection attempt/the client SHOULD abandon the connection attempt to the target service/ ** Section 7.4. Unpacking the first paragraph for easier commentary: (a) The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. (b) If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. (c) Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName as in Section 3, and clients SHOULD use the IP address in those responses for future connections. (a) seems to be saying that the value of the SrcParamValue is going to return an IP address associated with a TargetName. (b) seems to be saying that if the client already has an IP address for the TargetName in the cache, then ignore the hints. Per (c), why would A/AAAA queries need to be performed to resolve TargetName? Isn’t the hint the associated IP address? ** Section 9.3. Editorial. s/the the/the/ ** Section 10. Editorial. s/the value of the parameter is an ECHConfigList [ECH]/ the value of the parameter is an ECHConfigList per Section 4 of [ECH] ** Section 10. Editorial. s/ProtocolNameList in Section 7.1/ ProtocolNameList in Section 7.1.2/ ** Section 10.2. s/smaller SvcPriority/lower SvcPriority value/ ** Section A.1 Per the ABNF: -- What role does “item” rule play? It’s not referenced or explained. (see below) -- It would be useful to state somewhere which ABNF rule corresponds to which form of the list. Perhaps something like: OLD For implementations that allow "," and "\" in item values, the following escaping syntax applies: NEW For implementations that allow "," and "\" in item values, the ‘comma-separated’ rule for the escaping syntax applies. For those that do not required escaping, the ‘item’ syntax rule applies. |
2022-02-28
|
08 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2022-02-28
|
08 | Roman Danyliw | [Ballot comment] Thanks to Kyle Rose for the security feedback in the TSVART review. ** Section 2.1. Per the ABNF (with the caveat that my … [Ballot comment] Thanks to Kyle Rose for the security feedback in the TSVART review. ** Section 2.1. Per the ABNF (with the caveat that my manually review of such syntax might be rusty): -- What role does “value = *OCTET” play in the specification of SvcParams? It doesn’t appear to be used or explained. -- Should a top-level ‘SvcParams’ rule be defined (i.e., define the formal syntax of the entire parameter which is a list of SvcParam)? -- (Editorial) To make it clear that “char-string” is defined in Appendix A, it would be helpful to: OLD SvcParamValue = char-string NEW SvcParamValue = char-string ; per Appendix A ** Section 3.1. Recommend explicit saying which connection should be abandoned – s/the client SHOULD abandon the connection attempt/the client SHOULD abandon the connection attempt to the target service/ ** Section 7.4. Unpacking the first paragraph for easier commentary: (a) The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. (b) If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. (c) Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName as in Section 3, and clients SHOULD use the IP address in those responses for future connections. (a) seems to be saying that the value of the SrcParamValue is going to return an IP address associated with a TargetName. (b) seems to be saying that if the client already has an IP address for the TargetName in the cache, then ignore the hints. Per (c), why would A/AAAA queries need to be performed to resolve TargetName? Isn’t the hint the associated IP address? ** Section 9.3. Editorial. s/the the/the/ ** Section 10. Editorial. s/the value of the parameter is an ECHConfigList [ECH]/ the value of the parameter is an ECHConfigList per Section 4 of [ECH] ** Section 10. Editorial. s/ProtocolNameList in Section 7.1/ ProtocolNameList in Section 7.1.2/ ** Section 10.2. s/smaller SvcPriority/lower SvcPriority value/ ** Section A.1 Per the ABNF: -- What role does “item” rule play? It’s not referenced or explained. (see below) -- It would be useful to state somewhere which ABNF rule corresponds to which form of the list. Perhaps something like: OLD For implementations that allow "," and "\" in item values, the following escaping syntax applies: NEW For implementations that allow "," and "\" in item values, the ‘comma-separated’ rule for the escaping syntax applies. For those that do not required escaping, the ‘item’ syntax rule applies. |
2022-02-28
|
08 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2022-02-28
|
08 | Lars Eggert | [Ballot comment] Thanks to Dale Worley for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/ctABeNgyI1ywOHNXs17ZO07rLFY). ------------------------------------------------------------------------------- All comments below are about very minor … [Ballot comment] Thanks to Dale Worley for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/ctABeNgyI1ywOHNXs17ZO07rLFY). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". "Table of Contents", paragraph 2, nit: > iding transient connections to a sub-optimal default server, negotiating a pr > ^^^^^^^^^^^ This word is normally spelled as one. Section 2.4.2. , paragraph 10, nit: > its SvcParams all comply with each others' requirements. Zone-file implement > ^^^^^^^ Did you mean "other's"? Section 3.2. , paragraph 2, nit: > ons. 4.2. Recursive resolvers Whether or not the recursive resolver is aware > ^^^^^^^^^^^^^^ Consider shortening this phrase to just "Whether". It is correct though if you mean "regardless of whether". Section 9.1. , paragraph 5, nit: > o alt3.example:9443 * Fallback to the the client's non-Alt-Svc connection beh > ^^^^^^^ Possible typo: you repeated a word. Section 9.3. , paragraph 2, nit: > rtext HTTP. If this redirection would result in a loss of functionality (e.g > ^^^^^^^^^^^^ Consider removing "would". (Usually, "would" does not occur in a conditional clause, unless to make a request or give a polite order.). Section 12. , paragraph 3, nit: > his registry are subject to a First Come First Served registration policy ([ > ^^^^ It seems that a comma is missing. "D.2. ", paragraph 14, nit: > fy the IANA instructions (pure First Come First Served) - Recommend against > ^^^^ It seems that a comma is missing. Document references draft-ietf-tls-esni-13, but -14 is the latest available revision. |
2022-02-28
|
08 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2022-02-24
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-01-31
|
08 | Carlos Bernardos | Request for Telechat review by INTDIR is assigned to Suresh Krishnan |
2022-01-31
|
08 | Carlos Bernardos | Request for Telechat review by INTDIR is assigned to Suresh Krishnan |
2022-01-31
|
08 | Éric Vyncke | Requested Telechat review by INTDIR |
2022-01-31
|
08 | Cindy Morgan | Placed on agenda for telechat - 2022-03-03 |
2022-01-31
|
08 | Warren Kumari | For some reason this was stuck in IESG Eval state for a long time: "2021-10-13 13:33:45 -0700 -08 Warren Kumari IESG state changed to IESG … For some reason this was stuck in IESG Eval state for a long time: "2021-10-13 13:33:45 -0700 -08 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead". I've done a bunch of archeology to see if I can figure out what, if anything, it was waiting on, but have had no luck finding anything, so ¯\_(ツ)_/¯. I'm poking all of the buttons and twiddling all the knobs to see if I can make it move... |
2022-01-31
|
08 | Warren Kumari | Ballot has been issued |
2022-01-31
|
08 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2022-01-31
|
08 | Warren Kumari | Created "Approve" ballot |
2021-10-13
|
08 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
2021-10-13
|
08 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2021-10-12
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-10-12
|
08 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-08.txt |
2021-10-12
|
08 | (System) | New version approved |
2021-10-12
|
08 | (System) | Request for posting confirmation emailed to previous authors: Benjamin Schwartz , Erik Nygren , Mike Bishop |
2021-10-12
|
08 | Benjamin Schwartz | Uploaded new revision |
2021-09-15
|
07 | Warren Kumari | Changed action holders to Erik Nygren, Mike Bishop, Benjamin Schwartz (Waiting on update from authors. Ben (Aug 23rd): "FYI, we've received good feedback from area … Changed action holders to Erik Nygren, Mike Bishop, Benjamin Schwartz (Waiting on update from authors. Ben (Aug 23rd): "FYI, we've received good feedback from area reviews, and are planning a -08 to incorporate those improvements. We probably shouldn't proceed to IESG review until after those changes are published.") |
2021-08-31
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2021-08-31
|
07 | Amanda Baber | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2021-08-23
|
07 | Warren Kumari | IESG state changed to Waiting for AD Go-Ahead from IESG Evaluation |
2021-08-23
|
07 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2021-08-19
|
07 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-08-17
|
07 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2021-08-17
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-08-17
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-svcb-https-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-svcb-https-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. We understand that, upon approval of this document, there are three actions which we must complete. First, in the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ two existing registrations will be changed as follows: TYPE: SVCB Value: 64 Meaning: General Purpose Service Endpoints Reference: [ RFC-to-be ] TYPE: HTTPS Value: 65 Meaning: HTTPS Specific Service Endpoints Reference: [ RFC-to-be ] The YANG module [iana-dns-class-rr-type] must be updated as defined in [RFC-ietf-dnsop-iana-class-type-yang-05]. IANA Question --> The entries in Section 14.4 (Table 2) appear to have the same "TYPE" and registry as sections 14.1 and 14.2. Are these duplicates, or are they supposed to be new registrations? If these are duplicates, how should we update the "Meaning" field? Second, a new registry is to be created called the Service Binding (SVCB) Parameter Registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The registry is managed via First Come, First Served as defined in RFC8126 for values between 0 and 65279. Values from 65280 to 65534 are used for Private Use as defined in RFC8126. Value 65535 is reserved. There are initial registrations in the new registry as follows: +=============+=================+================+=================+ | Number | Name | Meaning | Format | | | | | Reference | +=============+=================+================+=================+ | 0 | mandatory | Mandatory keys | [ RFC-to-be ] | | | | in this RR | Section 7 | +-------------+-----------------+----------------+-----------------+ | 1 | alpn | Additional | [ RFC-to-be ] | | | | supported | Section 6.1 | | | | protocols | | +-------------+-----------------+----------------+-----------------+ | 2 | no-default-alpn | No support for | [ RFC-to-be ] | | | | default | Section 6.1 | | | | protocol | | +-------------+-----------------+----------------+-----------------+ | 3 | port | Port for | [ RFC-to-be ] | | | | alternative | Section 6.2 | | | | endpoint | | +-------------+-----------------+----------------+-----------------+ | 4 | ipv4hint | IPv4 address | [ RFC-to-be ] | | | | hints | Section 6.4 | +-------------+-----------------+----------------+-----------------+ | 5 | ech | Encrypted | [ RFC-to-be ] | | | | ClientHello | Section 6.3 | | | | info | | +-------------+-----------------+----------------+-----------------+ | 6 | ipv6hint | IPv6 address | [ RFC-to-be ] | | | | hints | Section 6.4 | +-------------+-----------------+----------------+-----------------+ | 65280-65534 | N/A | Private Use | [ RFC-to-be ] | +-------------+-----------------+----------------+-----------------+ | 65535 | N/A | Reserved | [ RFC-to-be ] | | | | ("Invalid | | | | | key") | | +-------------+-----------------+----------------+-----------------+ Third, in the Underscored and Globally Scoped DNS Node Names registry also on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ a new registration is to be made as follows: RR Type: HTTPS NODE NAME: _https Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." The IANA Functions Operator understands that these are the only actions required to be completed 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 meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-08-17
|
07 | Kyle Rose | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Kyle Rose. Sent review to list. |
2021-08-16
|
07 | Joe Clarke | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joe Clarke. Sent review to list. |
2021-08-14
|
07 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dale Worley. Sent review to list. |
2021-08-13
|
07 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Kyle Rose |
2021-08-13
|
07 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Kyle Rose |
2021-08-13
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2021-08-13
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2021-08-12
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2021-08-12
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2021-08-09
|
07 | Tim Wicinski | Changed document external resources from: None to: github_repo https://github.com/MikeBishop/dns-alt-svc |
2021-08-09
|
07 | Cullen Jennings | Request for Last Call review by ARTART Completed: Ready. Reviewer: Cullen Jennings. Sent review to list. |
2021-08-07
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Cullen Jennings |
2021-08-07
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Cullen Jennings |
2021-08-05
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2021-08-05
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2021-08-05
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-08-05
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-08-19): From: The IESG To: IETF-Announce CC: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, … The following Last Call announcement was sent out (ends 2021-08-19): From: The IESG To: IETF-Announce CC: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-svcb-https@ietf.org, tjw.ietf@gmail.com, warren@kumari.net Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' 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 last-call@ietf.org mailing lists by 2021-08-19. 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 specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7871: Client Subnet in DNS Queries (Informational - Internet Engineering Task Force (IETF)) draft-ietf-tls-esni: TLS Encrypted Client Hello (None - Internet Engineering Task Force (IETF)) |
2021-08-05
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-08-05
|
07 | Warren Kumari | Last call was requested |
2021-08-05
|
07 | Warren Kumari | Last call announcement was generated |
2021-08-05
|
07 | Warren Kumari | Ballot approval text was generated |
2021-08-05
|
07 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
2021-08-05
|
07 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
2021-08-05
|
07 | Warren Kumari | Ballot writeup was changed |
2021-08-05
|
07 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-07.txt |
2021-08-05
|
07 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2021-08-05
|
07 | Benjamin Schwartz | Uploaded new revision |
2021-07-14
|
06 | Tim Wicinski | Tag Revised I-D Needed - Issue raised by WG cleared. |
2021-07-14
|
06 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record … (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary: Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records. The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule. Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/ WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/ Document Quality: While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) == Outdated reference: A later version (-12) exists of draft-ietf-tls-esni-11 ** Downref: Normative reference to an Informational RFC: RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) (12) No formal review needed (13) All references have been identified as normative or informative. (14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement. (15) There is one downward normative reference to RFC 7871, which has one existing downward reference. (16) This RFC will not change any existing RFCs. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews. (19) N/A (20) No Yang Necessary |
2021-07-14
|
06 | Tim Wicinski | Responsible AD changed to Warren Kumari |
2021-07-14
|
06 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-07-14
|
06 | Tim Wicinski | IESG state changed to Publication Requested from I-D Exists |
2021-07-14
|
06 | Tim Wicinski | IESG process started in state Publication Requested |
2021-07-14
|
06 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record … (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary: Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records. The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule. Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/ WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/ Document Quality: While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) == Outdated reference: A later version (-12) exists of draft-ietf-tls-esni-11 ** Downref: Normative reference to an Informational RFC: RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) (12) No formal review needed (13) All references have been identified as normative or informative. (14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement. (15) There is one downward normative reference to RFC 7871, which has one existing downward reference. (16) This RFC will not change any existing RFCs. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews. (19) N/A (20) No Yang Necessary |
2021-07-14
|
06 | Tim Wicinski | (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record … (1) RFC is Standards Track, and this is the correct RFC type. (2) Technical Summary: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary: Working group consensus was strong. Document Quality: While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (pelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very solid. (10) There has been no appeals. (11) == Outdated reference: A later version (-12) exists of draft-ietf-tls-esni-11 ** Downref: Normative reference to an Informational RFC: RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) (12) No formal review needed (13) All references have been identified as normative or informative. (14) There is one normative reference for draft-ietf-tls-esni, that is not ready for advancement. (15) There is one downward normative reference to RFC 7871, which has one existing downward reference. (16) This RFC will not change any existing RFCs. (17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is created as a First Come First Serve, and does not require any Expert Reviews. (19) N/A (20) No Yang Necessary |
2021-06-16
|
06 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-06.txt |
2021-06-16
|
06 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2021-06-16
|
06 | Benjamin Schwartz | Uploaded new revision |
2021-05-19
|
05 | Tim Wicinski | Tag Revised I-D Needed - Issue raised by WG set. |
2021-05-19
|
05 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-04-21
|
05 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-05.txt |
2021-04-21
|
05 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2021-04-21
|
05 | Benjamin Schwartz | Uploaded new revision |
2021-03-18
|
04 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2021-03-18
|
04 | Tim Wicinski | Changed consensus to Yes from Unknown |
2021-03-18
|
04 | Tim Wicinski | Intended Status changed to Proposed Standard from None |
2021-03-17
|
04 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-04.txt |
2021-03-17
|
04 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2021-03-17
|
04 | Benjamin Schwartz | Uploaded new revision |
2021-02-17
|
03 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-03.txt |
2021-02-17
|
03 | (System) | New version approved |
2021-02-17
|
03 | (System) | Request for posting confirmation emailed to previous authors: Benjamin Schwartz , Erik Nygren , Mike Bishop |
2021-02-17
|
03 | Benjamin Schwartz | Uploaded new revision |
2020-11-02
|
02 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-02.txt |
2020-11-02
|
02 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2020-11-02
|
02 | Benjamin Schwartz | Uploaded new revision |
2020-09-06
|
01 | Tim Wicinski | Notification list changed to Tim Wicinski <tjw.ietf@gmail.com> |
2020-09-06
|
01 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2020-07-22
|
01 | Tim Wicinski | Added to session: IETF-108: dnsop Wed-1100 |
2020-07-13
|
01 | Benjamin Schwartz | This document now replaces draft-ietf-dnsop-svcb-httpssvc instead of draft-ietf-dnsop-svcb-httpssvc |
2020-07-13
|
01 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-01.txt |
2020-07-13
|
01 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2020-07-13
|
01 | Benjamin Schwartz | Uploaded new revision |
2020-06-12
|
00 | Benjamin Schwartz | This document now replaces draft-ietf-dnsop-svcb-httpssvc instead of None |
2020-06-12
|
00 | Benjamin Schwartz | New version available: draft-ietf-dnsop-svcb-https-00.txt |
2020-06-12
|
00 | (System) | New version accepted (logged-in submitter: Benjamin Schwartz) |
2020-06-12
|
00 | Benjamin Schwartz | Uploaded new revision |