Subject: [dane] Draft for serializing DNSSEC chains (01)

From: Adam Langley <[email-masked]>
Date: Fri, 1 Jul 2011 13:16:34 -0400

Addressing comments:

1) The details of the format have been pulled out from the
verification procedure and the similarities to the DNS wire format
have been highlighted.
2) A high level procedure for constructing the chains has been added.

http://tools.ietf.org/html/draft-agl-dane-serializechain-01

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 04 Jul 2011 10:12:33 +0200

Hi Adam,

> http://tools.ietf.org/html/draft-agl-dane-serializechain-01

It says: Filter the possible entry keys to
         only include those that have the SEP bit set in the flags.
But the RFCs say you MUST NOT distinguish based on the SEP bit. It is
for human consumption (and perhaps signer automation).  Skip this step
and remove this line.  Also at other points you check flags, again the
SEP flag is not required.  Only the ZSK flag, which allows a DNSKEY to
sign zone data (required for both KSK and ZSK keys, confusingly), is
something to check.

In case of algorithm rollover by the zones, you need to pick up one key
per algorithm to store.  Because some machines may support only one
algorithm.

A DNAME can simply be treated like you treat the CNAME redirect, but you
store the DNAME+RRSIG.  (the synthesized CNAME can be omitted since you
want to save bytes), then you synthesize the redirect with DNAME rules
(replace suffix labels).

Best regards,
   Wouter

---

From: Adam Langley <[email-masked]>
Date: Wed, 6 Jul 2011 10:53:42 -0400

On Mon, Jul 4, 2011 at 4:12 AM, W.C.A. Wijngaards <[email-masked]> wrote:
> for human consumption (and perhaps signer automation).

Thank you for the review. You're correct and I'll remove the SEP parts
in the next draft and probably replace them with wording about the ZSK
flag.

> per algorithm to store.  Because some machines may support only one

The idea that a single trust path is predetermined is important for
simplicity, which I greatly value. In order to keep the simplicity I'm
giving the algorithm rollover problem to another layer. Unlike serving
DNSSEC data using the DNS protocol, there's the possibility of
choosing a different serialization for different clients. Negotiation
of acceptable algorithms can thus be done by the higher layers.

> want to save bytes), then you synthesize the redirect with DNAME rules

Yes, I believe that DNAMEs would be simple to add but I've hesitated
so far because I've never seen a DNAME used in practice so have no
reality on which to write test code.

Cheers

AGL

---

From: Tony Finch <[email-masked]>
Date: Wed, 6 Jul 2011 16:10:47 +0100

> reality on which to write test code.

Have a look at the top half of the 232.128.in-addr.arpa zone. Sadly my
colleagues haven't rolled out DNSSEC to that zone or to the target of the
DNAMEs yet.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Cyclonic mainly west or northwest 6 to gale 8, decreasing 5 at times.
Rough or very rough, occasionally high at first in south. Rain or squally
showers. Good, occasionally poor.

---

From: Matt Larson <[email-masked]>
Date: Wed, 6 Jul 2011 18:20:32 -0400

On Wed, 06 Jul 2011, Adam Langley wrote:
> In order to keep the simplicity I'm giving the algorithm rollover
> problem to another layer.

This scares me.

> Unlike serving DNSSEC data using the DNS protocol, there's the
> possibility of choosing a different serialization for different
> clients.

This also scares me.

> Negotiation of acceptable algorithms can thus be done by the higher
> layers.

And this.

> so far

Aside from the fact that using X.509 as a transport for DNS resource
records is a grievous layer violation, statements such as above (no
DNAME support yet) show the complexity of forcing this square peg into
this round hole.  And taking into account Eric's legitimate concerns
about stale information and operational complexity, I'm concerned
about this protocol.

Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Jul 2011 18:58:33 -0400

> > problem to another layer.

Why, specify your fears.

We have to solve the algorithm rollover problem for SSL in any case.

> > possibility of choosing a different serialization for different

There is a really really bad history of people making arguments based on
fears or the state of their gut.

> > Negotiation of acceptable algorithms can thus be done by the higher

Why, do you understand how SSL negotiation works? It is pretty well
established at this point. People have been doing it for 15 years now.

> about stale information and operational complexity, I'm concerned

I don't see it as a layer violation. Its just another transport instead of
DNS query response.

It is a much simpler form of transport than messing with DNS queries, it
avoids the need for asynchronous response handling and is equivalent to
caching the DNS data.

If DNAME is the criteria, Adam is a lot closer to a solution than the
Hoffman draft is. I can modify Adam's proposal to support DNAME quite
simply. Making prefix records work with DNAME is a known incompatibility.

