Subject: [keyassure] DNSSEC data in the TLS channel

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 10:00:08 -0400

This is a very interesting conversation that may have some important
design consequences.

Do not make assumptions as to what a CA would or would not sign. If
there is a sound architecture and a reasonable business model there
will be a CA willing to take the business.

At one point I seriously considered a model in which every server cert
had an expiry interval of 2 days and was automatically updated. If we
were starting from scratch it would make a much better business model
than the OCSP plus cert model we have fallen into. So signing every
day is not a problem.

That said, I can't see the value of putting the DNSSEC material into
the cert. What value do you see in having a signature over the DNSSEC
material? Why can't the DNSSEC material be stapled to the cert package
in the same way that OCSP data can be?

Would use of some form of DNSSEC chain stapling in the TLS channel be
an acceptable means of meeting your optimization goals?

I see the following potential choices

1) CERT records have no prefixes and multiple keys per service is not supported.

2) Use unprefixed CERT records for performance optimization with one
key per service and fall back to prefixed records in the multiple key
case

3) Use prefixed CERT records (either hashes or labels) in the DNS and
use TLS channel stapling for performance optimization.

4) Use unprefixed CERT records for clients and require the use of TLS
channel stapling for performance optimization and multiple keys which
would entail some form of per-key generation of the RR signatures.

I think (1) would be a big mistake. It is a weak security model that
leads to administration nightmares. I also think (4) should be
rejected as getting the per-key signatures into the server would
probably require us to do prefixing anyways.

Comparing 2 and 3, both allow for the CERT record lookup to be
optimized out of the critical path but (3) allows for the lookup to be
eliminated entirely while it is still required in (2).

The other big advantage of (3) is that it encourages clients and
servers to implement OCSP stapling which is a major performance and
network optimization. The cost of a DNS lookup is rather marginal
compared to the cost of an OCSP request which requires a TCP channel
startup and teardown.

Is there some reason that we should avoid this model?

Is it possible that we could agree on (3) as a means of meeting both
the optimization requirement and the multiple key requirement?

On Thu, Sep 9, 2010 at 8:45 AM, Adam Langley <[email-masked]> wrote:
> On Wed, Sep 8, 2010 at 10:47 PM, Steve Schultze <[email-masked]> wrote:
>> Won't sign what?
>
> The DNSSEC chain is just an X509 extension.
> https://www.dnssec-exp.org) is running one now if you want an example.
> No CA should sign a certificate with a random extension that they
> don't understand.
>
> Embedding DNSSEC chains in X509 extensions is easy on the server side:
> no change to the server is needed, you just install a different PEM
> file. The disadvantage is that extensions are in the part of the
> certificate which is signed. That's fine for self-signed certificates
> but precludes using them in CA signed certificates. Even if you could
> find a CA that is happy to sign the DNSSEC chain, you would need to
> have the CA sign a new certificate each time the chain expired (which
> is likely to be once a week.)
>
>>> In this case, one could imagine
>>> putting the chain in a TLS extension (akin to OCSP stapling).
>>
>> The cert chain or the DNSSEC chain?
>
> The DNSSEC chain.
>
>>> However,
>>> the advantage for a CA signed cert isn't that great. The browser
>>> cannot really avoid the DNS lookup because it would already have
>>> started it before getting the stapled data.
>>
>> Because the DNSSEC chain cannot be embedded simultaneously with the cert chain?
>
> No, the browser would have started the DNS lookup when the HTTPS
> connection was started. (It wants to overlap as much as possible for
> latency reasons.) By the time that the certificate has been received
> the DNS lookup would hopefully have completed.
>
>> Why does it require a TLS extension?  You can't do a DNSSEC chain embed and an X.509 embed together?  (yes, I think I understand why this is the case, but it would be helpful for you to explain.)
>
> In order to put the DNSSEC chain somewhere where the CA doesn't have
> to sign it we would need to move it out of the certificate. That means
> putting it in another handshake message and that means a TLS extension
> to negotiate the inclusion of that handshake message.
>
>
> AGL
>
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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