Subject: [saag] OCSP over DNS

From: "Dr. Pala" <[email-masked]>
Date: Thu, 16 Nov 2017 17:08:53 +0800

Hi all,

although the I-D was not adopted by IETF, I have one question and I 
would like to provide some comments related to proposal that might have 
not been conveyed or stressed enough.

The question is: in order to effectively move forward with our work, how 
can we request the allocation for the DNS RR type for OCSP response data 
? Is there a possibility to get it allocated even if the submission will 
be an individual one ?

First of all, although mechanisms like OCSP stapling exist and are used 
in (some) environments like Web/Browsers [*] , there are many 
environment where that is not happening (not implemented). Even when 
stapling is supported, the parties (client and server) still need to 
retrieve the OCSP responses somehow and HTTP/s might not be a viable 
option - maybe I failed in conveying this point, but I think it is a 
very important one. Last but not least, reducing the amount of data sent 
for establishing secure sessions might not be relevant for large devices 
(e.g., laptop/etc.) or generic applications (e.g. browsers), but it 
definitely matter in the IoT space.

On the costs associated with the distribution of revocation information, 
I think that the comments on that were not really based on data. Large 
PKIs exist outside the ICA that issue BILLIONS of certificates and the 
proposed solution might not only be encouraged but required to provide 
revocation support in those environment.

This said, I am still a bit confused about the reasons for not adopting 
this work since it would improve access to revocation information, lower 
operational costs for CAs (and thus lowering the costs of certificates 
management), and, in general, provide more options for a more secure 
networking environment.

Last but not least, I would like to thank all the people that actually 
provided support and valuable comments (from ISC to individual 
contributors). Also, in case any of the people on the list are still 
interested in pursuing the idea and improve the draft (that is what we 
were hoping for - improving an INITIAL idea), please contact me directly 
as the work will still continue outside the IETF.

Thanks again for the opportunity to present at DISPATCH.

Cheers,
Max

[*] = Fun fact, here's reference of a thread in the mozilla sec lists 
where this proposal was positively considered even back in 2011 - 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8

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

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 16 Nov 2017 17:47:56 +0800

Sent from my iPhone

> On Nov 16, 2017, at 17:08, Dr. Pala <[email-masked]> wrote:
> 
> Hi all,
> 
> although the I-D was not adopted by IETF, I have one question and I would like to provide some comments related to proposal that might have not been conveyed or stressed enough.
> 
> The question is: in order to effectively move forward with our work, how can we request the allocation for the DNS RR type for OCSP response data ? Is there a possibility to get it allocated even if the submission will be an individual one ?
> 

DNS RR types may be allocated by expert review. See RFC 6895 section 3.1.1. 

Fill out the template and send it off to the IANA experts.
> First of all, although mechanisms like OCSP stapling exist and are used in (some) environments like Web/Browsers [*] , there are many environment where that is not happening (not implemented). Even when stapling is supported, the parties (client and server) still need to retrieve the OCSP responses somehow and HTTP/s might not be a viable option - maybe I failed in conveying this point, but I think it is a very important one. Last but not least, reducing the amount of data sent for establishing secure sessions might not be relevant for large devices (e.g., laptop/etc.) or generic applications (e.g. browsers), but it definitely matter in the IoT space.
> On the costs associated with the distribution of revocation information, I think that the comments on that were not really based on data. Large PKIs exist outside the ICA that issue BILLIONS of certificates and the proposed solution might not only be encouraged but required to provide revocation support in those environment.
> This said, I am still a bit confused about the reasons for not adopting this work since it would improve access to revocation information, lower operational costs for CAs (and thus lowering the costs of certificates management), and, in general, provide more options for a more secure networking environment.
> Last but not least, I would like to thank all the people that actually provided support and valuable comments (from ISC to individual contributors). Also, in case any of the people on the list are still interested in pursuing the idea and improve the draft (that is what we were hoping for - improving an INITIAL idea), please contact me directly as the work will still continue outside the IETF.
> 
> [*] = Fun fact, here's reference of a thread in the mozilla sec lists where this proposal was positively considered even back in 2011 - https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 16 Nov 2017 18:02:00 +0800

Hi Joel,

Thanks!

Cheers,
Max

> On Nov 16, 2017, at 5:47 PM, Joel Jaeggli <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Nov 2017 01:35:19 +0800

This is the current advice:
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-ocsp-stapling/

