Subject: [pkix] OCSP over DNS

From: Scott Rea <[email-masked]>
Date: Thu, 02 Aug 2012 10:47:37 -0600

G'day Folks,

yesterday at PKIX we had some folks supporting the proposed OCSP over 
DNS protocol (see: 
https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and some 
folks who said they did not like the idea. Time was short and I failed 
to get further feedback from the folks who "hated" (yes that was the 
exact phrase that was used) the idea as to WHY they do not support the 
idea.
Would those folks be willing to post their objections/justifications to 
the list, and if are not quite ready to make a public declaration, 
please send Max or I an email directly off-list as to reasons why you 
would not support this proposal?

Scott Rea <[email-masked]> or
Massimiliano Pala <[email-masked]>

Regards,

-- 
Scott Rea

---

From: Francis Dupont <[email-masked]>
Date: Thu, 02 Aug 2012 19:32:05 +0200

In your previous mail you wrote:

>  Time was short and I failed to get further feedback from the folks
>  who "hated" (yes that was the exact phrase that was used) the idea
>  as to WHY they do not support the idea.

=> I attended another session so I didn't follow the presentation itself
but according to the slides in the meeting materials I am afraid I deeply
dislike the idea (i.e., haters++). BTW the DNS is in no way a "transport".

Regards

[email-masked]
(and for this time I am making an exception, [email-masked] too)

---

From: Scott Rea <[email-masked]>
Date: Thu, 02 Aug 2012 11:41:14 -0600

Thanks Francis!

could you elaborate on WHY you do not like this proposal? We do not have 
any concrete data on what is at the source of haters' objections. There 
was a comment in the meeting about further burdening DNS, which we 
accept as a concrete reason for objection, but other than that, we seem 
to just have ephemeral statements of preferences rather than concrete 
reasoning behind the preferences - are you willing to lay out you base 
reasons for rejection?

Regards,
_Scott

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 02 Aug 2012 17:43:37 -0400

Hello Francis,

Thanks for the comments - as Scott wrote, it would be interesting if you could
let us know what is, specifically, that you do not like and how this could be
a problem for PKIs (why it should not be standardized).

Our attempt is to provide another mechanism that CAs can use (if they want to)
to distribute pre-computed OCSP responses - cheap, easy to deploy, and that
would deliver (by using the DNS caching) the response close to the client (thus,
enhancing their availability).

Issue:
- We need to improve the availability of OCSP responses. Today, the quality of service
   across different CAs is not enough for applications to enable strict revocation
   checking (issues: costs and connectivity issues (eg., latency))

The starting points for our proposal are:
- We should try to provide an infrastructure for OCSP checking (rev info checking)
   that minimize unavailability of data because of network issues
- Pre-computed OCSP responses can be provided via different access methods
   (e.g., HTTP, CDNs, FTP, etc.)
- For high-volume websites, huge bandwidth is required on the OCSP side to provide
   services that meet the expectations (and high costs) of clients
- Availability of OCSP responses could be increased by using widely deployed and
   distributed services like DNS / DNSSEC

Given the problem, the well-defined boundaries, and the considerations on the need
to address the availability of revocation information, we think that this I-D could
provide a well-targeted mid-term solution to the issue.

Any input on the matter that takes in consideration the above points, is more than
welcome as the purpose here is to address a real issue that affects practically all
the Internet users.

Best,
Max

-- 

tel.718-260-4009 | web: http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director & Founder, OpenCA Labs
Research Professor, NYU Poly
Assistant Director, CRISSP

http://crissp.poly.edu

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Aug 2012 23:47:40 -0400

Dear colleagues,

I apologise I had to leave the PKIX meeting yesterday after the CAA
discussion; I was double booked.  Also, for that reason I wasn't
really prepared for PKIX (indeed, it was only due to a fortunate IM
that I knew I needed to pay attention.  Thanks to Richard!)

So, I hadn't read draft-pala-rea-ocsp-over-dns prior to today.  I just
did, although very quickly.

On Thu, Aug 02, 2012 at 10:47:37AM -0600, Scott Rea wrote:

> https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and
> some folks who said they did not like the idea. Time was short and I
> failed to get further feedback from the folks who "hated" (yes that
> was the exact phrase that was used) the idea as to WHY they do not
> support the idea.

My natural reaction when someone says, "%$#* that, just put it in the
DNS," [http://twitpic.com/9au7p5] is to break out in hives, so I get
why people "hate" this proposal.  That said, it is not the dumbest
idea I've heard.  It's not even the dumbest idea I've heard this week.
If I understand it correctly, all the data ends up in a DNS zone
operated by the CA, and the goal is mainly to produce a mechanism that
is low latency and can take advantage of distributed caches.  If
that's right, then it seems to me like a possibly viable notion.

The draft as it stands needs an enormous amount of work, I should
note.  I have some reservations about the DNS URL arrangement, at
least to the extent I understand it (which isn't very far).  As it
stands, the draft doesn't say at all how to look these records up, nor
what RRTYPE they use (I suspect a new one is needed, and we'll need to
specify it).

Those issues are all just issues about the details in the document,
however, and could be fixed.  Also, it seems to me that this approach
could help with a significant problem that CAs have.

There are some environments, of course, in which this approach won't
work.  I'm nervous about the speed at which a new RRTYPE could be
deployed, and that might be a dealbreaker.  Also, sometimes
applications just can't get unmolested access to DNS, and that might
be another problem that means this won't really help.  But perhaps
these things could be mitigated, and some additional iterations will
probably clarify some of it.

I am willing to help with the document if the authors want to pursue
it.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Sean Leonard <[email-masked]>
Date: Fri, 03 Aug 2012 00:41:39 -0700

> that's right, then it seems to me like a possibly viable notion.

For those who were not at the WG meeting, to reiterate a point that was 
mentioned:

There is concern that "just putting it in the DNS" will overload DNS 
operators. This should be addressed through empirical data, the 
conclusions based on which ought to be mentioned in the RFC.

[Note: it shouldn't overload DNS operators--if they are all under the 
CA's domain, then it only "overloads" the CA operator, but this should 
be cheaper than running a true OCSP server. However, it may place more 
overhead on intervening DNS caching servers, as distinct from DNS 
operators that have the authoritative records.]

> what RRTYPE they use (I suspect a new one is needed, and we'll need to

To iterate a point of my own volition (with a nod to my co-author 
colleague):

http://tools.ietf.org/html/rfc4501
S. Josefsson, Domain Name System Uniform Resource Identifiers

Whatever is in ocsp-over-dns must follow RFC 4501, which specifies:
  dns://192.168.1.1/some.ocsp.ca.service.com?type=SOMETYPE

If you have a problem with the format of DNS URIs, it's about six years 
too late...but at least RFC 4501 provides a comprehensive treatment of that.

Sean

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Aug 2012 06:29:42 -0400

> conclusions based on which ought to be mentioned in the RFC.

I don't see how this could overload a DNS operator.  But anyway,
that's a rather unconvincing argument, for taken to its logical
conclusion it would preclude putting anything more in the DNS.  Given
that the proposal puts everything into a single zone (well, one or
more zones per CA, but anyway it uses the normal top-down DNS lookup
model), I simply don't see any objection on operational grounds,
unless the responses are very large (that would have implications for
caches).  

>  dns://192.168.1.1/some.ocsp.ca.service.com?type=SOMETYPE

Yeah, that was more or less what I was expecting, and the draft
doesn't look to my bleary eyes like it's following that.  It also
doesn't refer to RFC 4501, so I think that might be the first problem.

I'm more concerned about the RRTYPE and responses, though, for the
reasons above.  Fixing up the way the URI is presented would be
irrelevant if we learn that every response is going to be 400k.  I'm
pretty sure that's not the case, but I can't tell from the draft.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 03 Aug 2012 13:32:05 -0400

On 08/03/2012 03:41 AM, Sean Leonard wrote:
> [...] There is concern that  "just putting it in the DNS" will
 > overload DNS operators. This should be addressed through empirical
 > data, the conclusions based on which ought to be mentioned in the
 > RFC.
 >
 > CA's domain, then it only "overloads" the CA operator, but this
 > should be cheaper than running a true OCSP server. However, it may
 > place more overhead on intervening DNS caching servers, as distinct
 > from DNS operators that have the authoritative records.]
 >

This has been an argument that has been present since... 10yrs ago.
In general, I would agree that you should not overload the DNS (e.g., using
DNS to distribute any type of certificates - like user certs - bad idea),
however I also think that the scope we identified is very well defined and
that will *NOT overload the DNS at all*.

Also, since these responses go through DNS, it might solve the problem with
some environments (e.g., web-portals) where traffic toward OCSP servers
might be blocked - usually DNS lookups are enabled in that environment.

This would help to enable revocation checking also before having complete
access to the net - e.g., revocation checking might be enabled also in hotel-like
portal access.

[...]
 > http://tools.ietf.org/html/rfc4501 S. Josefsson, Domain Name System
 > Uniform Resource Identifiers

I think that you (and some others in the list) are missing the point that we need to specify
a bit more than just a URI.

There are several problems with the RFC 4501 to be used in this proposal. Keep in mind that
the RFC is meant to specify DNS URIs, but it does not cover the fact that we need to specify
additional information that the client MUST use to build the final URL. In particular, we 
can not
use RFC 4501 URLs because of two important points (I guess this will put an end to this
discussion on using RFC 4501):

- RFC 4501 does not allow to specify dns vs dnssec. If an operator wants to convey that the
   returned DNS response WILL be signed, if the URL does not carry that information, the 
client
   can not tell if the received response should be signed or not.

   As it was said in another message, DNSSEC can guarantee the non-existance of the 
record, i.e.
   if a record is not found and the response is correctly signed, the client will know 
that it has to
   use another source. On the other hand, if a record should be signed, but a non-signed 
record
   is received, this is a source of attack and should be treated as such.

- In order to identify the certificate that needs to be checked, the client has to use an hash
   function to build the DNS entry that should be looked up for. We have two options here.
   Either we stick with one algorithm (default) as we did in the past for most algorithms (but
   this would violate the "algorithm-agility" principle), or have a way to specify 
different algorithms
   so that the client knows what to use when building  the DNS URI. If we go with the second
   route (which I think we should) we need to be able to specify the algorithm. RFC 4501 is to
   be used to extract DNS records, and works fine for that, however we need to be able to 
specify
   the algorithm. We still have not addresses if we want to be able to provide the 
possibility to pass
   also additional parameters that are specific for the algorithm (as pointed out in 
another email
   the GOST hash is one of those algorithm that requires additional parameters).

These two reasons make RFC 4501 *not suitable* to specify DNS URI for OCSP responses because
we need to provide information on how to get to the final URL.

Why can't we just specify the full address of the certificate in the DNS URI ? The answer 
is simple:
you don't have the final DER representation of the certificate until the CA has signed it, 
so you can
not include that value in the certificate to be signed.

The only workaround to this would be if we use a hash of the serial number to be pre-pended to
the domain the CA is managing - however I would suggest against it as this might also be 
an issue
with some CA software (the serial number might be assigned randomly at signing time and 
changes
to the software might be required - a static approach would be easier to deploy).

Last but not least, the final I-D could also provide the possibility to specify multiple 
supported algorithms
(eg., future transitions among algorithms). Also in this case RFC 4501 would not provide a 
suitable
solution for that.

Cheers,

-- 

Massimiliano Pala, Ph.D.

http://crissp.poly.edu

---

From: Adam Langley <[email-masked]>
Date: Fri, 3 Aug 2012 13:40:09 -0400

I conducted an experiment for testing the viability of wide-spread
OCSP over DNS with Chrome. Please see the writeup below, although note
that it was conducted some months ago and so words like "today" don't
actually mean that.

-----
* This has only been enabled in Canary and Dev channels. These channels have
  users who have opted in to running unstable versions of Chrome and so are not
  representative in some ways.

Setup:

For each HTTP request, we consider if it meets all of the following criteria:

1) The request went over HTTPS
2) The reply didn't come from the Chrome cache
3) The certificate rooted at a known public root (i.e. the connection was not
   MITMed with a user-installed CA cert)
