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

[Daniel Migault <[e-mail]>]

HI Tommy,

Thanks for the response. Please see my comments inline.

Yours,
Daniel
On Fri, Jun 10, 2022 at 2:51 PM Tommy Pauly <[e-mail]> wrote:

> 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?
>
Encrypted DNS that is DNS over TLS with whatever we want between DNS and
TLS.

>
> 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.
>
> I got what it says, but my point is that I believe that saying the
resolution of resolver.arpa over TLS should use the IP in the URI might be
much clearer - at least in my opinion.
While I agree with the idea, I think we need to provide more to explain
when this situation happens.Typically, I am wondering why would we do DDR
if we have an encrypted resolver - I can see the discovery of multiple
options. I am also wondering whether we want to assume that the initial
resolver has been configured out-of band (however, in that case, a template
is also likely to have been configured) or pre opportunistically discovered
- that is based on the IP the client guesses a well-known URI template (
that would only work is everyone uses the same one  - let see in a few
years - or if that would be standardized at some points). For now, it seems
to me unlikely to happen - but I am happy to be wrong.

>
>
> """
>
> 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.
>
> The SNI issue applies for DoT where the situation seems to me more likely
to happen as there is no URI template to guess. As a result, the situation
might happen when a client receives the IP and just try DoT a
pre-discovery. It might use DoT to discover DoH.
What I understand is that when a TLS handshake happens without SNI,
the identified service will be by default the resolver. I do not see this
happening without a normative - but maybe I am missing something.
In any case, this also means that SNI is not mandatory for resolvers as one
cannot make the difference between a resolver.arpa request and any other
request. I would like to get what I am missing.
I would also like to understand how DoT for example can be differentiated
from DoH - would it be reasonable to go through a protocol analyzer ? I do
not think so.

In a word, I do not see the case that applies for DoH, I could see the case
for DoT. I do not know if a MUST is realistic for cases where
multiple services are hosted behind the same IP address.

> 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.
>

I think the level of trust of the resolver is the same if upon receiving an
IP one sends a resolver.arpa request in clear or encrypted. When the
resolver is non local one probably would prefer using TLS. If in addition,
one is able to check the IP in the certificate matches the one you were
configured with, you are achieving more or less the same level of trust as
with ddr. I do not see this as unrealistic - but I agree that is not
deterministic.

I think that one recommendation could be that configuring an encrypted DNS
resolver should minimally be done using a FQDN + IP address as opposed to
the solely IP address. That would be helpful to have it specified.

> 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.
>
> I think we need to explain when such situation can happen. Note that this
may be somewhere in the draft. I have not re-read it entirely.

> 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.
>
> I got it but I do not see the current recommendations as realistic and
sufficient to solve the absence of SNI. I think  recommendations on the
client side are also necessary.

>
> 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, we have a common understanding for this. I was raising it just in
case, to prevent an issue being raised in 3 months.

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

-- 
Daniel Migault
Ericsson