And here is some info on its relative prevalence:
https://mzl.la/2AQ7gpM

To address your points:
* The primary part of a CA workload is signing, not storage and retrieval
of OCSP.
* Stapling provides superior access, security and (critically) privacy.
DNS would not be any significant improvement over CRL or OCSP privacy.
* That thread you cite is very old and not any basis for a decision in 2017.

You didn't address the comment I made about the cache - stapling has the
virtue that it results in a cache of the OCSP in exactly one place: the
entity that holds the certificate.  DNS caching would result in copies in
DNS caches throughout the network.

I don't understand the claim that DNS provides better access for
certificate-holders.  The number of places that HTTP fails and DNS succeeds
is not significant enough to be relevant.

On Thu, Nov 16, 2017 at 5:08 PM, Dr. Pala <[email-masked]> wrote:

> Hi all,
>
> although the I-D was not adopted by IETF, I have one question and I would
> like to provide some comments related to proposal that might have not been
> conveyed or stressed enough.
>
> can we request the allocation for the DNS RR type for OCSP response data ?
> Is there a possibility to get it allocated even if the submission will be
> an individual one ?
>
> First of all, although mechanisms like OCSP stapling exist and are used in
> (some) environments like Web/Browsers [*] , there are many environment
> where that is not happening (not implemented). Even when stapling is
> supported, the parties (client and server) still need to retrieve the OCSP
> responses somehow and HTTP/s might not be a viable option - maybe I failed
> in conveying this point, but I think it is a very important one. Last but
> not least, reducing the amount of data sent for establishing secure
> sessions might not be relevant for large devices (e.g., laptop/etc.) or
> generic applications (e.g. browsers), but it definitely matter in the IoT
> space.
>
> On the costs associated with the distribution of revocation information, I
> think that the comments on that were not really based on data. Large PKIs
> exist outside the ICA that issue BILLIONS of certificates and the proposed
> solution might not only be encouraged but required to provide revocation
> support in those environment.
>
> interested in pursuing the idea and improve the draft (that is what we were
> hoping for - improving an INITIAL idea), please contact me directly as the
> work will still continue outside the IETF.
>

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 17 Nov 2017 06:27:28 +0800

Hi Martin,

thanks for the reply. In general, I am a bit puzzled by the fact that 
you focus your attention on OCSP stapling. The proposal does not address 
or try to improve that in any way. The fair and right comparison from an 
engineering standpoint of view would be to compare it with OCSP over 
HTTP. It seems to me that this is a pretty important point that probably 
you might have ... missed ? Don't you agree? Have you read Section 3 of 
the draft ?

After all, even when using OCSP stapling, the OCSP response need to be 
retrieved by the communication party - that is what we should talk 
about, I think.

This said, let me try to address your points where relevant.. I always 
enjoy an healthy discussion :D My responses inline.

> https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-ocsp-stapling/
This report provides a good description about OCSP stapling, and I do 
not disagree that in the environment where this report is actually 
relevant (Browser), that is a great solution. As pointed out at the end 
of the report, however, it seems that its adoption is far from being 
widespread - the report says that only 20% of the website actually do 
adopt stapling (Feb 2017).

Interesting post, but I do not think is relevant for the proposal 
evaluation. In the view of the two solution not to be in competition but 
complementary, can you explain why this is relevant for the proposal 
evaluation ?
> And here is some info on its relative prevalence:
Thanks for the link.. probably is the lack of sleep but it seems a bit 
difficult to interpret the data. In particular it seems that the first 
graph is related to the current session, while the second is the total 
submission of OCSP stapling reported by Firefox ? If that is the case, 
it would be interesting to know what is the percentage with respect of 
all the website visited. If that is correct, than the numbers seem quite 
low (I think I am interpreting this graph wrong because the numbers 
seems way too low...) - 15/20M is not a large number calculated daily. 
But as I said, I must have the interpretation wrong - could you please 
provide some details about how to interpret the data ? The third graph's 
numbers seem more in the ballpark of what I would expect, but without a 
percentage of how many websites actually use stapling, it is difficult 
to interpret the data.

As I said during the meeting, I am NOT discounting the value of OCSP 
stapling - I never did. It is a good approach that has been around for 
quite a while and has its merits. If in the browsers' / web environment 
that works fine, great. But I do not think this solution works for 
everybody. And, as explained in the first paragraph, I think that the 
comparison should be done with OCSP over HTTP instead.

