Subject: Re: [dns-privacy] draft-pp-recursive-authoritative-opportunistic-04

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 14 Jan 2021 16:31:19 +0000

Comments -- which may have been discussed in the WG before, in which case ignore them:

- The discovery method seems to be that you look at the NS RR IP address and attempt DoT on port 853. But the requirements doc https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02 in requirement 7 suggests that instead of this that they auth SLD admin would specify secure transport preferences. Presumably this would be in some DNS RR in the SLD. Your proposed discovery method and what is suggested in the requirements doc seem to be at odds.

- Why suggest attempting to contact via an IP rather than a FQDN in the URI? I know sometimes managing the TLS certs based on IPs rather than FQDNs can be problematic in some deployments.

- Is it necessary to specify the transport cache? If it helps with performance everyone will do it. And the section other than saying there MUST be a cache does not specify anything else.

Jason

On 1/13/21, 8:07 PM, "dns-privacy on behalf of Paul Hoffman" <[email-masked] on behalf of [email-masked]> wrote:

    Greetings again. I have updated draft-pp-recursive-authoritative-opportunistic to include comments from the WG on -03, and to include timings that I have determined by experimenting on a large database of domain names of "typical" web sites. I am writing up that research now, but because the WG asked me to put data-driven timeouts in the draft, I did so in advance of the research.

    Draft: https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/
    Diff: https://tools.ietf.org/rfcdiff?url2=draft-pp-recursive-authoritative-opportunistic-04.txt

    Comments before or during the interim are clearly welcome.

    --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jan 2021 18:12:18 +0000

> Comments -- which may have been discussed in the WG before, in which case ignore them:

I'd rather not ignore anything!

> - The discovery method seems to be that you look at the NS RR IP address and attempt DoT on port 853. But the requirements doc draft-ietf-dprive-phase2-requirements-02 in requirement 7 suggests that instead of this that they auth SLD admin would specify secure transport preferences. Presumably this would be in some DNS RR in the SLD. Your proposed discovery method and what is suggested in the requirements doc seem to be at odds.

This was discussed at IETF 109, and I thought that the outcome was that, for opportunistic encryption, probing works fine and will inherently lead to more encryption of traffic than requiring changes to naming for servers or adding new record types. This was also discussed on the list in reply to Tony Finch's message before IETF 109 (but that never became a draft).

> - Why suggest attempting to contact via an IP rather than a FQDN in the URI? I know sometimes managing the TLS certs based on IPs rather than FQDNs can be problematic in some deployments.

I don't understand this. After all, one *always* contacts a server based on its IP address, based on doing a lookup for the domain name in the NS record. Also, there is no URI here.

We talked about using IP addresses in certificates being problematic, but so is listing hundreds of names for name servers that have vanity names for each of the names for which it is authoritative. For this draft, it truly doesn't matter what identifier is in the certificate, but the draft is still trying to work with whatever different draft that might eventually come out describing the fully-authenticated use case.

> - Is it necessary to specify the transport cache? If it helps with performance everyone will do it. And the section other than saying there MUST be a cache does not specify anything else.

In earlier discussions, there were questions about what would and would not be in the transport case, so describing the contours seemed more appropriate. If the WG wants to remove it, that's easy.

--Paul Hoffman

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 14 Jan 2021 18:22:48 +0000

> We talked about using IP addresses in certificates being problematic, but so is listing hundreds of names for name servers that have vanity names for each of the names for which it is authoritative…

[JL] I guess I am thinking mainly of how to implement & manage the certs. The easier this is the better it will be for eventual deployment.

> In earlier discussions, there were questions about what would and would not be in the transport case, so describing the contours seemed more appropriate. If the WG wants to remove it, that's easy.

[JL] As it stands now it seems to just say you must have one but not much specificity beyond that. As a result I am just suggesting that a shorter document is a better document and this section could be removed without affecting the objective of the proposed standard or how software implements this.

Jason