Subject: [dns-privacy] 2nd WGLC for draft-ietf-dprive-dns-over-tls-02.

From: Warren Kumari <[email-masked]>
Date: Wed, 09 Dec 2015 21:16:07 +0000

Dear DPRIVE WG,

Pippin: But what about WGLC?
Aragorn: You've already had it.
Pippin: We've had one, yes. But what about second WGLC?
          (with apologies to JRR Tolkien / Peter Jackson)

This is a compressed WGLC for draft-ietf-dprive-dns-over-tls.
The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/

The authors have addressed some changes requested during the first WGLC
(please see Allison's mail here for details:
https://mailarchive.ietf.org/arch/msg/dns-privacy/orjGksDRsCXV5m8vvfj0Tmdn1uM )
and the changes are large enough that we feel a second WLGC is in order.

We will primarily be looking at the changes, diff available here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dns-over-tls-02

This WGLC ends Monday 21-Dec-2015.

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 9 Dec 2015 15:12:41 -0800

On Wednesday, December 9, 2015 1:16 PM, Warren Kumari wrote:
> ...
> The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
>

I have reviewed the updated draft. The main change is the addition of text describing an " an out-of-band key-pinned privacy profile." This is a welcome addition, and a very good fit for the "client to recursive resolver" scenario. The proposed key-pinning follows the design specified in the "Public Key Pinning Extension for HTTP," RFC 7479. This is goodness, as it avoids reinventing an existing mechanism. 

However, I am a bit skeptical of some of the requirement to provide "two or more pins" for each server. This assumes a specific model of out-of-band provisioning, and it also assumes that servers always have a second key to fallback to if the first one is compromised. That may be true in many deployments, but that will not always be true. For example, just after a fallback, it will take some time for a second key to become available. Another model would be for clients to proactively refresh the pins that are nearing end-of-life, or maybe perform periodic updates. I would suggest replacing the text in section 4.2 between "MUST deploy" and "future key rollover" by something less imperative, like "SHOULD deploy a backup pin along with the primary pin, for the reasons explained in [RFC7479]."

The mechanism is also somewhat  under-specified, because RFC7469 pins can differ in many ways, besides pinning different keys. For example, they could be computed in the future using different hash algorithms, they may have different life times, they may include subdomains, or they may have different purposes such as "report-only." Then, there is the question of how often clients should be updated, regardless of the age of the pins. But since it is pretty obvious that key-pinning could also be used by DNS-over-DTLS, the fine details on how to manage pinning and provision clients probably belong in a common document, and the DNS-over-TLS draft could be kept simple...

-- Christian Huitema

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 10 Dec 2015 05:54:32 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Christian Huitema
> Sent: Thursday, December 10, 2015 4:43 AM
> To: 'Warren Kumari'; [email-masked]
> Subject: Re: [dns-privacy] 2nd WGLC for draft-ietf-dprive-dns-over-tls-02.
> 
> > The authors have addressed some changes requested during the first
> > WGLC (please see Allison's mail here for details:
> > https://mailarchive.ietf.org/arch/msg/dns-privacy/orjGksDRsCXV5m8vvfj0
> > Tmdn1uM ) and the changes are large enough that we feel a second WLGC
> is in order.
> >
> I have reviewed the updated draft. The main change is the addition of text
> describing an " an out-of-band key-pinned privacy profile." This is a welcome
> addition, and a very good fit for the "client to recursive resolver" scenario.
> The proposed key-pinning follows the design specified in the "Public Key
> Pinning Extension for HTTP," RFC 7479. This is goodness, as it avoids
> reinventing an existing mechanism.
> 
> However, I am a bit skeptical of some of the requirement to provide "two or
> more pins" for each server. This assumes a specific model of out-of-band
> provisioning, and it also assumes that servers always have a second key to
> fallback to if the first one is compromised. That may be true in many
> deployments, but that will not always be true. For example, just after a
> fallback, it will take some time for a second key to become available. Another
> model would be for clients to proactively refresh the pins that are nearing
> end-of-life, or maybe perform periodic updates. I would suggest replacing
> the text in section 4.2 between "MUST deploy" and "future key rollover" by
> something less imperative, like "SHOULD deploy a backup pin along with the
> primary pin, for the reasons explained in [RFC7479]."
> 
> The mechanism is also somewhat  under-specified, because RFC7469 pins
> can differ in many ways, besides pinning different keys. For example, they
> could be computed in the future using different hash algorithms, they may
> have different life times, they may include subdomains, or they may have
> different purposes such as "report-only." Then, there is the question of how
> often clients should be updated, regardless of the age of the pins. But since it
> is pretty obvious that key-pinning could also be used by DNS-over-DTLS, the
> fine details on how to manage pinning and provision clients probably belong
> in a common document, and the DNS-over-TLS draft could be kept simple...

+1 to discuss it in the common document. It simplifies DNS-over-DTLS draft and we can remove the fine details of key-pinning from DNSoD draft and just point to the common doc. The common doc is almost ready, we are waiting for clarity on which doc should SPKI Pinsets.

-Tiru

> 
> -- Christian Huitema
> 
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Dec 2015 13:34:28 -0500

On Wed 2015-12-09 18:12:41 -0500, Christian Huitema <[email-masked]> wrote:

> However, I am a bit skeptical of some of the requirement to provide
> "two or more pins" for each server. This assumes a specific model of
> out-of-band provisioning, and it also assumes that servers always have
> a second key to fallback to if the first one is compromised.

To clarify this: it requires server *operators* to prepare and have
available a second key for fallback.  It does not require the server
itself to have access to both keys concurrently.

> That may be true in many deployments, but that will not always be
> true. For example, just after a fallback, it will take some time for a
> second key to become available.

I think the implication here is that as soon as a compromise happens,
the servers may no longer use the original key.  This isn't how things
are likely to work in practice.  In practice, a key compromise and
rollover will have a timeline like this:

 Time   Action      Key used     Keys Permitted
                    by server    on updated client
                   
  0    Setup        A            A,B
  
  1    Compromise   A            A,B
  
  2    Compromise   A            A,B
       Discovered 

  3    Backup key   B            A,B
       Deployed

  4    New Pins     B            B,C
       Announced
       (OOB)

The time i think you're talking about is the time between 1 and 3,
right?  Key A, despite being known-compromised, does not become unusable
until step 4 has completed.  This is slower than we might like, but it
also allows for smooth service upgrades and no failures in service while
the operator waits for the action in step 4 to take effect across all
connected clients.

> Another model would be for clients to proactively refresh the pins
> that are nearing end-of-life, or maybe perform periodic updates. I
> would suggest replacing the text in section 4.2 between "MUST deploy"
> and "future key rollover" by something less imperative, like "SHOULD
> deploy a backup pin along with the primary pin, for the reasons
> explained in [RFC7479]."

If a server operator deploys this scheme with a pinset containing only
one pin, and they have more than one client, then they cannot change
their service key without either (a) coordinating a simultaneous
rollover between all clients, or (b) causing service interruption for
some clients.  This is effectively an unmaintainable system, and we
should not provide the wiggle-room to say that an unmaintainable service
is compliant with the specification.

> can differ in many ways, besides pinning different keys. For example,
> they could be computed in the future using different hash algorithms,

HSTS has explicitly decided to not specify multiple algorithms now, and
will deal with subsequent algorithms with an update when SHA-256 is
nearing end-of-life.  I see no reason for this authentication mechanism
for dprive should be more specific.

> they may have different life times, they may include subdomains, or
> they may have different purposes such as "report-only."

None of these features are relevant to this dprive authentication
mechanism, which explicitly states that the pinsets are per-endpoint
(not associated with a name at all), are fail-closed, and must be
updated in some out-of-band process.  (yes, the "some out-of-band
process" is deliberately not specified -- that's the piece that an
implementer needs to handle on their own).

   --dkg