Providing a standard that describes how to use DNS in environments that 
have different constraints and characteristics than the environment you 
are probably used to, seems, to me, a good idea for providing 
interoperability for those environment that might require a different 
solution.

Also this link, although interesting, does not qualify as a relevant 
point for the evaluation of the proposal. In the view of the two 
solution not to be in competition but complementary, can you explain why 
this is relevant for the proposal evaluation ?
>
> To address your points:
> * The primary part of a CA workload is signing, not storage and 
> retrieval of OCSP.
I do strongly disagree with this statement. The primary "part" or better 
role of a CA is to provide a trust path for applications to be able to 
authenticate and protect data and communication. The load for signing 
certificates is, actually, negligible. On commodity servers you can 
easily have the capacity to address practically any load (I grant you 
that today's HSM really fall behind when it comes to 2017 standards... 
). For example, in my previous job, our (internally developed) 
certification system could easily crank out 500M certificates a day on a 
single server (full process: certificate requests -> server -> 
certificate signing -> certificate returned to the client) [this is real 
data].

For the storage and retrieval of OCSP I am not sure why you say that 
that is not part of the primary CA's responsibility. We can argue about 
how the revocation system might be improved (I proposed several times to 
open a WG to address, at least, the revocation issue in PKIX but, 
unfortunately, that was at times ignored and at times rejected with the 
"we don't want to do PKIX anymore" pointless rant) - but that is not the 
scope of the proposal here. Since today's trust model is based on the 
availability (and checking) of revocation information, a CA should 
provide revocation information and make it available as much as possible.

This said, I do not think this is a relevant argument/point for the 
evaluation of the proposal. If you disagree, can you please provide a 
more extensive argument for the above statement and why it is relevant 
in this case ?
> * Stapling provides superior access, security and (critically) 
> privacy.  DNS would not be any significant improvement over CRL or 
> OCSP privacy.
Again, I am not saying using DNS is an improvement over OCSP stapling - 
since they are not in competition and address slightly different 
problems (after all, OCSP stapling still required OCSP over HTTP, right 
?). Actually there are many good arguments about the fact that the 
distributed nature of the DNS would actually help in case of experienced 
downtime of OCSP responders or DDoS attacks. The party who staples the 
response, still need to access the OCSP responder at some point - DNS 
could be a viable fallback mechanism to provide business continuity.

