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
On 10/27/17 7:16 AM, Ondrej Sury via RT
wrote:
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
