Re: [lamps] [saag] Proposal for OCSP over DNS

["Dr. Pala" <[e-mail]>]

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:
> On Mon, Oct 23, 2017 at 5:13 PM, Paul Hoffman <[e-mail]> 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)?
> 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.
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm