On 7/21/2023 11:56 AM, Paul Hoffman wrote:
Substantial bits below; others were accepted withtout note.
On Jul 17, 2023, at 5:06 AM, Eric Vyncke (evyncke)
<evyncke=40cisco....@dmarc.ietf.org> wrote:
# Shepherd's write-ip
The shepherd's write-up states "the WG would like to ensure that this list remains in the
document once it is published as an RFC" but the appendix A states "RFC Editor: please
remove this section before publication". I.e., the shepherd's write-up and the I-D MUST be
coherent ;-)
Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in the
format from RFC 7942, and is not at all definitive, and thus can be removed.
# Section 1.1
I am always uneasy with the use of BCP14 normative language outside of a
standard track or BCP document.
I agree with your unease, but it is a long-established tradition in the RFC
Series. If the IESG and IAB and ISE want to create new guidance on that...
# Section 3
This was probably discussed over the mailing list, but must DoT & DoQ replies
be also identical to Do53 replies ? The current text is a little underspecified.
The last paragraph of Section 3 says "An authoritative server implementing DoT or
DoQ MUST authoritatively serve the same zones over all supported transports." How
should we say that differently to be more specfied?
# Section 3.2
In ` The simplest deployment would simply provide a self-issued, regularly-updated X.509
certificate` is the intent to use short-lived certificates ? Or more to state "valid
certificate" ? The text would benefit from clarity.
There is no intent for short-lived or long-lived: that's totally up to the
deployment. Also, self-issued certificates are not valid, they are only
verifiable.
# Section 3.5
Expect some comments during the IESG review if the SHOULDs do not have some
wording about when the SHOULDs does not apply.
To increase the anonymity set for each response, the authoritative
server SHOULD use a sensible padding mechanism for all responses it
sends when possible (this might be limited by e.g. not receiving an
EDNS(0) option in the query). Specifically, a DoT server SHOULD use
EDNS(0) padding [RFC7830] if possible, and a DoQ server SHOULD follow
the guidance in Section 5.4 of [RFC9250]. How much to pad is out of
scope of this document, but a reasonable suggestion can be found in
[RFC8467].
The first SHOULD says it does not apply when not receiving an EDNS(0) option.
The second points to the logic in Section 5.4 of RFC 9250. What more could we
add?
IF we were serious about the "informational only" status, then we would
rewrite this to provide information instead of mandating behavior.
Something like:
An authoritative server that does not use sensible padding mechanisms
will probably decrease the anonymity of each response. For DoT, sensible
padding mechanism can be implemented using EDNS(0) padding [RFC7830].
For DoQ, padding mechanisms are described in Section 5.4 of [RFC9250].
How much to pad is out of scope of this document, but a reasonable
suggestion can be found in [RFC8467].
-- Christian Huitema
# Section 4.4
Unsure whether the last paragraph has any value... ` a recursive resolver
implementing these strategies SHOULD also accept queries from its clients over
some encrypted transport (current common transports are DoH or DoT).`
That was requested by the WG.
# Section 4.6.10
Only one prioritization scheme in this section while there were two in section
3.4
Section 3 is about authoritative servers, Section 4 is about resolvers. In
general, no one gets too concerned about resource exhaustion in resolvers.
After the deployment experiemt, maybe that will change.
We will turn in the -10 during IETF117.
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