4) The certificate chain passed through at least one of the following:

AAACertificateServices
AddTrustClass1CARoot
AddTrustExternalCARoot
AddTrustPublicCARoot
AddTrustQualifiedCARoot
COMODOCertificationAuthority
SecureCertificateServices
TrustedCertificateServices
UTNDATACorpSGC
UTNUSERFirstClientAuthenticationandEmail
UTNUSERFirstHardware
UTNUSERFirstObject

5) It was more than 10 minutes since the last time we tried a DNS lookup for
this experiment.

If we find a qualifing HTTP request then we issue a TXT lookup for
"wibble.comodoca.com" via the system's resolver library.

If the DNS reply comes back in under 10 milliseconds, then we consider it a
local cache hit and discard it. (We have an in-process cache as well as any
system cache.)

Any remaining replies are considered a `success' if the system resolver
returned successfully and we find the string "wibble" in the RR data payload.
Otherwise they are considered a `failure'.

The time taken for the resolution is recorded for both `success' and `failure'
responses. Recorded time values are capped to 10 seconds.

Results:

As of today we have 71,833 successes recorded. The distribution looks as
expected: a big hump with a fat right tail. The median is 95ms, 90% at 533ms,
99% at 5961ms.

We also have 3,537 failures recorded. 84.7% of these have times > 10s.  There
is also a 3.5% peak at 3s (i.e. 3 attempts with a one second retry). The
remaining ~10% is scattered mostly uniformly.

