Subject: [lamps] Draft New Version (was Re: [saag] Proposal for OCSP over DNS)

From: "Dr. Pala" <[email-masked]>
Date: Thu, 26 Oct 2017 15:59:06 -0600

Hi all,

I just want to let everybody know that we manage to send in the latest 
version of the draft that better organizes the text and incorporates the 
previous work / I-Ds into one:

    https://datatracker.ietf.org/doc/draft-pala-odin

comments, feedback, etc. always welcome :D

Cheers,
Max

On 10/23/17 3:38 PM, Dr. Pala wrote:
>
> Hi Paul, all,
>
> the way I personally see this is not only related to Internet CAs / 
> website-oriented TLS, but also as a way to distribute the revocation 
> information in environments where entities (devices, software, etc.) 
> might be restricted from accessing the global Internet but still 
> allowed to query the DNS. Entities leveraging specific trust 
> environments (e.g., OCF, CMI, etc. ) might especially benefit from 
> this additional distribution mechanism (which is not in competition 
> with existing solutions :D)
>
> Beefing up CAs web infrastructures is what CAs have been doing so far 
> - AFAIK, however that comes at high operational costs that have to be 
> covered somehow :D I think that it will be useful to have an 
> alternative that can be as efficient (if not even more efficient), 
> distributed (info get closer to the client), and that comes at 
> (potentially) lower operational costs.
>
> Just my 2 cents...
>
> Cheers,
> Max
>
>
> On 10/23/17 3:13 PM, Paul Hoffman wrote:
>> On 23 Oct 2017, at 13:54, Dr. Pala wrote:
>>
>>> we are currently working on specifying how to use DNS as a transport 
>>> protocol for revocation information for X509 certificates. In 
>>> particular, we are working on how to leverage the distributed nature 
>>> of DNS to efficiently (and at lower operational costs) distribute 
>>> OCSP responses to applications/devices/etc.
>>>
>>> We started this work sometime ago but never really had the time to 
>>> finish it. Now it seems we can focus more on the topic and would 
>>> like to discuss this work in a more public venue.
>>>
>>> We currently have two similar I-D submitted (that should probably be 
>>> re-edited and merged):
>>>
>>>  * https://datatracker.ietf.org/doc/draft-pala-odin/
>>>  * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/
>>>
>>> EKR suggested that this may be another topic for the SEC-DISPATCH 
>>> meeting. Can we have 5-10 minutes for this @IETF100 ?
>>
>> These sound like "we want HTTP over UDP to save latency, so we'll 
>> just substitute DNS". That's certainly an option, but it hasn't been 
>> a popular route in the IETF. Are the busy CAs asking for this? Is 
>> there a reason why they can't just beef up their web infrastructure 
>> (like their customers are)?
>>
>> --Paul Hoffman
>
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Oct 2017 08:16:45 -0400

On Mon, Oct 23, 2017 at 5:13 PM, Paul Hoffman <[email-masked]> wrote:
>> protocol for revocation information for X509 certificates. In particular, we
>> are working on how to leverage the distributed nature of DNS to efficiently
>> (and at lower operational costs) distribute OCSP responses to
>> applications/devices/etc.
>>
>> We started this work sometime ago but never really had the time to finish
>> it. Now it seems we can focus more on the topic and would like to discuss
>> this work in a more public venue.
>>
>> EKR suggested that this may be another topic for the SEC-DISPATCH meeting.
>> Can we have 5-10 minutes for this @IETF100 ?
>
>
> These sound like "we want HTTP over UDP to save latency, so we'll just
> substitute DNS". That's certainly an option, but it hasn't been a popular
> route in the IETF. Are the busy CAs asking for this? Is there a reason why
> they can't just beef up their web infrastructure (like their customers are)?

Since QUIC is 'TCP++ over UDP' and flavor of the month, OCSP over QUIC
is probably a more viable route.

The expiry of the Micali and Kocher efficient revocation patents mean
that we now have options beyond OCSP which is what we are currently
focused on at Comodo.

I have proposed OCSP over DNS several times in the past. The problem I
ran into was that the chief concern of the browser providers is
latency. And some are unwilling to accept any proposal that increases
latency in any way for the sake of public safety.

Attempting to use DNS as transport is highly problematic. Many
networks block unknown RRs for a start. It is hard enough to get
DNSSEC to work right.

That led me to an approach where the OCSP and DNS lookups were
combined into one UDP transaction to a trusted discovery service
combining DNS lookup, OCSP and certificate fetch, aka 'omnibroker'.
That is an approach I will probably be revisiting in the near future.

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 27 Oct 2017 14:54:32 -0600

Hi Phillip, all,

I totally agree with your points - however, I still think that proposing 
this work could have some benefits and can be complimentary to work that 
will tackle more efficient revocation. I would support work in that 
direction and I think that this work could be a good starting point.

In the meantime, providing the additional option to use DNS for the 
revocation info distribution (although more efficient data structures 
might be defined in the future) could help preparing support in software 
out there without the need to modify the data structures for the revInfo.

For OCSP over QUIC (and, please, correct me if I am wrong here :D), I 
personally think that that would be more related to the transport layer 
(more similar to an HTTP endpoint) while one of the main points here is 
the use of the distributed and cached architecture of DNS which can help 
in reducing operational costs for CAs, move the revocation data closer 
to the edge of the network, and provide another distribution mechanism 
that can be leveraged by clients (not just browsers.. but also for IoT 
environments when authenticating devices and/or servers) that might not 
have direct access to the Internet but that can query the DNS system :D

Thanks again,

Cheers,
Max

On 10/27/17 6:16 AM, Phillip Hallam-Baker wrote:
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm