Dr. Pala, Dr. Pala: > Hello all, > > As suggested by some people from other WGs, I just wanted to cross-post > this message here since the proposal heavily rely on DNS and can be > leveraged in many different environments (e.g., Server and Client > (browsers) authentication, document validation, IoT identities, etc.) > and we would like to receive feedback from anybody who might be > interested in the topic. > > *Context. *We are currently working on specifying how to use DNS as a > transport protocol for revocation information for digital certificates. > In particular, we are working on how to leverage the distributed nature > of DNS to efficiently (and possibly at a lower operational costs) > distribute OCSP (Online Certificate Status Protocol) responses to > applications/devices/etc. > > *Current Status.* We started this work sometime ago but never really had > the time to finish it. Now it seems we can focus more on the topic and > would like to discuss this work in a more public venue. We have recently > updated the two competing I-D we submitted sometime ago into the latest > reference I-D that is available here: > > https://datatracker.ietf.org/doc/draft-pala-odin/ > > Please feel free to contact us for any help (you might require or you > might provide), feedback, etc.
I had a quick look and have a few comments/suggestions. Some minor points, and then on to major issues.... Section 6.3, "Time Validity" might be tricky. Someone reading the specification may infer that authoritative DNS servers are supposed to look at the OSCP record and clamp TTL to the expiration of the OCSP response. While there is some precedence for this (in RRSIG records), those are limited to cryptography that is for the DNS itself. My recommendation here is that it be made clear that as an operational matter that operators ensure that the records are published in a way that the TTL is low enough that they expire from caches before the OCSP response expiration. Section 7.2, "Use of TXT Records" may hit a problem similar to what happened with the SPF record. In SPF (a mail authentication & authorization technology), early implementations used TXT records. The DNS community encouraged a switch to a "real" RRTYPE for this. However, what ended up happening is that implementations had to support SPF *and* TXT records. This was extra work and even extra packets on the wire, and eventually the next SPF revision deprecated the SPF type. If the OSCPRR is not yet widely deployed, I would suggest at the very least changing "MAY use TXT records" to "SHOULD NOT use TXT records". If it is widely deployed, then... ug. ;) Now on to the big stuff. :) I think that more work needs to be done explaining why DNS is a more efficient delivery mechanism than HTTP or some other technology. If the idea is that resolvers provide "free" caching close to the user then this may be reasonable. If the idea is that DNS is a simple UDP protocol, then this may quite possibly backfire when you stick largish cryptographic blobs into the DNS responses; DNS is probably less efficient than HTTP then because you'll get UDP responses that tell you to switch to TCP... instead of starting with TCP in the first place. Next, I think you may want to consider more security implications in pressing the DNS infrastructure into service as a critical component of a PKI infrastructure. Unlike HTTP, most DNS traffic is not encrypted (there are not even any drafts proposing a solution in the resolver-to-authoritative server space). This means that, for example, an attacker who gains access to DNS logs may not be able to infer clients who have not updated their revocation lists in a way that was not previously possible. None of this means that the proposal is a bad idea, just that more text would make it more convincing. Cheers, -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