If possible, I would like you to qualify more your statements on these 
three points. Here's my attempt at providing some considerations about 
your generic statement above:

  * In which way stapling provide superior access ? What about who has
    to retrieve the response, that is not OCSP stapling but OCSP over
    HTTP. This is the transport protocol we should compare to, not OCSP
    stapling which is orthogonal to the proposal. Do you disagree? If
    so, can you tell me why?

  * In which way OCSP stapling is superior for security ? Since OCSP
    stapling depends on the ability to retrieve the response in the
    first place, I would say that the comparison should be with OCSP
    over HTTP from this point of view. If you read the draft, the
    security considerations cover this topic. Once the response is in
    the hands of the client or server, then the in-band deliver to the
    other party is secure, but OCSP over DNS does not prevent using OCSP
    stapling where supported.

  * When it comes to OCSP and privacy, the two solutions are not that
    dissimilar since the client never contacts the CA's DNS server
    directly, IMHO. I do not think that the proposal weakens today's
    situation (in the vision of 20% deployment). OCSP stapling is, in my
    opinion, far worse from this point of view when it comes to client
    certificates (clients have to directly retrieve their own OCSP
    response in order to be able to staple it, don't they ?), IMHO.

> * That thread you cite is very old and not any basis for a decision in 
That is correct, it is an old thread and was provided as an example - as 
I said during the presentation, the idea is not new. However, I think 
that age has never qualified as a valid technical consideration :D So I 
do not understand your point here. "old" is not "bits on the wire". 
Sorry, I do not want to be polemic here, but I would like to focus the 
discussion on the technical merits. If the thread contains reasonable 
and sound technical considerations, why those can not contribute to a 
decision in 2017 ? Can you please qualify more your statement ?

> You didn't address the comment I made about the cache - stapling has 
> the virtue that it results in a cache of the OCSP in exactly one 
> place: the entity that holds the certificate. DNS caching would result 
> in copies in DNS caches throughout the network.
And this is wrong because.... ? Wouldn't be the same argument for other 
protocols like DANE as well ? I think that leveraging distributed cache 
to bring the data actually closer to where it is needed is actually a 
very good thing, not a bad one.

Have you considered the advantages of cross-application caching ? 
Stapling does not provide that. But again, you would have to compare the 
caching capabilities of HTTP to the ones of DNS (same argument, let's 
compare apples with apples, not apples with apple juice)
> certificate-holders.  The number of places that HTTP fails and DNS 
> succeeds is not significant enough to be relevant.
Martin, the world is more complex than you picture here. You say it is 
not relevant, but I do disagree with this statement. What works for 
browsers might not work in other (maybe more constrained) environments 
like class1 devices, corporate environments, restricted networks, etc.

In general, I would say, that the proposal has good technical merits and 
I think I did address all of your points - the time for the presentation 
was not enough and even the time to actually reply was insufficient, I 
hope I clarified all your doubts with this very detailed reply.

I am actually quite surprised about this resistance to even given the 
idea a shot but that is what happened. I wonder how many people did 
actually read the proposal, and how many of them have experience running 
large CAs or network with large number of mutually authenticated 
objects/devices/agents. From the type of discussions, questions, and 
remarks it seems that the set is pretty small.

Although, as I said, I am an old-time believer... I do not think it is 
worth proposing more work here unless the technical evaluation is 
properly done (I am a very reasonable person and very open to 
discussions, but that is not what happened, IMO). In particular, I think 
that the SEC dispatch really does not provide presenters enough time to 
give ideas a fair shot (especially anything that touches, in any way, 
established TLS practices) because the limited amount of time and 
because the audience might not have the technical expertise in 
particular areas to provide sound technical judgments.

Even someone as expert as you that does such amazing work in TLS have 
completely missed the main point (OCSP Stapling instead of OCSP over 
HTTP) in a very short draft. Maybe it is my fault, have I forgotten to 
spell it out explicitly ? Honestly, I did not think there was much need 
for more than what is in Section 3 of the document - did you miss that 
section or you just disagreed with the considerations there ?

I already sent this feedback to the SEC dispatch chairs and I hope it 
might help to improve future sessions for the people who will be willing 
to be shot at. This experience, sincerely, made me regret taking this 
work to the IETF - a feeling shared among many newcomers, as we all know.

Thanks again for your reply, looking forward to your (or other people) 
reply,

Cheers,
Max

>
> On Thu, Nov 16, 2017 at 5:08 PM, Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     although the I-D was not adopted by IETF, I have one question and
>     I would like to provide some comments related to proposal that
>     might have not been conveyed or stressed enough.
>
>     The question is: in order to effectively move forward with our
>     work, how can we request the allocation for the DNS RR type for
>     OCSP response data ? Is there a possibility to get it allocated
>     even if the submission will be an individual one ?
>
>     First of all, although mechanisms like OCSP stapling exist and are
>     used in (some) environments like Web/Browsers [*] , there are many
>     environment where that is not happening (not implemented). Even
>     when stapling is supported, the parties (client and server) still
>     need to retrieve the OCSP responses somehow and HTTP/s might not
>     be a viable option - maybe I failed in conveying this point, but I
>     think it is a very important one. Last but not least, reducing the
>     amount of data sent for establishing secure sessions might not be
>     relevant for large devices (e.g., laptop/etc.) or generic
>     applications (e.g. browsers), but it definitely matter in the IoT
>     space.
>
>     On the costs associated with the distribution of revocation
>     information, I think that the comments on that were not really
>     based on data. Large PKIs exist outside the ICA that issue
>     BILLIONS of certificates and the proposed solution might not only
>     be encouraged but required to provide revocation support in those
>     environment.
>
>     This said, I am still a bit confused about the reasons for not
>     adopting this work since it would improve access to revocation
>     information, lower operational costs for CAs (and thus lowering
>     the costs of certificates management), and, in general, provide
>     more options for a more secure networking environment.
>
>     Last but not least, I would like to thank all the people that
>     actually provided support and valuable comments (from ISC to
>     individual contributors). Also, in case any of the people on the
>     list are still interested in pursuing the idea and improve the
>     draft (that is what we were hoping for - improving an INITIAL
>     idea), please contact me directly as the work will still continue
>     outside the IETF.
>
>     [*] = Fun fact, here's reference of a thread in the mozilla sec
>     lists where this proposal was positively considered even back in
>     2011 -
>     <https://groups.google.com/forum/#%21topic/mozilla.dev.security.policy/pfFLvTFZxE8>
>
>

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