Re: [DNSOP] New I-D for OCSP over DNS

[Shane Kerr <[e-mail]>]

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