Conclusions:

The median is a lot better than an OCSP reponse (which is 268ms at the moment),
but the failure rate (4.7%) is very high.
-----

Cheers

AGL

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 03 Aug 2012 13:40:41 -0400

Hello Francis,

Issue:

Best,
Max

-- 

Massimiliano Pala, Ph.D.

http://crissp.poly.edu

-- 

Massimiliano Pala, Ph.D.

http://crissp.poly.edu

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 03 Aug 2012 13:44:45 -0400

Hello Francis,

Issue:

Best,
Max

-- 

Massimiliano Pala, Ph.D.

http://crissp.poly.edu

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Aug 2012 14:16:44 -0400

> might be blocked - usually DNS lookups are enabled in that environment.

I think you need to be a little more careful about your assumptions in
this case.  In my experience, large numbers of web portals permit DNS
lookups _for some value of "permit"_.  Many of them munge or otherwise
mangle the DNS responses, and I have seen shipping DNS middleboxes
that return an A response no matter what RRTYPE you looked up.  The
most egregious of these things are gradually getting ditched with the
deployment of DNSSEC, but there's still a lot of garbage out there.

This is especially true on public wifi networks, one of the places
that good revokation checking is most urgently needed.

This isn't an argument against the idea, just a note of caution about
the operational realities of the network.

