> -----Original Message----- > From: dns-privacy [mailto:[email protected]] On Behalf Of > Christian Huitema > Sent: Thursday, December 10, 2015 4:43 AM > To: 'Warren Kumari'; [email protected] > Subject: Re: [dns-privacy] 2nd WGLC for draft-ietf-dprive-dns-over-tls-02. > > On Wednesday, December 9, 2015 1:16 PM, Warren Kumari wrote: > > ... > > 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/orjGksDRsCXV5m8vvfj0 > > Tmdn1uM ) 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. > > 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 protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
