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/

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Sep 2010 11:30:31 -0400

On Thu, Sep 9, 2010 at 10:00 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> the cert.

The DNSSEC chain embedding was mostly intended for the sort of folks
who currently have self-signed certificates, or otherwise invalid
certificates. I don't know if they'll bother to adopt it, but the task
of getting DNSSEC resolution ability to the browser is long and
complex, while chain embedding could be supported quickly.

As I've previously noted. If you already have CA valid certificates
then DNSSEC chain embedding (in the certificate or otherwise) is of
more limited value. It would mostly be a performance optimisation and
only a few sites really care that much about performance.

> What value do you see in having a signature over the DNSSEC
> material?

I don't believe that there is any value in having a signature over the
DNSSEC chain (see next answer).

> Why can't the DNSSEC material be stapled to the cert package

The DNSSEC chain could certainly be included in a TLS handshake, in
much the same way that OCSP stapled data is. The advantage of putting
it in the certificate is purely operational: you can take any HTTPS
server and configure it with a different certificate with a minimum of
fuss. A new TLS extension would mean patching the SSL library for
support, then the server to add a new configuration directive etc.

> an acceptable means of meeting your optimization goals?

Yes. It doesn't really matter where the chain lives.

> key per service and fall back to prefixed records in the multiple key

Sites with a small number of keys can list several CERT records. Some
sites have lots of keys and we should support that, although I don't
see it as an immediate priority as long as we have some sort of plan.

Looking up a CERT record on www.example.com for
https://www.example.com works for the majority of sites. If that CERT
record says "Shit, I have lots of keys. You'll should do another
lookup of <hash>.cert.example.com", then that takes care of all the
use cases that I'm aware of. It's slower since the second lookup can
only proceed once the certificate data is available, but that might
just be a cost of have lots of keys. (I understand this to be your
case (2)).

Using prefix labels in the common case (i.e. _tls.www.example.com for
https://www.example.com) doesn't allow www.example.com to be a CNAME,
which is a significant demerit to that design.

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 12:50:22 -0400

> only a few sites really care that much about performance.

One of the things that some people want to use DNSSEC chains for is to
reinforce a CA issued cert with current DNS trust chain information.
While I am not going to accept the parties in the ICANN DNS trust
chain as the only root of trust, I can see applications where I would
want to validate on different chains for different purposes.

In particular if you start going off into bridge-CA land I can see
real advantages.

> support, then the server to add a new configuration directive etc.

OK, that makes sense. I tend to think that fixing the server is a
better plan than messing about with extensions, but it could make
sense.

The problem I would see there would be that X.509 certs tend to have
expected lifetimes of years and DNS data is designed for lifetimes of
days so putting DNS data into a cert does not seem like a good fit to
me.

But assuming that we can patch the TLS library, this would be an option.

> which is a significant demerit to that design.

OK, that makes sense to me.

But Ben Laurie also had an idea which I think is very useful, he
suggested a CERT record value for 'SIHLOK'. Actually he suggested that
this was the previous suggestion but I don't remember seeing that
actually stated.

What I would like is a SIHLOK record that allows me to specify a
pointer to a DNS node where the prefixes are stored. This then allows
for all manner of complications that arise from use of wildcards and
CNAMEs and prefixes to be finessed.

So imagine that I have my server farm with 1,000,000 domains and 1,000
hosts, each of which has one IPv4 address and one private key pair.
Instead of generating 1000 records for every single domain I am
serving, I generate 1000 CERT X509DIGEST records for the hosts and
1,000,000 CERT SIHLOK records for the domains.

So for example, there is a web server at customer.com. As is the
normal practice I want to have www.customer.com be an alias to
customer.com

www.customer.com   CNAME customer.com
customer.com    A 10.1.0.0
customer.com    CERT 0 0 SIHLOK SHA256 cert.hosting.com

_2982398ywef92ye2908y2938y.cert.hosting.com CERT
                               0 0 X509DIGEST 93822982398ywef92ye2908y2938y

This creates a really nice, clean separation along administrative
lines of responsibility that I know to exist. It is really easy to
drop in or remove either a new domain or  new host.

The design question I have not answered at this point is whether it is
possible/desirable to insist that the domains customer.com and
hosting.com be signed under the same DNSSEC keys.

If this restriction is made then it is clear that the pointer does not
have a material effect on the security model. Without the restriction
I have to write additional security considerations.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 9 Sep 2010 18:07:14 +0100

> better plan than messing about with extensions, but it could make

I don't think so. By the time you've done the scripting to generate a
new cert and restart the server (or reload the config), which is
necessarly going to be a local affair, you'd probably have been better
off to just have upgraded your server to the new version that does it
all for you (as a TLS extension).

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Sep 2010 13:22:09 -0400

> CNAMEs and prefixes to be finessed.

I'm fine with that design. (It's what I was alluding to with "Shit, I
have lots of keys. You'll should do another
lookup of <hash>.cert.example.com" :)

AGL

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Sep 2010 13:26:44 -0400

> all for you (as a TLS extension).

I agree that a TLS extension is cleaner from a design point of view.

However, an extension means waiting 10 years for IIS support.

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 13:33:56 -0400

If this was a functionality issue I would be very concerned. But this
is an optimization issue and so I am much less worried.

The IETF is not the right forum to drive compliance issues. But there
are other forums we can use.