Best,

A 

-- 
Andrew Sullivan
[email-masked]

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Sun, 5 Aug 2012 22:16:01 +0000

Hi Scott and Massimiliano,

As someone who has implemented a very large OCSP service for a well-known CA and implemented parts of the software infrastructure very large DNS service operator, I think your proposal has general merit. I have reviewed the proposal although I am still thinking through some of the responses I've seen so far and apparently have to catch-up on details such as RFC 4501.

First, I would respond to the comments about overloading a DNS operation. In my experience, DNS is significantly lighter than a TCP-based OCSP and would take very considerably less computational (and likely network) resources once implemented than an equivalent OCSP responder service. I've long thought, since the initial inception of the "lightweight OCSP profile" in RFC 5019, that an even lighter way would be to use UDP. It has been my experience that the TCP connection overhead is not only significant for increased client latency, but also significant in the computational resources of the servers. 

Besides the possibility of using UDP to reduce latency, I see the ability to use anycasting, quite typical in DNS service providers, to be a viable option for distributing load. In earlier experiments, I have noticed that anycasting TCP services does not work well for some clients, most likely due to network misconfiguration. That data point is now a few years old.

I do have a one question when I was reading through your proposal text. It sounds like you are considering the DNS query as between the client directly to the CA's DNS service. Why not make use of the distributed nature of the DNS to make the request to a local resolver and possibly get the advantage of local caching? That is a more typical model for DNS (e.g. make a request to a local resolver; local resolver makes recursive requests to authoritative servers). My only observation about this approach is that using a "dnssec" URI doesn't make sense since local resolvers will do the DNSSEC validation, not the client.

