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

["Dr. Pala" <[e-mail]>]

Hi Shane,

thanks for the reply and feedback, we do really appreciate :D For the 
replies to your comments, see inline.

Again, thanks!


On 10/30/17 3:23 AM, Shane Kerr wrote:
> Dr. Pala,
> [...]
> 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.
Thanks. This is a good point. I will update the draft and add this 
consideration. It is to be noted that, today, most of the pre-computed 
OCSP tokens/responses are generated at specific times (few times a day) 
and usually have a configured validity time. This is probably easy to 
implement also in the DNS case where the ZONE file might be updated at 
specific times and the TTL, in that case, would be the same for all entries.

Good point, I will add some specific considerations for that.
>
> 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. ;)
I do agree with this point. I will remove the TXT example/suggestion.
>
> 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.
The main point of this I-D is to allow for simple "caching" closer to 
the user. So, it is not about UDP or "low-latency" (as someone else in 
other WG asked about). This I-D is meant to leverage the widely 
distributed nature of the DNS so that operational costs can be lowered 
(from a Certification Authority point of view and the revocation 
information has another channel/transport mechanism that (in my opinion) 
will ease the use of revocation information in applications (not only 
browsers) and IoT space.

So, "free" caching is the target for us.
>
> 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.
I am not sure about your point on the DNS logs - could you elaborate a 
little bit more? For the security of the communication (i.e., DNS 
traffic not being encrypted), consider that, today, most (if not all) 
the major Internet Certification Authorities distribute the pre-computed 
OCSP responses via CDNs over HTTP (not HTTPS). This is because all the 
OCSP responses are signed, therefore they can not be forged. However, 
this approach has security implications about MITM attacks that are the 
same as the DNS ones.
> None of this means that the proposal is a bad idea, just that more text
> would make it more convincing.
>
Again, I do really appreciate the feedback :D The whole point of IETF is 
to mold a good ideas by one person/group into a great idea that 
incorporates feedback from experts in different fields :D Our goal is to 
provide a good alternative to HTTP that is also easy to deploy so that 
it can be adopted and deployed easily.

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo