Re: [Add] ddr - SPKI question and comment on SNI section

[Tommy Pauly <[e-mail]>]

Hi Daniel,

> On Jun 10, 2022, at 9:12 AM, Daniel Migault <[e-mail]> wrote:
> 
> Hi, 
> 
> We are considering different ways to configure DoE clients.                   
>                                                                              
> RFC 7858 indicates the use of SPKI Fingerprints in an analogous manner to that described in RFC7469. I am wondering if anyone is aware of implementation considering SPKI Fingerprints for or if such usage is not something we would like to deprecate.
> 
> Additionally, I was wondering how DoE can be performed without an hostname and its associated SNI and went through 6.3. 

What does “DoE” refer to in this context?
> 
> 6.3. Server Name Handling
> 
> """                                                                           
> When performing discovery using resolver IP addresses, clients MUST use the IP address as the URI host for DoH requests.                                   
> """                                                                           
> The text can be read as when ddr is performed as described in section 4, DoH
> request place the IP address in the URI.                                      
> I think the text is willing to say when ddr requests are performed using DoH,
> but once ddr is done, the hostname provided by ddr must be placed in the URI, but I think that could be clarified.      

It says that if you use the mechanism with resolver.arpa, as defined in Section 4, your DoH URI needs to use the IP address as the hostname.

If, on the other hand, you use the discovery by name in Section 5 (which doesn’t say what transport you use, it’s just a case where you are configured with a resolver name instead of an address), this requirement doesn’t apply or make sense.

>                                   
> 
> """                                                                           
> Note that since IP addresses are not supported by default in the TLS SNI,
> resolvers that support discovery using IP addresses will need to be configured
> to present the appropriate TLS certificate when no SNI is present for both DoT
> and DoH.                                                                     
> """                                                                           
> 
> I am wondering what "will need" means  MUST or SHOULD ? 

It’s a statement of fact for how certificates work, not trying to add extra normative language. We could make this a MUST, but I don’t think that is necessary here.

> 
> As I see it, SNI causes an issue for client only configured with an IP address when they are willing to perform DDR over an encrypted DNS. In this later case, it seems that a user that checks if the IP supports DoE to discover the assigned DoE seems a bit like an opportunistic (pre)-discovery - obviously different from section 4.3.

Discovery in DDR, in either method, assumes you are starting with some DNS configuration that you are willing to use. This is unencrypted or encrypted — that doesn’t matter. You can certainly send DDR queries over an encrypted resolver, but those aren’t about validating that you can use that encrypted resolver — you should only send those if you already trust that encrypted resolver. Instead, they would be done to discover alternative protocols, or to look up designated resolvers for other resolver names.

> In addition, when the TLS session can be established, there is no obvious rea
> sons to proceed further to ddr.

Again, it’s not about bootstrapping its own connection.

> The way I perceive the section on SNI is to provide some recommendations on the resolver side to handle more possible scenario. It might also be good to add the client perspective and recommend that clients be configured with the host name to increase the chance of a working SNI - and this extension should be  enabled by the client.  

The section on SNI is just clarifying that you can’t use an IP address as an SNI, and that you shouldn’t try to use resolver.arpa if you used that to discover, but instead leave off the SNI.

> 
> There are cases where multiple unencrypted DNS resolvers (with different IP addresses) share a designated encrypted DNS. My reading of section 4.2 is that this case is covered properly. I am raising the use case just in case someone sees an issue somewhere. 

Yes, you could have different unencrypted resolvers all point to the same encrypted DNS server as long as that server has a cert that covers those IP addresses. You could also have one unencrypted resolver point to multiple encrypted resolvers on different IP addresses, as long as each has a cert that covers the unencrypted resolver’s address.

Thanks,
Tommy

> 
> -- 
> Daniel Migault
> Ericsson
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add