[dns-privacy] [IANA #1223683] Re: Last Call: (DNS over Dedicated QUIC Connections) to Proposed Standard
Hi Christian,
These changes look good. Thank you!
Best regards,
Sabrina Tanamal
Lead IANA Services Specialist
On Tue Jan 25 20:55:17 2022, huit...@huitema.net wrote:
> Hello Sabrina,
>
> Yes, reading the section 10.2 again, I see that there is some leftover
> text from previous iterations, and it creates confusion. I just
> proposed
> a set of changes on our github repo --
> https://github.com/huitema/dnsoquic/pull/140. The changes affet
> section
> 10.2 as follow:
>
> 1) Remove the line "IANA responded to the early allocation request
> with
> the following TEMPORARY assignment:", since IANA did not do anything
> like that.
>
> 2) Remove the line "The TEMPORARY assignment expires 13th December
> 2022." There is no such temporary assignment.
>
> 3) Delete section 10.2.1, which was already slated for removal. This
> removes the confusing references to port number 784.
>
> Would that address your concerns?
>
> -- Christian Huitema
>
>
> On 1/25/2022 9:36 AM, Sabrina Tanamal via RT wrote:
> > Hi Christian,
> >
> > See [ST] below.
> >
> > On Tue Jan 25 02:04:28 2022,huit...@huitema.net wrote:
> >> On 1/24/2022 8:39 AM, Sabrina Tanamal via RT wrote:
> >>> (BEGIN IANA COMMENTS)
> >>>
> >>> IESG/Authors/WG Chairs:
> >>>
> >>> The IANA Functions Operator has completed its review of draft-ietf-
> >>> dprive-dnsoquic-08. 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.
> >>>
> >>> The IANA Functions Operator understands that, upon approval of this
> >>> document, there are four actions which we must complete.
> >>>
> >>> First, in the TLS Application-Layer Protocol Negotiation (ALPN)
> >>> Protocol IDs registry on the Transport Layer Security (TLS)
> >>> Extensions registry page located at:
> >>>
> >>> https://www.iana.org/assignments/tls-extensiontype-values/
> >> The registry is located at:
> >> https://www.iana.org/assignments/tls-extensiontype-values/tls-
> >> extensiontype-values.xhtml#alpn-protocol-ids.
> >>
> >> That registry is under the title "TLS Application-Layer Protocol
> >> Negotiation (ALPN) Protocol IDs"
> >>
> >>> a new registration is to be made as follows:
> >>>
> >>> Protocol: DoQ
> >>> Identification Sequence: 0x64 0x6F 0x71 ("doq")
> >>> 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."
> >>>
> >>> Second, we will update the description and list this document as an
> >>> additional reference for UDP port 853:
> >>>
> >>> Service Name: domain-s
> >>> Port Number: 853
> >>> Transport Protocol(s): UDP
> >>> Assignee: IETF DPRIVE Chairs
> >>> Contact: Brian Haberman
> >>> Description: DNS query-response protocol run over DTLS or QUIC
> >>> Reference: [RFC7858][RFC8094] This document
> >>>
> >>> In addition, the Description field for the corresponding TCP port
> >>> 853
> >>> allocation will be changed to 'DNS query-response protocol run over
> >>> TLS'.
> >>>
> >>> IANA Question: We understand from Section 8.1.1 of RFC 6335 that
> >>> the
> >>> IESG should be listed as the assignee and the IETF Chair as the
> >>> contact for an IETF-stream document. Can you confirm that this is
> >>> correct?
> >> Yes.
> >>> IANA Question: Since we didn't make a temporary early allocation
> >>> request for the above port, can the early allocation language be
> >>> removed from the document? We will make the changes as agreed with
> >>> the port experts when the document is approved for publication.
> >> Please explain what you mean by "the early allocation language."
> > [ST] Section 10.2 says, “IANA responded to the early allocation
> > request with the following TEMPORARY assignment:” and states that the
> > allocation expires on 13 December 2022. However, on 13 December 2021,
> > the determination by the port experts was that the existing port
> > would be modified when the document was approved for publication, not
> > that an early allocation or modification would be made. Can this
> > section be rewritten to reflect that a modification is being
> > requested by the document?
> >
> >>> IANA notes that section 10.2.1 contains notes for implementer of
> >>> early experiments and no instructions for IANA.
> >> Section 10.2.1. should be removed once the allocation is done. The
> >> text
> >> says "(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE
> >> PUBLICATION)".
> >> It might have been better to describe an IANA action rather than at
> >> RFC
> >> EDITOR action, but the intent is clear.
> > [ST] If a port allocation is required here, please clarify what the
> > IANA actions should be.
> >
> > Thank you,
> >
> > Sabrina Tanamal
> > Lead IANA Services Specialist
> >
>
Re: [dns-privacy] [IANA #1223683] Re: Last Call: (DNS over Dedicated QUIC Connections) to Proposed Standard
Hello Sabrina,
Yes, reading the section 10.2 again, I see that there is some leftover
text from previous iterations, and it creates confusion. I just proposed
a set of changes on our github repo --
https://github.com/huitema/dnsoquic/pull/140. The changes affet section
10.2 as follow:
1) Remove the line "IANA responded to the early allocation request with
the following TEMPORARY assignment:", since IANA did not do anything
like that.
2) Remove the line "The TEMPORARY assignment expires 13th December
2022." There is no such temporary assignment.
3) Delete section 10.2.1, which was already slated for removal. This
removes the confusing references to port number 784.
Would that address your concerns?
-- Christian Huitema
On 1/25/2022 9:36 AM, Sabrina Tanamal via RT wrote:
Hi Christian,
See [ST] below.
On Tue Jan 25 02:04:28 2022,huit...@huitema.net wrote:
On 1/24/2022 8:39 AM, Sabrina Tanamal via RT wrote:
(BEGIN IANA COMMENTS)
IESG/Authors/WG Chairs:
The IANA Functions Operator has completed its review of draft-ietf-
dprive-dnsoquic-08. 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.
The IANA Functions Operator understands that, upon approval of this
document, there are four actions which we must complete.
First, in the TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs registry on the Transport Layer Security (TLS)
Extensions registry page located at:
https://www.iana.org/assignments/tls-extensiontype-values/
The registry is located at:
https://www.iana.org/assignments/tls-extensiontype-values/tls-
extensiontype-values.xhtml#alpn-protocol-ids.
That registry is under the title "TLS Application-Layer Protocol
Negotiation (ALPN) Protocol IDs"
a new registration is to be made as follows:
Protocol: DoQ
Identification Sequence: 0x64 0x6F 0x71 ("doq")
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."
Second, we will update the description and list this document as an
additional reference for UDP port 853:
Service Name: domain-s
Port Number: 853
Transport Protocol(s): UDP
Assignee: IETF DPRIVE Chairs
Contact: Brian Haberman
Description: DNS query-response protocol run over DTLS or QUIC
Reference: [RFC7858][RFC8094] This document
In addition, the Description field for the corresponding TCP port 853
allocation will be changed to 'DNS query-response protocol run over
TLS'.
IANA Question: We understand from Section 8.1.1 of RFC 6335 that the
IESG should be listed as the assignee and the IETF Chair as the
contact for an IETF-stream document. Can you confirm that this is
correct?
Yes.
IANA Question: Since we didn't make a temporary early allocation
request for the above port, can the early allocation language be
removed from the document? We will make the changes as agreed with
the port experts when the document is approved for publication.
Please explain what you mean by "the early allocation language."
[ST] Section 10.2 says, “IANA responded to the early allocation request with
the following TEMPORARY assignment:” and states that the allocation expires on
13 December 2022. However, on 13 December 2021, the determination by the port
experts was that the existing port would be modified when the document was
approved for publication, not that an early allocation or modification would be
made. Can this section be rewritten to reflect that a modification is being
requested by the document?
IANA notes that section 10.2.1 contains notes for implementer of
early experiments and no instructions for IANA.
Section 10.2.1. should be removed once the allocation is done. The
text
says "(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE
PUBLICATION)".
It might have been better to describe an IANA action rather than at
RFC
EDITOR action, but the intent is clear.
[ST] If a port allocation is required here, please clarify what the IANA
actions should be.
Thank you,
Sabrina Tanamal
Lead IANA Services Specialist
Third, in the Extended DNS Error Codes registry on the Domain Name
System (DNS) Parameters registry page located at:
https://www.iana.org/assignments/dns-parameters/
a new registration will be made as follows:
INFO-CODE: [ TBD-at-Registration ]
Purpose: Too Early
Reference: [ RFC-to-be ]
Yes.
Fourth, a new registry is to be created called the DNS over QUIC
Error Codes registry. The new registry will be located on the Domain
Name System (DNS) Parameters registry page located at:
https://www.iana.org/assignments/dns-parameters/
The registration rules for the new registry are:
0x00 - 0x3f require Standards Action or IESG Approval
Permanent registrations for values larger than 0x3f, which are
[dns-privacy] [IANA #1223683] Re: Last Call: (DNS over Dedicated QUIC Connections) to Proposed Standard
Hi Christian,
See [ST] below.
On Tue Jan 25 02:04:28 2022, huit...@huitema.net wrote:
>
> On 1/24/2022 8:39 AM, Sabrina Tanamal via RT wrote:
> > (BEGIN IANA COMMENTS)
> >
> > IESG/Authors/WG Chairs:
> >
> > The IANA Functions Operator has completed its review of draft-ietf-
> > dprive-dnsoquic-08. 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.
> >
> > The IANA Functions Operator understands that, upon approval of this
> > document, there are four actions which we must complete.
> >
> > First, in the TLS Application-Layer Protocol Negotiation (ALPN)
> > Protocol IDs registry on the Transport Layer Security (TLS)
> > Extensions registry page located at:
> >
> > https://www.iana.org/assignments/tls-extensiontype-values/
>
> The registry is located at:
> https://www.iana.org/assignments/tls-extensiontype-values/tls-
> extensiontype-values.xhtml#alpn-protocol-ids.
>
> That registry is under the title "TLS Application-Layer Protocol
> Negotiation (ALPN) Protocol IDs"
>
> >
> > a new registration is to be made as follows:
> >
> > Protocol: DoQ
> > Identification Sequence: 0x64 0x6F 0x71 ("doq")
> > 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."
> >
> > Second, we will update the description and list this document as an
> > additional reference for UDP port 853:
> >
> > Service Name: domain-s
> > Port Number: 853
> > Transport Protocol(s): UDP
> > Assignee: IETF DPRIVE Chairs
> > Contact: Brian Haberman
> > Description: DNS query-response protocol run over DTLS or QUIC
> > Reference: [RFC7858][RFC8094] This document
> >
> > In addition, the Description field for the corresponding TCP port 853
> > allocation will be changed to 'DNS query-response protocol run over
> > TLS'.
> >
> > IANA Question: We understand from Section 8.1.1 of RFC 6335 that the
> > IESG should be listed as the assignee and the IETF Chair as the
> > contact for an IETF-stream document. Can you confirm that this is
> > correct?
> Yes.
> > IANA Question: Since we didn't make a temporary early allocation
> > request for the above port, can the early allocation language be
> > removed from the document? We will make the changes as agreed with
> > the port experts when the document is approved for publication.
> Please explain what you mean by "the early allocation language."
[ST] Section 10.2 says, “IANA responded to the early allocation request with
the following TEMPORARY assignment:” and states that the allocation expires on
13 December 2022. However, on 13 December 2021, the determination by the port
experts was that the existing port would be modified when the document was
approved for publication, not that an early allocation or modification would be
made. Can this section be rewritten to reflect that a modification is being
requested by the document?
> > IANA notes that section 10.2.1 contains notes for implementer of
> > early experiments and no instructions for IANA.
>
> Section 10.2.1. should be removed once the allocation is done. The
> text
> says "(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE
> PUBLICATION)".
> It might have been better to describe an IANA action rather than at
> RFC
> EDITOR action, but the intent is clear.
[ST] If a port allocation is required here, please clarify what the IANA
actions should be.
Thank you,
Sabrina Tanamal
Lead IANA Services Specialist
> > Third, in the Extended DNS Error Codes registry on the Domain Name
> > System (DNS) Parameters registry page located at:
> >
> > https://www.iana.org/assignments/dns-parameters/
> >
> > a new registration will be made as follows:
> >
> > INFO-CODE: [ TBD-at-Registration ]
> > Purpose: Too Early
> > Reference: [ RFC-to-be ]
> Yes.
> >
> > Fourth, a new registry is to be created called the DNS over QUIC
> > Error Codes registry. The new registry will be located on the Domain
> > Name System (DNS) Parameters registry page located at:
> >
> > https://www.iana.org/assignments/dns-parameters/
> >
> > The registration rules for the new registry are:
> >
> > 0x00 - 0x3f require Standards Action or IESG Approval
> >
> > Permanent registrations for values larger than 0x3f, which are
> > assigned using the Specification Required policy (as defined in
> > [RFC8126])
> >
> > Provisional registrations for values larger than 0x3f, which require
> > Expert Review, as defined in Section 4.5 of [RFC8126].
> >
> > There are initial registrations in the new registry as follows:
> >
> > +==+===+++
> > |Value | Error |Description | Specification |
> >
Re: [dns-privacy] Will unilateral-probing "poison the well"?
On Sun 2021-12-12 07:58:08 -0500, Robert Evans wrote: > Yes. It is reasonable to leave room for clients to validate for measurement > or analysis purposes that have no effect on authoritative operators. > > Perhaps you can consider changing the "SHOULD NOT" in that section to "MUST > NOT". > > Or perhaps it would be better to reframe this section as "MUST accept any > certificate presented" rather than framing this around MAY validate and > MUST NOT reject invalid certs. Thanks for this suggestion, Robert. I'm proposing the attached change to address it. Joey and I are trying to push out a draft -02 soon, and it should be included in that revision. --dkg From 0e05878a7814100a994e38515a33f3dc280b0354 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 25 Jan 2022 11:08:11 -0500 Subject: [PATCH] Clarify that failed server authentication MUST NOT cause cleartext fallback Robert Evans suggested clearer text here, thanks! I also took the opportunity to remove the line about not suggesting what name to use for authentication, since we do actually offer a suggestion. --- unilateral-probing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/unilateral-probing.md b/unilateral-probing.md index 8410808..a9b7cb8 100644 --- a/unilateral-probing.md +++ b/unilateral-probing.md @@ -356,9 +356,9 @@ If the recursive resolver needs to send SNI to the authoritative for some reason A recursive resolver following this guidance MAY attempt to verify the server's identity by X.509 certificate or DANE. When doing so, the identity would presumably be based on the NS name used for a given query. -However, since this probing policy is unilateral and opportunistic, the client SHOULD NOT consider it a failure if an encrypted transport handshake that does not authenticate to any particular expected name. - -To avoid the complexity of authoritative servers with multiple simultaneous names, or multiple names over time, this draft does not attempt to describe what name a recursive resolver should use when validating an authoritative server, or what the recursive resolver should do with an authentication success. +However, since this probing policy is unilateral and opportunistic, the client connecting under this policy MUST accept any certificate presented by the server. +If the client cannot verify the server's identity, it MAY use that information for reporting, logging, or other analysis purposes. +But it MUST NOT reject the connection due to the authentication failure, as the result would be falling back to cleartext, which would leak the content of the session to a passive network monitor. ### Establishing an encrypted transport connection -- 2.34.1 signature.asc Description: PGP signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Last Call Expired:
Please DO NOT reply to this email. I-D: Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
