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

[Daniel Migault <[e-mail]>]

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.

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.


"""

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 ?

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.
In addition, when the TLS session can be established, there is no obvious
rea
sons to proceed further to ddr.
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.

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.

-- 
Daniel Migault
Ericsson