Subject: [Add] draft-pauly-add-deer

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Jan 2021 09:08:21 +0100

Hi,

I support the adoption of this draft.  I do have a question regarding scale:

Imagine that a cloud-based service were to implement this with a single anycast IP address: would the expectation be that the plethora of DoH resolvers all share a private key?

I guess what I am really asking is what the value of the IP address is in the certificate.  In the case of DoH, is this address a form of non-authoritative hint where the real validation occurs in the domain name or is it really needed to secure the design?

Thanks,

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2021 07:33:33 -0800

On Thu, Jan 21, 2021 at 12:08 AM Eliot Lear <lear=[email-masked]>
wrote:

> Imagine that a cloud-based service were to implement this with a single
> anycast IP address: would the expectation be that the plethora of DoH
> resolvers all share a private key?
>

That's an implementation detail. I.e., one can either share a single
certificate or have many certificates with the same identity. Note that
this situation already exists with any large domain (e.g., google.com), and
is not really different for IPs.

> I guess what I am really asking is what the value of the IP address is in
> the certificate.  In the case of DoH, is this address a form of
> non-authoritative hint where the real validation occurs in the domain name
> or is it really needed to secure the design?

Good question. In ordinary TLS authentication, the certificate is serving
one purpose: authenticating the binding between the identity that the
client is trying to connect to and the server (technically the server's
key, of course). In this case, however, it's also serving another function,
which is demonstrating that the server has control of the identity that the
client started with, which is to say the IP address of the resolver that
was configured into it, obtained from DHCP, etc.

An analogy here might be the way that CNAMEs are handled in HTTPS: you
start with example.com and there is a CNAME to example.org. That's an
insecure redirection, so you expect the server to have a cert for
example.com (and perhaps also example.org, but you don't care about that).
In this case, you start with 192.0.2.1 and then get example.com, so you
expect the cert to have 192.0.2.1. From this perspective, in some sense,
the requirement in DEER S 4.1. that it also have example.com is unnecessary.

-Ekr

Eliot
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Thu, 21 Jan 2021 16:43:43 +0000

Thanks, Eric.  Please see below:

[trimming]

> On 21 Jan 2021, at 16:33, Eric Rescorla <[email-masked]> wrote:
> 
> Good question. In ordinary TLS authentication, the certificate is serving one purpose: authenticating the binding between the identity that the client is trying to connect to and the server (technically the server's key, of course). In this case, however, it's also serving another function, which is demonstrating that the server has control of the identity that the client started with, which is to say the IP address of the resolver that was configured into it, obtained from DHCP, etc.
> 
> An analogy here might be the way that CNAMEs are handled in HTTPS: you start with example.com <http://example.com/> and there is a CNAME to example.org <http://example.org/>. That's an insecure redirection, so you expect the server to have a cert for example.com <http://example.com/> (and perhaps also example.org <http://example.org/>, but you don't care about that). In this case, you start with 192.0.2.1 and then get example.com <http://example.com/>, so you expect the cert to have 192.0.2.1. From this perspective, in some sense, the requirement in DEER S 4.1. that it also have example.com <http://example.com/> is unnecessary.

Ok, this is worth documenting. I could envision this being done with new EKU, but I imagine that would introduce some complications t in terms of knowing which usage is intended at the time of cert validation.  Perhaps this is the nail in the coffin for new EKUs involving services.  Arguably that coffin is pretty well nailed already.

Eliot

---

From: Eric Orth <[email-masked]>
Date: Fri, 22 Jan 2021 13:15:51 -0500

On Thu, Jan 21, 2021 at 10:34 AM Eric Rescorla <[email-masked]> wrote:

>
>
> On Thu, Jan 21, 2021 at 12:08 AM Eliot Lear <lear=
> [email-masked]> wrote:
>
>> Hi,
>>
> this situation already exists with any large domain (e.g., google.com),
> and is not really different for IPs.
>
>
> example.com (and perhaps also example.org, but you don't care about
> that). In this case, you start with 192.0.2.1 and then get example.com,
> so you expect the cert to have 192.0.2.1. From this perspective, in some
> sense, the requirement in DEER S 4.1. that it also have example.com is
> unnecessary.
>

Maybe theoretically unnecessary for the security requirements of DEER, but
before anybody goes suggesting we actually remove the requirement for certs
to contain exmaple.com, it still may be worth some study to be sure it
wouldn't create practical challenges for client implementations.  I imagine
many clients' HTTPS stacks/libraries would not be happy to load
https://example.com without example.com in the cert, and it may not always
be reasonable to convince the library that it's the same thing as a CNAME.
Plus I'd be worried that this might be creating an exception against
requirements in other specs.