Thank you for your review.
I have made a PR in response to these comments:
https://github.com/tlswg/draft-ietf-tls-esni/pull/646
Detailed responses below.
> In section 6.1.7 "Authenticating for the Public Name", this repeats
> the a public_name should not have any ASCII dots in the wrong places
> and that all labels 63 octects.
>
> Nothing is said about the overall length of DNS name? I assume the
> referenced RFC 5890 references older DNS RFCs about this? But if so,
> why call out the ASCII dots and the label lengths?
>
> At the end of that paragraph other limitations are layed out about the
> "numbers" 0-9 and A-F.
>
> "This avoids public_name... interpreted as IPv4 literals"
>
> Seeing A-F also being mentioned this is "IPv4/IPv6 literals"? (Then
> again IPv6 would be weird, because there should dots in public_name).
This text is generally about trying to mimic existing browser
behavior for identifying things that might be domain names
while excluding IP addresses. I don't believe we need to talk
about v6, because those addresses have colons.
This text was pretty carefully workshopped and perhaps some of the
other WG members who are more DNS experts might want to weigh
in.
> In section 6.1.8, last paragraph,
>
> "...comply with any freshness rules (e.g., DNS TTLs)"
>
> Fair, but how does the application get access to those TTLs? AFAIK the
normal
> resolving stack doesn't not hand out that information.
Many browsers do their own DNS resolution. As you say, if you use
the OS stack you may not get that information, but it will handle
the TTL for you.
> In section 8.1.1.
>
> "...provided the server is authoritative for the public name."
>
> What is meant by this? Because in DNS a nameserver is authoritative for a
zone
> (and thus the names in that zone). Does this mean the DNS name points to
this
> server (via A or AAAA)?
This is talking about the TLS server. I rewrote the text as:
The retry mechanism repairs inconsistencies, provided the TLS server
has a certificate for the public name.
> Section 10.2
>
> nit: "Resource Records" -> RRs (I saw RRs already being used in the
document)
Done.
> "ECH records"
>
> What are those? Are these the HTTPS record(s), mentioned in the beginning?
Yes. This is version skew. Changed.
>
> Further more,
>
> "... which is 1:1 with the DNS name that was looked up (modulo DNS
> wildcards)."
>
> As a non-native English speaker, I have trouble understanding the "which
is 1:1
> with the DNS name".
Changed to:
replace the IP address, thus blocking client connections, or substitute
a
unique IP address for each DNS name that was looked up (modulo DNS
> Then
>
> "modula DNS wildcards"
>
> Why is this mentioned? Because a DNS server (internally) knows about DNS
> wildcards, but a client does not (well with DNSSEC you can figure it
out), so
> I'm not sure why this is said here, seems not relevant and even a bit
wrong?
I agree. Removed.
> Nit:
>
> "Encrypted DNS"
>
> Maybe put the references to the RFCs here again?
Instead I used the term "encrypted DNS" above.
> Section 10.3
>
> "... can help mitigate this problem by flushing and DNS or ECHConfig
> state..."
>
> "flushing DNS state" is dropping the HTTPS record information that a
client has
> and performing a lookup again? Because I don't see how DNS state can be
flushed
> from, say the local resolving by such client, but I don't think that was
meant.
That is what we mean. As noted above, many clients use their own resolver.
Added.
(this may not be possible if clients use the operating system resolver
rather than doing their own resolution).
> Section 10.10.2
>
> "... further limit sharing.... different keys using a short TTL"
>
> OK, yes, this will help a bit, put this information is being put in
public DNS,
> so it's as public as can be... which is the opposite of 'limit
sharing'... ?
What is being shared in this case is the private key that the record
contains the public key for. I changed the text to:
an IP address. Server operators may further limit sharing of private
keys by publishing different DNS records containing ECHConfig values
with different public keys using a short TTL.
> Section 10.10.6
>
> "ECH record"
Fixed.
> used again.
>
> "trusted Recursive Resolver"
>
> I'm unaware of a formal definition of "trusted recursive resolver", so you
> might trust the resolver, but as this document also explains that sounds
a bit
> like hoping for the best? Unsure what to make of this. Or is this the
Firefox
> TRR thing? Which implies DoH/DoT querying?
It's referring to the Firefox thing, but I actually think this is too strong
a claim, so I narrowed it to DNSSEC.
-Ekr
On Fri, Mar 7, 2025 at 4:50 AM R. Gieben via Datatracker <nore...@ietf.org>
wrote:
> Reviewer: R. Gieben
> Review result: Ready with Nits
>
> Hello,
>
> I'm the designated reviewer from dnsdir and I've reviewed -23.
>
> I have a bunch of nits and minor questions, but section 10.2 stood out as
> I had
> trouble understanding the DNS bits in there. Though I think that those can
> be
> fairly easy be fixed.
>
> Note that I haven't read (or can't remember) any of the referenced RFCs or
> I-Ds.
>
> In section 6.1.7 "Authenticating for the Public Name", this repeats the a
> public_name should not have any ASCII dots in the wrong places and that all
> labels 63 octects.
>
> Nothing is said about the overall length of DNS name? I assume the
> referenced
> RFC 5890 references older DNS RFCs about this? But if so, why call out the
> ASCII dots and the label lengths?
>
> At the end of that paragraph other limitations are layed out about the
> "numbers" 0-9 and A-F.
>
> "This avoids public_name... interpreted as IPv4 literals"
>
> Seeing A-F also being mentioned this is "IPv4/IPv6 literals"? (Then again
> IPv6
> would be weird, because there should dots in public_name).
>
> In section 6.1.8, last paragraph,
>
> "...comply with any freshness rules (e.g., DNS TTLs)"
>
> Fair, but how does the application get access to those TTLs? AFAIK the
> normal
> resolving stack doesn't not hand out that information.
>
> In section 8.1.1.
>
> "...provided the server is authoritative for the public name."
>
> What is meant by this? Because in DNS a nameserver is authoritative for a
> zone
> (and thus the names in that zone). Does this mean the DNS name points to
> this
> server (via A or AAAA)?
>
> Section 10.2
>
> nit: "Resource Records" -> RRs (I saw RRs already being used in the
> document)
>
> "ECH records"
>
> What are those? Are these the HTTPS record(s), mentioned in the beginning?
>
> Further more,
>
> "... which is 1:1 with the DNS name that was looked up (modulo DNS
> wildcards)."
>
> As a non-native English speaker, I have trouble understanding the "which
> is 1:1
> with the DNS name".
>
> Then
>
> "modula DNS wildcards"
>
> Why is this mentioned? Because a DNS server (internally) knows about DNS
> wildcards, but a client does not (well with DNSSEC you can figure it out),
> so
> I'm not sure why this is said here, seems not relevant and even a bit
> wrong?
>
> Nit:
>
> "Encrypted DNS"
>
> Maybe put the references to the RFCs here again?
>
> Section 10.3
>
> "... can help mitigate this problem by flushing and DNS or ECHConfig
> state..."
>
> "flushing DNS state" is dropping the HTTPS record information that a
> client has
> and performing a lookup again? Because I don't see how DNS state can be
> flushed
> from, say the local resolving by such client, but I don't think that was
> meant.
>
> Section 10.10.2
>
> "... further limit sharing.... different keys using a short TTL"
>
> OK, yes, this will help a bit, put this information is being put in public
> DNS,
> so it's as public as can be... which is the opposite of 'limit sharing'...
> ?
>
> Section 10.10.6
>
> "ECH record"
>
> used again.
>
> "trusted Recursive Resolver"
>
> I'm unaware of a formal definition of "trusted recursive resolver", so you
> might trust the resolver, but as this document also explains that sounds a
> bit
> like hoping for the best? Unsure what to make of this. Or is this the
> Firefox
> TRR thing? Which implies DoH/DoT querying?
>
> Cheers,
> Miek
>
>
>
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
