Subject: [Add] opportunistic discovery certificate question

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Apr 2021 17:12:20 +0000

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

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 15 Apr 2021 12:02:33 -0700

I think we’re thinking that the certificate should still match the name that is used for the authority in the HTTP requests made if the server is a DoH server. So, if you have an advertisement for a server running on a particular address being https://doh.examplecarrier.com/dns-query <https://doh.examplecarrier.com/dns-query>, then it should have a certificate that covers doh.examplecarrier.com <http://doh.examplecarrier.com/> and validates with whatever trust settings the device is configured with.

Thanks,
Tommy

> On Apr 15, 2021, at 10:12 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Apr 2021 23:35:10 +0000

Hmm. I'm not fully understanding. I'm a bit fuzzy as to who's doing what in your explanation, where the domain is coming from, and what the client is expected to "know".
Let me see if I can paraphrase what I think I'm reading, in the form of a more specific example...

Let's say the CE router is advertising itself as the Unencrypted Resolver (a stub resolver / DNS proxy) at 192.168.1.1. When the client queries for dns://resolver.arpa, the stub resolver has the requisite SVCB record and replies with the DoH info which indicates the DoH resolver is also at 192.168.1.1 (because the client won't trust it unless "the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver"). The local domain the CE router advertises in DHCP is carrierexamplelocal.net. The provider puts this same local domain in all its CE routers. It has registered this domain, but the domain doesn't resolve on the Internet - it's just for the stub resolver to resolve.

The certificate that the stub resolver supplies with its IP address (as part of the SVCB record) includes a SubjectAlternativeName of doh.carrierexamplelocal.net?
But no CA would sign off on this (since there may be millions of CE routers that use this same local domain), so there can't be a chain of trust for this cert that would lead to a CA the client trusts.
So, back to my previous question, is self-signed cert ok? If so, the self-signed cert could certainly be generated with that domain name; but what does that accomplish? It proves nothing.
If self-signed cert is not ok, then the opportunistic discovery is fairly useless for the private IP case (which I thought it was defined for).
Barbara

From: Tommy Pauly <[email-masked]>

I think we're thinking that the certificate should still match the name that is used for the authority in the HTTP requests made if the server is a DoH server. So, if you have an advertisement for a server running on a particular address being https://doh.examplecarrier.com/dns-query<https://urldefense.com/v3/__https:/doh.examplecarrier.com/dns-query__;!!BhdT!x93s7fsG7o-LtsX3j-gpfYdhp42_6Nh7lbw0toTiWdgm8NtUE9op7hSkPJp1OA$>, then it should have a certificate that covers doh.examplecarrier.com<https://urldefense.com/v3/__http:/doh.examplecarrier.com__;!!BhdT!x93s7fsG7o-LtsX3j-gpfYdhp42_6Nh7lbw0toTiWdgm8NtUE9op7hQh2YSXAQ$> and validates with whatever trust settings the device is configured with.

Thanks,
Tommy

On Apr 15, 2021, at 10:12 AM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!x93s7fsG7o-LtsX3j-gpfYdhp42_6Nh7lbw0toTiWdgm8NtUE9op7hToWFuf1Q$>

---

From: tirumal reddy <[email-masked]>
Date: Fri, 16 Apr 2021 11:25:45 +0530

DoT allows both self-signed certificates and raw public keys, see
https://tools.ietf.org/html/rfc8310 for more details. It says "Raw public
keys [RFC7250 <https://tools.ietf.org/html/rfc7250>], 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 <[email-masked]> wrote:

> 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
> [email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Apr 2021 19:31:51 +0000

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://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8310__;!!BhdT!1Ig1yeHY-MeOs5Be0KAgpJ8VZiTD-qSGnGd7RzbS0U-TJrrkT5hU17vjag_dNg$> for more details. It says "Raw public keys [RFC7250<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7250__;!!BhdT!1Ig1yeHY-MeOs5Be0KAgpJ8VZiTD-qSGnGd7RzbS0U-TJrrkT5hU17v4KyzqKg$>], 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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!1Ig1yeHY-MeOs5Be0KAgpJ8VZiTD-qSGnGd7RzbS0U-TJrrkT5hU17sYX6CXrg$>

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 16 Apr 2021 19:50:08 +0000

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 <[email-masked]> On Behalf Of STARK, BARBARA H
Sent: Friday, April 16, 2021 12:32 PM
To: 'tirumal reddy' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: [EXTERNAL] Re: [Add] opportunistic discovery certificate question

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

--
Add mailing list
[email-masked]<mailto:[email-masked]>
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>