Arguments based on complexity sound rather hollow to me having spent the
past few weeks writing DNS resolution code.

The DNS chain is simply a PKI cert chain in a format other than ASN.1. I
find it hard to see how that is a 'layer violation'.

I didn't get this approach until last week either. But it all makes sense to
me and it is better for key distribution than my proposal was.

There is 16 years of history that has flowed under that particular bridge.
Any new mechanism for key distribution has to work at least as well in
practice as the existing scheme. Adam is the only person that has proposed
such a scheme. It does look like a bit of a hack, but it is probably the
least uggly solution that is going to work at least as well as the existing
scheme.

That still leaves security policy as an area where the 'get the info from
the DNS' approach is the only game in town. So it is not like embracing
Adam's scheme means that the need for DNSSEC aware resolvers goes away.

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 7 Jul 2011 02:59:58 +0200 (MEST)

> about stale information and operational complexity, I'm concerned

There a the reasonable concern that accessibility to DNSSEC records
might not be available to a non-marginal fraction TLS client for
quite a while (some middle boxes, such as home DSL routers or
other DNS proxies filtering them away).

In-band signalling of all relevant DNSSEC records within the TLS
protocol might be one possible solution to this.

While tunneling the information within X.509v3 extensions of the
server certificate would obviate changes to the server and
changes to the TLS protocol, it has the disadvantage that it
can not transport all DANE record types, needs frequent refreshing
of the server certificate and can not be used with X.509v1
self-signed server certs.

Personally, I think I would prefer an approach more like the
stapled OCSP responses TLS extension, where the server could
send the client all relevant DNSSEC records for verifying
the server certificate.

A server that constantly changes it certificate is fairly unusable
with a pre-DANE TLS client, because you can not preconfigure the trust
explicitly for the server's cert.  I really would like to see browser
memorizing server certs on first encounter and warn when the server
cert changes -- at least as an expert option.

-Martin

---

From: Matt Larson <[email-masked]>
Date: Thu, 7 Jul 2011 11:53:30 -0400

> > > problem to another layer.

The protocol, as I understand it, extracts a specific trust path to
embed in the cert, which may then supply algorithms to a client that
it can't understand.  Using standard DNS transport, the client gets
all records and can use what it needs and understands.

It sounds to me that rather than addressing the issue that supplying a
single trust chain may be problematic, this proposal kicks that can
down the road for someone else.  Well, who? 

> We have to solve the algorithm rollover problem for SSL in any case.

I think we're probably not understanding each other.  Are you
suggesting that some kind of negotiation would need to be added that
would allow the client to get a trust path it can understand?  If so,
that's yet more complexity that will cause operational issues, as Eric
has been pointing out.

If that's not it, then this issue (a single trust path that's possibly
not usuable by the client) is not solved.

Both of those choices (yet more complexity or an unsolved issue) are
troubling.

> fears or the state of their gut.

My objections here are the same as above: increased complexity that's
yet unspecified in this protocol.

> established at this point. People have been doing it for 15 years now.

Yes, I understand SSL negotiation.  I'm not suggesting negotiation is
impossible, but that it appears that as this protocol is being
investigated, more issues are getting uncovered.  Using an alternate
transport for DNS records that might require some negotiation for the
client to get the right trust path is undisputably more complicated
than a DNS lookup to retrieve the same information.

> I don't see it as a layer violation. Its just another transport instead of

We might have to disagree.

> avoids the need for asynchronous response handling and is equivalent to

It's only equivalent to caching DNS data if it has the exact same
properties as a DNS cache regarding expiry.  I don't believe this
protocol can do that without fantastic complexity.

> past few weeks writing DNS resolution code.

Code complexity is different than operational complexity, which is the
position Eric and I are arguing from.  I believe my background and
current responsibilities allow me to opine on operational complexity.

> least uggly solution that is going to work at least as well as the existing

I'm not arguing that, from an expediency standpoint based on deployed
code, it may well be easier to get DNSSEC information to a client
using an SSL cert as transport rather than a standard DNS lookup.
What I am suggesting is that it would be operationally very
complicated and introduce new caching semantics.  It is operationally
inevitable that trust paths will be frozen in SSL certs leading to
validation failures.  Using only the DNS infrastructure, there is no
place for data to become that stale.

> Adam's scheme means that the need for DNSSEC aware resolvers goes away.

You are presuming an objection I didn't make.

Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 12:48:06 -0400

> down the road for someone else.  Well, who?

The whole attraction of DNSSEC as a PKI is that it only allows assertions to
be made with respect to the namespace and the namespace is strictly
hierarchical.

