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/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.
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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
