Hi Ondrej,

thanks for the feedback. I will definitely cross-post the proposal to DNSOP, TLS WG, and maybe the CAB Forum. I totally agree with you about the need of having implementations.. that is why I contacted you in the first place :D

On this topic, we also gathered some interest around the idea and we already have people interested in an implementation. On our side, this is going to be implemented in the OpenCA software. On top of that, Rich from OpenSSL provided initial commitment for an implementation. We are working mostly outside the TLS-only Browsers/Servers environment(s) and tackling this for use also in IoT environments (e.g., OCF, OpenADR, WinnForum, etc.), but there are obvious advantages for the CAB environment too... it just seems that if you are not from Mozilla or Google, it is quite difficult to get anything moving in (especially) browsers' environment... :D

(a) For your point about the DNSSEC support. I think that eliminating support for DNS would be equivalent to require HTTPS (instead of HTTP) as a transport protocol for OCSP responses or for CRL download. As far as I know, the vast majority of deployment use the HTTP transport protocol, which is open to the same security consideration as DNS vs. DNSSEC. I do think that requiring DNSSEC would definitely kill the idea and I fear it would not be easily adopted because of that.

(b) For the TXT fallback, I still am on the fence. I totally agree with you that the use of a specific record type is to be preferred, but I would also provide the possibility for existing infrastructures to start leveraging the DNS infrastructures even before a new RR is defined and supported by deployed software... my plan was to deprecate the support for TXT records once we have the document on its way to standardization. If the document never makes it and becomes just informational, I think that keeping the TXT support might facilitate testing and experimentation... :D

Thanks again for your suggestions and for taking the time to read the document :D And, please, let me know what you think of the responses above :D

Cheers,
Max

Dear Massimiliano,

thank you for the heads up, I would recommend simply submitting your proposal as I-D and send the announcement message to DNSOP and TLS WG @ IETF. That way this will get much more attention than from just us. Or I would rather recommend going to CAB Forum first - because it would be useless to spend time working on a standard nobody would implement.

From myself, I would add just initial thoughts on the DNS side:

a) I would strongly recommend making this DNSSEC only and tackling the error modes when DNSSEC Validation fails (e.g. similar to situation when OCSP retrieval via HTTP(S) fails). Without DNSSEC, you are prone to OCSPRR striping, with DNSSEC, you are tackling the same problem as DANE (TLSA RR) has - the resistance to implement DNSSEC-validating resolver in the browser.

b) drop the TXT fallback, getting a new RR is simple (compared to getting this to be approved as a model of operation in PKIX WG

Good luck,
Ondrej

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director