One potential downside I see is with the security guarantees. It is pretty easy to forge UDP responses, and although the OCSP response is signed, one could invent cases where "OCSP good" responses were replayed (when the certificate had been revoked, but was still within the OCSP expiration window) or worse: the unsigned "Unknown" response could be blasted much easier than if the service were implemented over TCP.

That all said, I'm on board in concept.

Thanks,

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Rea
Sent: Thursday, August 02, 2012 12:48 PM
To: [email-masked]
Subject: [pkix] OCSP over DNS

G'day Folks,

Regards,

-- 
Scott Rea

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Aug 2012 12:47:10 -0400

There are pros and cons to using DNS. What we really need to do is to
measure cases where DNS transport works but UDP does not and the cases
where UDP transport works but DNS does not and see whether DNS is
actually useful.

The only potential benefit of using DNS is that it may be easier to
get connectivity through firewalls.

The potential benefit of using UDP is that an OCSP response could
consist of one request packet and a series of response packets. That
is probably enough to satisfy an reasonable OSCP transaction.

The other design question is whether the client should query the
responder of a CA or direct requests to a gateway chosen by the client
(or client provider) that is known to meet an acceptable QoS. The
problem I see with the OCSP over DNS approach is that the complaint
from the browser providers is not merely that OCSP over HTTP is slow,
it is that they are really unhappy with the reliability of some of the
CA services.

Now that might be possible to address if there was a consequence to
having shitty OCSP service. I would like to see the padlock icon not
show if the CA can't provide a decent responder. But they may not go
for that.

-- 
Website: http://hallambaker.com/

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Aug 2012 07:34:11 +0200

Scott,

How is this proposal positioned in relation to OCSP stapling.
Would we need either or, or both?

I've seen two questions on what RRTYPE you would use, whether a new need
to be defined and what deployment issues that would bring to the table.
What is your position on that?

/Stefan

---

From: Scott Rea <[email-masked]>
Date: Wed, 22 Aug 2012 11:34:56 -0600

Sorry for the long delay answering you here Stefan, I was traveling...

In my mind, we want to enable both these since they are aimed at two 
different stakeholder groups - one option is a decision for site owners 
(stapling) and the other is a decision for CAs (OCSP-over-DNS), even 
though they may both be considered to be aimed at performance 
improvement for certificate validation checking.

In terms of RRTYPE, that is still under discussion and specifically 
deployment is the main consideration here. There are certainly pros and 
cons to defining a new type or not, and it may be a question we settle 
by taking it to the list. For now, perhaps I can encourage Max or Olafur 
to regurgitate a summary of our internal discussions to replay for the 
list some of our thinking to date.

Regards,
_Scott

On 8/14/2012 11:34 PM, Stefan Santesson wrote:
> On 12-08-02 9:47 AM, "Scott Rea"<[email-masked]>  wrote:
>
>> G'day Folks,
>>
>> Scott Rea<[email-masked]>  or
>> Massimiliano Pala<[email-masked]>
>>
>> Regards,
>>
>> -- 
>> Scott Rea
>>

-- 
Scott Rea