On Jan 14, 2021, at 8:31 AM, Livingood, Jason <[email protected]> wrote:
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
