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

Daniel Migault <> Sat, 11 June 2022 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0EEFC14CF13 for <>; Fri, 10 Jun 2022 17:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o8zv28YroP9F for <>; Fri, 10 Jun 2022 17:25:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id BCD01C14F734 for <>; Fri, 10 Jun 2022 17:25:12 -0700 (PDT)
Received: by with SMTP id a15so834894lfb.9 for <>; Fri, 10 Jun 2022 17:25:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=57D/LjG42p9474eatjatEkr2VmfrWasxbOMWcdt42Ss=; b=bKadipJYmuumEnQj9ycL+sc7Yj/XKZoBB7TLcPb/uFeIr7xv9QWnEC4mHj5h1rNs/h mAr9nFhVDZJ4hNQPbLWpWbAaAMq8/ftPTzb9OG905FigKKEJNeXXAUE3OvQfZpAKCpFZ 5NYvLAk3Es0GoAMnZkpzW2u0vJM09dS3ZW2AkaRs00fc51p9ZRAXjz55FVp8FTTI8ulI asisseOn6TFEZwHu3UHS+SCo7yrjfOAE5ckJUL8hC37djnrL1lRKboxchNz+Rj2yNT69 x85OKQXZE5AtTEUuFWARRy0ppA+yO3otwmuELpg/IMgem0o6moD/60LriCMc2S2CRIZy /bIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=57D/LjG42p9474eatjatEkr2VmfrWasxbOMWcdt42Ss=; b=STzeiX1AMe8bJVZ3dLROCqQzgbwL1MZ1phL+byK/8A6jByKE5C56V+w7MmztCl1sEv J8U31g3JbcZwVCCQm1zNNBr9O2W41OPlXocP2FdwRov21YfjxcccYuDWPvRtwanla0TR 7tAmGh7xq+y1TKpAJGe2rMw/nG7OVPtsr4y/Li2v7C3l7GeSScQ3K7pguAR5km1T3ILh dbGTpct/tClMX6IT4x4ON9coCLZg8PIgoc8MQxuNPevg2quWdVoq6owK6rTTq+wZ6fdf cE4BwBhgtAsOhtIVcGdCuL56Ccwu9iySQ8/iFVhyGv0c/p3ADQu3bXIiARiVurtuwGiE t+TQ==
X-Gm-Message-State: AOAM530rJ/cHinF1u2vajtXSKOgJ3oKahfQ/My2A7QsC3x5xmtRf3Sgh 5hfWnACnt9/koAlxrQNnHFiZL7gUs1GCJU1zy0LHttk6XRs=
X-Google-Smtp-Source: ABdhPJzL0cRu5CiI080ncEMj3Pipn8zdrpqEtUO1Ck7EUdcHLKspfTgRvltRS6F3MnvK2O54timiH1Fz0tR4VPAY99s=
X-Received: by 2002:a05:6512:10cd:b0:479:5c5b:f90a with SMTP id k13-20020a05651210cd00b004795c5bf90amr14246426lfg.7.1654907110740; Fri, 10 Jun 2022 17:25:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Fri, 10 Jun 2022 20:24:59 -0400
Message-ID: <>
To: Tommy Pauly <>
Cc: ADD Mailing list <>
Content-Type: multipart/alternative; boundary="00000000000078dca205e121168d"
Archived-At: <>
Subject: Re: [Add] ddr - SPKI question and comment on SNI section
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Jun 2022 00:25:16 -0000

HI Tommy,

Thanks for the response. Please see my comments inline.

On Fri, Jun 10, 2022 at 2:51 PM Tommy Pauly <> wrote:

> Hi Daniel,
> On Jun 10, 2022, at 9:12 AM, Daniel Migault <> 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

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

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

Daniel Migault