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:
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.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.
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.
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.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.
So, "free" caching is the target for us.
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.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.
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.None of this means that the proposal is a bad idea, just that more text would make it more convincing.
Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
