Re: [dane] Draft for serializing DNSSEC chains

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil <[e-mail]>wrote:

>  On 7/6/11 9:37 PM, Martin Rex wrote:
>
>  > > (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?
>

Well if any such problems exist it should be possible to state them with
specificity. Otherwise the assertion is FUD pure and simple.

The distinction between design complexity and operational complexity was not
originally clear because no such distinction had been proposed. It was only
after I pointed out that there are empirical criteria for design complexity
that Matt decided that he was talking about operational complexity.

There are empirical criteria for operational complexity as well:

* Number of administrative actions required to perform an operation
* Number of independent services that must be configured to achieve an
action
* Dependence on support for specific capabilities in deployed infrastructure
* State that must be maintained at services

Adam's proposal is better than the previous one on each of these criteria
above. The proposal to use the pickled chain in an OCSP token is better
still.




> > > 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.
>

Well the purported issue is not at all clear to me and I have twenty years
experience of PKI.

I don't think that the issue you claim exist is real. I am certain that you
have not substantiated your claim.

If you really think that there is a problem explain it to your CTO and then
let him tell us that he thinks there is a problem. If you and Matt really
think there is a problem you should be able to explain it to Burt. In terms
of years of experience he out-ranks everyone here as far as I am aware.

If Burt is willing to state that he is sure that there is a problem then I
am willing to re-read your messages.

If Burt is not willing to endorse your claim or you do not have sufficient
confidence in it to take it to him then I am not willing to attempt to
decipher your claims either.

 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?
>

I don't think that you understand the TLS protocol or the proposal being
made.

All the pickled DNSSEC chain provides is one means of establishing the
validity of the key. It does not have to be the only means.

The problem of Internet time synchronization means that there is an
intrinsic uncertainty of +- 25 hours associated with any validation
operation applied to statically signed data.

It is pretty clear to me that any ambiguities that may arise as a result of
DNS operations are going to be of the same order which is not surprising as
they have much the same underlying causes.

Thus I do not see the concerns you appear to be raising as being valid.


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