Re: [dane] Draft for serializing DNSSEC chains

[Eric Osterweil <[e-mail]>]

On 7/6/11 9:37 PM, Martin Rex wrote:
>
> Osterweil, Eric wrote:
> >
> > "Matt McCutchen" <[e-mail]> wrote:
> > >
> > > DNSSEC RRSIGs are properly analogous to OCSP responses; they 
> provide the
> > > same functionality.  (DNSSEC just skipped the intermediate stage of
> > > signed long-term certificates because offline operation was not a 
> goal.)
> > > The motivations and security considerations for DNSSEC chain stapling
> > > are much the same as those for OCSP stapling.
> >
> > Why would you say that?  The two protocols are immensely different 
> and they
> > have much different goals.  Please provide details if you feel this 
> is in
> > err.
>
> I agree with Matt (I hadn't noticed he had already suggested this
> when I wrote my last message).
>
> Processing stapled OCSP responses is similar to processing stapled
> DNSSEC records, although the scope of DANE records is slightly broader
> than OCSP (because it may include issues server endpoint identification).
>
> >
> > > (Which raises another point.  OCSP stapling uses a TLS extension.  
> This
> > > is a more appropriate design than embedding the data in the cert;
> > > additionally, the latter is impossible to do backward-compatibly 
> with a
> > > CA-signed cert.
> >
> > OK, so let's discuss this.  Are you aware of any operational hurdles 
> that
> > may have hampered OCSP (for what it was intended, let alone for 
> something
> > new)?
>
> AFAIK, the original TLS extension was a single OCSP response, and then
> all CAs added intermediate certs so that a single OCSP response was
> no longer sufficient to validate a server certificate.
>
> The proposal for a new TLS extension to carry more than a single
> OCSP reponse is still an internet draft:
> https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/
>

Yes, but are you aware of the _operational_ problems?  Is the 
distinction between design complexity and operational complexity not 
clear?  If so, is anyone else on the list concerned?

>
> >
> > > For DNSSEC chain stapling, embedding is possible.
> > > Chromium may find the ability to use externally automated DNSSEC chain
> > > stapling with existing web servers to be sufficient justification for
> > > choosing the poorer design, but does IETF?)
> >
> > This will lead to disaster, and opens up new attack vectors.
>
> Could you elaborate?  I fail to follow.
>
I think (having restated the same position in multiple different ways 
over the last several days) I have outlined the objection pretty 
clearly.  If you are not clear on them, please re-read my previous 
emails and I can clarify any specific points you don't follow.

>
> The security design of DANE does not have a dependency on the transport
> that is used to convey the signed DNS records.  Neither does OCSP and 
> CRLs.
>
Actually, it very much does.  If operational issues open attack vectors 
(which they will in this case), then I think the security design (by 
definition) has a dependency.  Is the vector still unclear?

Eric