Re: [Add] opportunistic discovery certificate question

Hey Barbara,

> If the answer is "have the stub resolver make sure no reply comes from a dns://resolver.arpa query and supply Encrypted Resolver info via DNR" and then make sure DNR handles this use case well, I'd be fine with that.

This is exactly what I would recommend when a local-to-CPE forwarder is used for unencrypted DNS but the network operator wants to send clients to an upstream resolver for encrypted DNS. This is what the drafts should convey; I will review this when going over the DDR issues again this next week. I think DNR already makes clear that the ADN included in the DHCP/RA messages should be used to authenticate the DoH server just like any other HTTPS connection.

There has been some enthusiastic debate on the list and in IETF 110 about whether the authenticated mode of DDR should verify the cert chain or not for the name given it already validates an IP-based identity. I believe WG consensus was heading toward "only require IP so we avoid authenticating two identities". However, Tommy Pauly made a point on the other fork I think is worth noting: the decision to trust a cert for a name is separate (generalized to HTTPS behavior, not DDR) for clients from decided to trust a DDR referral as a designated resolver. Is your point that, instead of having DDR leave the topic of name ownership verification alone, it should specifically state that name verification will not occur?

One thing that will not work for sure is using a private IP address for DDR authentication in the TLS cert. For private IP addresses, the entire check is whether the designated server uses the same IP address. If it does not, clients should not use it.

Forgive me and let me know if I did not fully address your questions.

Thanks,
Tommy

From: Add <add-bounces@ietf.org> On Behalf Of STARK, BARBARA H
Sent: Friday, April 16, 2021 12:32 PM
To: 'tirumal reddy' <kondtir@gmail.com>
Cc: 'add@ietf.org' <add@ietf.org>
Subject: [EXTERNAL] Re: [Add] opportunistic discovery certificate question

Yes, but there's no indication in the DoT RFC or in the DDR draft that clients can/should/will trust these certificates and use them to establish a connection.
I'm really trying to get a sense of whether or not there will be some sort of consistent client behavior for clients that claim compliance to DDR. That should be a goal of the DDR specification (I hope). Otherwise, it makes it difficult for ISPs and retail vendors supplying CE routers with stub resolvers to figure out what sort of functionality has to exist in that CE router to get DDR to work.
Reading the DDR section on Authenticated Discovery more carefully, I'm also now wondering if it would be possible for an ISP's recursive resolver queried by that ISP's CE router stub resolvers to supply the SVCB record and include a self-signed certificate with the proper domain name and the default private IP address used by that ISP's CE router stub resolvers. Per the words currently in the 4.1 Authenticated Discovery section, it seems like that would work for the 90% of users who don't change the private IP address of the CE router. This doesn't sound highly desirable. I would expect validation of the provided certificate to also include validation of the chain of trust that requires the cert be signed by an entity whose cert is in the client trust store; but, admittedly, the DDR draft doesn't require that. And having the IP address of the Unencrypted Resolver that's included in the cert be just a best guess default value private IP address is also very kludgy.

Anyway, a huge chunk of the world is behind these stub resolvers. I need to understand whether it makes sense to try to push for some sort of new functionality in these stub resolvers and, if so, what that functionality is. But for me to push for anything, I need to be sure that it's not just throw-away development. This use case is clearly noted in the requirements draft.

If the answer is "have the stub resolver make sure no reply comes from a dns://resolver.arpa query and supply Encrypted Resolver info via DNR" and then make sure DNR handles this use case well, I'd be fine with that. I just need to make sure the use case is handled, I know what the stub resolver has to do, and clients that are compliant (with DNR? with DDR?) will behave consistently.
Thx,
Barbara

DoT allows both self-signed certificates and raw public keys, see https://tools.ietf.org/html/rfc8310<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8310__%3B!!BhdT!1Ig1yeHY-MeOs5Be0KAgpJ8VZiTD-qSGnGd7RzbS0U-TJrrkT5hU17vjag_dNg%24&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cfae02f02cae84023975008d9010e6c9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541983758031483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BJk5zparIE4do4r7yTEfxVDN0ERNAtKsYWI%2Bw9iWKng%3D&reserved=0> for more details. It says "Raw public keys [RFC7250<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc7250__%3B!!BhdT!1Ig1yeHY-MeOs5Be0KAgpJ8VZiTD-qSGnGd7RzbS0U-TJrrkT5hU17v4KyzqKg%24&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cfae02f02cae84023975008d9010e6c9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541983758041479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NRcHqkQz47L%2BhtRtANchaaGO6fkw1TLhPbZyteDBebE%3D&reserved=0>], which reduce the size of the ServerHello and can be used by servers that cannot obtain certificates (e.g., DNS servers on private networks)."

-Tiru

On Thu, 15 Apr 2021 at 22:43, STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>> wrote:
I have a question about certificates used with the DDR opportunistic mechanism.
Since the certificate is not used for authentication ("...whose identity cannot be confirmed using TLS certificates"), does this mean that self-signed certificates could be used?
Would it be possible to even use something simpler (than X.509 certificates), like just Raw Public Keys (RFC7250)?
Thx,
Barbara

--
Add mailing list
Add@ietf.org<mailto:Add@ietf.org>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd__%3B!!BhdT!1Ig1yeHY-MeOs5Be0KAgpJ8VZiTD-qSGnGd7RzbS0U-TJrrkT5hU17sYX6CXrg%24&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cfae02f02cae84023975008d9010e6c9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637541983758041479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rrH%2BbCOn3%2FtmHgP4sUkYdIIUn%2BHYfklDqSjIFTIDuro%3D&reserved=0>