Getting all the DNS records does not make life easier for the client in any
way. It kicks the client back to the problem of performing PKI paths and
path-math.

While there are circumstances in which the DNS hierarchy can become
ambiguous, those are essentially doomsday scenarios involving state level
conflicts. One of the attractions of this approach is precisely the fact
that it still continues to work in the case that the Shanghai Cooperation
Organization countries make good on their treaty commitments and decide to
set up their own DNS root and block external access to the ICANN root.

> that's yet more complexity that will cause operational issues, as Eric

No, the problem is that SSL currently has no viable strategy for upgrading
from use of SHA1 to a new algorithm whatsoever.

If we can't use SHA2 or SHA3 in the browser, the ability to use it in DNSSEC
is irrelevant.

Simply deploying SHA2 in new browsers and waiting for old ones to stop being
used is a naive approach to deployment that is certain to fail. Cert
customers measure the value of a certificate by the amount of customers and
business it helps generate, not the amount of risk it mitigates. In fact
they are entirely uninterested in the risk of the cert being hijacked during
transport as that is not a risk that they are likely to be held liable for
in any circumstance.

Under the existing upgrade proposal a site that deploys a SHA2 signed
certificate is guaranteed to loose some percentage of their business. At the
moment that would be around 40% due to the widespread use of Windows XP and
older. This problem is not necessarily improving. Mobile phones are becoming
more popular and many of them have very restricted PKI.

No business is going to sacrifice 40% of their business to upgrade to SHA2.
They wouldn't even do that if SHA1 was broken. No business is going to
sacrifice 5% or even 1%. Hence there is a requirement for a better solution.

The problem comes from the fact that the legacy protocol, the servers and
browsers are built around the assumption that there is one certificate per
site. The certificate is presented at the wrong stage in the SSL
negotiation.

There is thus an existing problem that the TLS world has to solve.

One approach that works very well is to put a flag in the cert to say 'you
can pull this OCSP response and get a SHA2 digest of me in it.

This would all have been avoided if OCSP had specified the certificate whose
status is being reported by means of a message digest of the cert as
originally proposed and not the CertID being the serial number of the cert
being reported on:

CertID ::= SEQUENCE {
    hashAlgorithm            AlgorithmIdentifier,
    issuerNameHash     OCTET STRING, -- Hash of Issuer's DN
    issuerKeyHash      OCTET STRING, -- Hash of Issuers public key
    serialNumber       CertificateSerialNumber }

I missed that change when the spec was converted into ASN.1.

It has two hashes and neither is the right one.

> Both of those choices (yet more complexity or an unsolved issue) are

You seem to use the term 'complexity' as meaning 'things I am not familiar
with'.

PKI is complex, browsers are even more complex. The proposal made by Adam
has no more complexity than the alternative and is considerably simpler to
administer and code.

> yet unspecified in this protocol.

There are empirical measures of complexity: The number of FSM states, the
number of places where consistency between data stored in different places
is required.

The proposal made by Adam involves fewer FSM states than the existing code
according to my analysis. The relying party has only one path to validate
and the data is presented in a fashion that permits the validation to be
performed by a simple for loop with a fixed number of state variables
carried from one iteration to the next. The complexity is thus O (n) The
existing DANE draft inescapably requires PKI path construction to be
performed which is a graph matching problem and is thus complex and has O(n
ln (n)) complexity at best, O (n^2) for a typical implementation.

It is thus less complex according to my objective criteria.

> investigated, more issues are getting uncovered.

None of the issues uncovered give me the slightest concern. SSL negotiation
is a tool that is designed to be used.

If someone is proposing a new way to do SSL that is not making use of the
SSL negotiation mechanism there is probably something wrong.

>  Using an alternate

No, it isn't.

What is indisputable is that O(n) is less than O(n ln (n)) and that a for
loop is much less complex than graph matching which is known to be worst
case np-complete.

> We might have to disagree.

I can't see how you can assert this as a layer violation without also
asserting that any inclusion of application PKI data in the DNS is a layer
violation.

> current responsibilities allow me to opine on operational complexity.

We may have to disagree.

The proposal made by Adam works in the existing DNS infrastructure without
assuming any further deployment.

The proposal you appear to be backing depends on clients being able to
access DNSSEC data. Support for that is well short of 100% and is highly
unlikely to ever reach a level that makes use of a security scheme that
depends on that access being practical.

>From an operational point of view I prefer the approach that is guaranteed
to work with my WiFi router than the one that is likely to force an upgrade.

> place for data to become that stale.

Does caching in the OCSP token work better for you?

The OCSP token is separate from the cert and validity can be limited to the
expiry of the RRSig expiring earliest.