Re: [dns-privacy] [IANA #1228441] Protocol Action: 'DNS over Dedicated QUIC Connections' to Proposed Standard (draft-ietf-dprive-dnsoquic-11.txt)
Hi Amanda,
Thank you - all the changes look correct but we have one minor request.
Given that DNS-over-DTLS has been removed from the port 853 TCP entry
‘description' field, it seems correct to also remove the reference to RFC8094
from the ‘reference’ field for consistency. Could that change please be made?
Best regards
Sara.
>> Service Name: domain-s
>> Port Number: 853
>> Transport Protocol: tcp
>> Description: DNS query-response protocol run over TLS
>> Assignee: [IESG]
>> Contact: [IETF Chair]
>> Registration Date: 2015-10-08
>> Modification Date: 2022-04-01
>> Reference: [RFC7858][RFC8094]
> On 8 Apr 2022, at 20:34, Amanda Baber via RT wrote:
>
> Dear Authors,
>
> This is a reminder that we need a reply to the message below.
>
> Best regards,
>
> Amanda Baber
> IANA Operations Manager
>
> On Sat Apr 02 01:06:51 2022, amanda.baber wrote:
>> Dear Authors:
>>
>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED
>>
>> We've completed the registry actions for the following RFC-to-be:
>>
>> draft-ietf-dprive-dnsoquic-11
>>
>> ACTION 1:
>>
>> The following entry has been added to the TLS Application-Layer
>> Protocol Negotiation (ALPN) Protocol IDs registry:
>>
>> DoQ 0x64 0x6F 0x71 ("doq") [RFC-ietf-dprive-dnsoquic-11]
>>
>> Please see
>> https://www.iana.org/assignments/tls-extensiontype-values
>>
>> ACTION 2:
>>
>> An additional reference and an updated description have been listed
>> for UDP port 853, and the word "DTLS" has been removed from the
>> description of the corresponding TCP port. These two registrations now
>> read as follows:
>>
>> Service Name: domain-s
>> Port Number: 853
>> Transport Protocol: tcp
>> Description: DNS query-response protocol run over TLS
>> Assignee: [IESG]
>> Contact: [IETF Chair]
>> Registration Date: 2015-10-08
>> Modification Date: 2022-04-01
>> Reference: [RFC7858][RFC8094]
>>
>> Service Name: domain-s
>> Port Number: 853
>> Transport Protocol: udp
>> Description: DNS query-response protocol run over DTLS or QUIC
>> Assignee: [IESG]
>> Contact: [IETF Chair]
>> Registration Date: 2015-10-08
>> Modification Date: 2022-04-01
>> Reference: [RFC7858][RFC8094][RFC-ietf-dprive-dnsoquic-11]
>>
>> Please see
>> https://www.iana.org/assignments/service-names-port-numbers
>>
>> ACTION 3:
>>
>> The following entry has been added to the Extended DNS Error Codes
>> registry:
>>
>> 26 Too Early [RFC-ietf-dprive-dnsoquic-11]
>>
>> Please see
>> https://www.iana.org/assignments/dns-parameters
>>
>> ACTION 4:
>>
>> The following registry has been created under the "Domain Name System
>> (DNS) Parameters" heading:
>>
>> DNS over QUIC Error Codes
>> Expert(s): Unassigned
>> Reference: [RFC-ietf-dprive-dnsoquic-11]
>> Available Formats
>>
>> Range Registration Procedures
>> provisional (greater than 0x3f) Expert Review
>> provisional registration Date field update First Come First
>> Served
>> permanent, 0x00-0x3fStandards Action or IESG Approval
>> permanent, greater than 0x3fSpecification Required
>>
>> Value Error Description Status Specification Date
>> Contact
>>
>> 0x0 DOQ_NO_ERRORNo errorpermanent [RFC-ietf-
>> dprive-dnsoquic-11, Section 5.3] 2022-04-01 [DPRIVE_WG]
>>
>> 0x1 DOQ_INTERNAL_ERROR Implementation errorpermanent
>> [RFC-ietf-dprive-dnsoquic-11, Section 5.3] 2022-04-01
>> [DPRIVE_WG]
>>
>> 0x2 DOQ_PROTOCOL_ERROR Generic protocol violation
>> permanent [RFC-ietf-dprive-dnsoquic-11, Section 5.3] 2022-
>> 04-01 [DPRIVE_WG]
>>
>> 0x3 DOQ_REQUEST_CANCELLED Request cancelled by client
>> permanent [RFC-ietf-dprive-dnsoquic-11, Section 5.3] 2022-
>> 04-01 [DPRIVE_WG]
>>
>> 0x4 DOQ_EXCESSIVE_LOAD Closing a connection for excessive
>> load permanent [RFC-ietf-dprive-dnsoquic-11, Section 5.3]
>> 2022-04-01 [DPRIVE_WG]
>>
>> 0x5 DOQ_UNSPECIFIED_ERROR No error reason specified
>> permanent [RFC-ietf-dprive-dnsoquic-11, Section 5.3] 2022-
>> 04-01 [DPRIVE_WG]
>>
>> 0xd098ea5e DOQ_ERROR_RESERVED Alternative error code used
>> for tests permanent [RFC-ietf-dprive-dnsoquic-11, Section 5.3]
>> 2022-04-01 [DPRIVE_WG]
>>
>> Please see
>> https://www.iana.org/assignments/dns-parameters
>>
>> Please let us know whether this document's registry actions have been
>> completed correctly. Once we receive your confirmation, we'll notify
>> the RFC Editor that the actions are complete. If a team of authors is
>> responsible for the document, and the actions have been performed
>> correctly, please send a single confirmation message.
>>
>> We'll update any references to this document in the registries when
>> the RFC Editor notifies us that they've assigned an RFC number.
>>
>> Best regards,
>>
>> Amanda Baber
>> IANA Operations Manager
>
___
dns-privacy mailing list
dns-privacy@ietf.org
Re: [dns-privacy] review of dprive-unilateral-probing
Hi Alex--
thanks for this thoughtful review!
I've adopted most of the changes you highlighted (until we submit a new
draft to the datatracker, they can be seen in the editor's draft
https://dkg.gitlab.io/dprive-unilateral-probing/), but wanted to note a
few of them that I didn't fully incorporate yet:
On Wed 2022-04-06 17:52:00 +0200, Alexander Mayrhofer wrote:
> - I agree to the prococol choices considerations. Towards publication,
> we should shorten the paragraph about the DoH path problem.
noted, and recorded here so we don't lose it:
https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/16
> - As noted in the WG discussion, the X.509 certificate with common
> names of all the names an authoritative server is known under could be
> problematic, because customers are usually "creating" their own
> nameserver names without necessarily informing the op of the
> nameserver. Side note - this might be an interesting research topic -
> to look at the names requested in SNI to the DoT port of such servers
> ... (once we have deployment!)
> - I guess implementors have more to say about the client-side probing
> strategy proposed, but it does look very reasonable to me. Maybe we
> can get feedback from early implementations on optimizing the
> resource-use of state information required.
I agree with these two comments, but i'm not sure there's anything to
put in the draft about either of them. if you have text you want to
suggest, and a place to put it, please let me know!
> - The description of the connection state (4.3, first section, and the
> state mangling in 4.5.*) is very close to implementation
> specifications - do we really need that great detail for the protocol
> to be interopable? Given the connection to the requirements in 4.5.1,
> I do admit it's tricky. Maybe we should move that to an Appendix?
> Section 4.3.1, though, is more like an abstract requirement, and
> should be kept in. Maybe re-order? I agree on the 4.4. "per IP
> address" recommendation. It might even be worse for v4/v6 deployments.
This draft is definitely "close to implementation specifications" -- but
that's kind of the goal here. We're trying to describe what specific
policies each server needs to take to avoid harming resolution and
disincentivizing other players from themselves adopting these
strategies.
I've added a high-level overview to section 4 so that an implementer
gets the general idea before diving into the specifics:
https://dkg.gitlab.io/dprive-unilateral-probing/#name-high-level-overview
but i'm kind of reluctant to move the state tables or the specific
transition steps into an appendix.
If those state tables or transition steps are misguided, incomplete for
the stated purpose, or problematic, i'd like to know about it from
implementers so we can correct them.
I fully expect some implementers to keep *additional* state beyond what
is described here, because they may have additional goals. And of
course some implementers might use their own data structures that are
the equivalent of the state described here without being named or
indexed in the exact way described in the document. But i don't see how
to perform the recursive resolver side without keeping something
equivalent to this state.
Would it help to explicitly acknowledge that this description isn't a
requirement for variable names, data structures, etc? I'm happy to
accept text.
Many of the documents coming out of the WHATWG and W3C offer this level
of implementation guidance or even more. For example:
https://www.w3.org/TR/webdriver/
https://encoding.spec.whatwg.org/
They do this to enhance interoperability; when each party knows that the
other conformant party will behave in a certain way, it becomes simpler
to make a decision about how to interact.
I think this is not an unreasonable posture for a document like this in
the IETF too.
> - All the "identifier" strings in the draft should be quoted. (such as
> "early", "unsent", etc..) - maybe personal preference, but I find it
> clearer. Latest, the RFC editors will comment on that anyways.
In the HTML version (which i'm thinking of as the canonical form) all
those identifier strings are set off as elements so they're
already visually distinct. Do you (or does the WG) want quotation marks
as well?
Another possibility would be to rely on in the text/html form,
and quotation marks in the text/plain form, but the xml2rfc tooling
doesn't really permit that. Here are some links that describe that
decision (i'm not sure i agree with it, but i'm also not sure i have the
capacity to fight it):
https://github.com/ietf-tools/xml2rfc/issues/600
https://github.com/ietf-tools/xml2rfc/issues/647
https://notes.ietf.org/cmt-20210222#
I could do an automated replacement in the source to wrap all literal
strings (`foo`) with quotation marks ("`foo`"), using something like:
sed -e 's/\([^"]\|^\)`\([^`]*\)`\([^"]\|$\)/\1"`\2`"\3/g'
But i'm not sure whether it improves the
