Subject: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Mar 2017 17:20:39 -0700

SUBSTANTIVE

   Servers receiving a "dnssec_chain" extension in the client hello, and
   which are capable of being authenticated via DANE, SHOULD return a
   serialized authentication chain in the Certificate message, using the
   format described below.  The authentication chain will be an
   extension to the certificate_list to which the certificate being
   authenticated belongs.

In TLS 1.3, the extensions are attached to the certificates, so you
need to say which one. I assume end entity. You could also shove
this in EncryptedExtensions, one supposes.

EDITORIAL
You should replace "client hello" with ClientHello throughout.

-Ekr

---

From: Melinda Shore <[email-masked]>
Date: Tue, 21 Mar 2017 17:22:08 -0800

> You should replace "client hello" with ClientHello throughout.

Thanks, EKR.  I've updated the draft based on these comments and
will submit it once submissions reopen.

Melinda

---

From: Sean Turner <[email-masked]>
Date: Wed, 22 Mar 2017 10:37:40 -0400

> On Mar 21, 2017, at 21:22, Melinda Shore <[email-masked]> wrote:
> 

Minor nits from me too:

0) s1 (just once): r/server hello/ServerHello

1) s3.3: Is the or X.509 containers in the following supposed to be like otherwise known as X.509; it’s just that “PKIX” kind of jumped out at me:

is not limited to public
   keys encapsulated in PKIX or X.509 containers

2) s3.4: Should we refer to SNI Extensions as “server_name” extension to match the registered value?  You refer to this extensions as dnssec_chain in previous sections (just trying to be all matchy-matchy).

spt

---

From: Melinda Shore <[email-masked]>
Date: Wed, 22 Mar 2017 06:56:35 -0800

Thanks - I've updated those, as well.

Our sense right now is that the pieces that need completion
prior to going to working group last call are to add
some pseudocode to clarify construction of the chain, and
test vectors.  The draft could definitely benefit from
additional review.

Thanks,

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Mar 2017 11:15:07 -0400

> On Mar 22, 2017, at 10:56 AM, Melinda Shore <[email-masked]> wrote:
> 
> The draft could definitely benefit from
> additional review.

Quick comment:

   3.3.  Raw Public Keys

   [RFC7250] specifies the use of raw public keys for both server and
   client authentication in TLS 1.2.  It points out that in cases where
   raw public keys are being used, code for certificate path validation
   is not required.  However, DANE provides a mechanism for securely
   binding a raw public key to a named entity in the DNS, and when using
   DANE for authentication a raw key may be validated using a path
   chaining back to a DNSSEC trust root.  This has the added benefit of
   mitigating an unknown key share attack, as described in
   [I-D.barnes-dane-uks].

Binding raw public keys to a node in the DNS tree does not by itself
mitigate (or militate against) UKS attacks.  Indeed with just a raw
public key there are no names to check in any server certificate,
so when the application (web browsing) is vulnerable to UKS, raw
public create an exposure to such attacks.

However, the use of the "DNSSEC Authentication Chain Extension"
means that the server in fact cryptographically commits (because
the TLS handshake finished message commits both sides to the same
session transcript) to the DNS location (owner name) of its TLSA
records.  So it is not DANE (RFC6698, RFC7671) that protects RPK
against UKS, but rather this draft!

What "DNSSEC Authentication Chain Extension" does is effectively
augment RPK with the server's name that would otherwise be found
in the certificate, a reverse SNI if you like (but actually
stronger than names in certificates, because it also binds the
protocol and port).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Mar 2017 17:50:33 -0400

> The draft could definitely benefit from

I find it ironic that section 4 includes:

   The components of the authentication chain are built by starting at
   the target record set and its corresponding RRSIG.  Then traversing
   the DNS tree upwards towards the trust anchor zone (normally the DNS
   root), for each zone cut, the DNSKEY and DS RRsets and their
   signatures are added.  If DNS responses messages contain any domain
   names utilizing name compression [RFC1035], then they must be
   uncompressed.

while at the same time there is ongoing discussion of *adding* compression
of the server certificate chain (as a TLS 1.3 extension).  Would the
compression of server certificates also cover compression of the DNSSEC
chain extension?  If so, perhaps this would be a belated moral victory
for DJB[1]. :-)

-- 
-- 
	Viktor.

[1] https://cr.yp.to/djbdns/notes.html

Compression

Compression DNS packets use an ad-hoc compression method in which
portions of domain names can sometimes be replaced with two-byte
pointers to previous domain names. The precise rule is that a name
can be compressed if it is a response owner name, the name in NS
data, the name in CNAME data, the name in PTR data, the name in MX
data, or one of the names in SOA data.

One problem with DNS compression is the amount of code required to
parse it. Reliably locating all these names takes quite a bit of
work that would otherwise have been unnecessary for a DNS cache.
LZ77 compression would have been much easier to implement.

Another problem with DNS compression is the amount of code required
to correctly generate it. (RFC 1035 allowed servers to not bother
compressing their responses; however, caches have to implement
compression, so that address lists from some well-known sites don't
burst the seams of a DNS UDP packet.) Not only does the compressor
need to figure out which names can be compressed, but it also needs
to keep track of compression targets earlier in the packet. RFC
1035 doesn't make clear exactly what targets are allowed. (Most
versions of BIND do not use pointers except to compressible names;
suffixes of the query name are excluded. dnscache uses pointers to
suffixes of the query name.)

Another problem with DNS compression is that it's not particularly
effective. LZ77 would have done a noticeably better job on current
data, and a much better job on new record types that might become
popular in the future. (BIND versions 4.9.* through 8.1.2 compress
names in new record types, such as RP and SRV, in blatant violation
of RFC 1035. The names are not decompressed by caches that do not
know about the new types. This is an interoperability disaster.)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Mar 2017 08:58:53 +1100

The way that the UKS attack is mitigated here is counter-intuitive.
It is via inclusion of the *name* in the handshake transcript and
validation of that name that we get the protection we need.

Victor is right to question this.  This isn't a very obvious result
and needs more text than a single simple sentence.

On 23 March 2017 at 02:15, Viktor Dukhovni <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Mar 2017 01:28:16 -0400

> The draft could definitely benefit from additional review.

A more complete walk through:

> 2.  Introduction
> 
>    This draft describes a new TLS [RFC5246] extension for transport of a
>    DNS record set serialized with the DNSSEC signatures [RFC4034] needed
>    to authenticate that record set.  The intent of this proposal is to
>    allow TLS clients to perform DANE authentication [RFC6698] of a TLS

Should RFC6698 here be replaced or augmented with RFC7671?  In RFC7671,
the processing of DANE-EE(3) are DANE-TA(2) is modified from what one
might naively do with just RFC6698.  One of these changes of course
introduces the UKS problem referenced in this draft, but since this
draft militates against UKS attacks, that's not a problem.

>    server certificate without performing additional DNS record lookups
>    and incurring the associated latency penalty.  It also provides the
>    ability to avoid potential problems with TLS clients being unable to
>    look up DANE records because of an interfering or broken middlebox on
>    the path between the client and a DNS server.

FWIW, sometimes is the very DNS server the client learns via DHCP that
does not support DNSSEC, so no "middle-box" may be required to block
DNSSEC access.

>    And lastly, it allows
>    a TLS client to validate DANE records itself without necessarily
>    needing access to a validating DNS resolver to which it has a secure
>    connection.

[ It might be interesting at some point to implement a service in a
  local validating resolver to which the obtained DNS RRs can be
  forwarded for validation.  This way, all the application is doing
  is proxying DNS lookup via the TLS server to data that the local
  resolver may be prevented from obtaining directly, or would take
  too long to obtain.  This of course is not for the draft. ]

>    Furthermore,
>    SMTP MTAs usually employ Opportunistic Security [RFC7435], in which
>    the presence of the DNS TLSA records is used to determine whether to
>    enforce an authenticated TLS connection.  Hence DANE authentication
>    of SMTP MTAs [RFC7672] will typically not use this mechanism.

Note that RFC7672 describes opportunistic DANE TLS for SMTP, so RFC7435
should probably be replaced by RFC7672 here.

>    The client then authenticates the chain using a pre-configured trust
>    anchor.

Speaking of trust-anchors, the client will ultimately need to have some
mechanism to deal with root KSK rollover.  If the client has no local
resolver that is, at least intermittently, able to refresh the root KSK,
then the client may well also need to use this specification to update
the root KSK list from the DNSKEY RRsets returned by servers, and to
persist these for future use.  That's probably worth a mention...

>    As described in the DANE specification [RFC6698], this procuedure
>    applies to the DANE authentication of X.509 certificates.

Or raw public keys as described in 7671, and indeed mentioned below
in the draft.

> 3.1.  Protocol, TLS 1.2
> 
>    A client MAY include an extension of type "dnssec_chain" in the
>    (extended) ClientHello.  The "extension_data" field of this extension
>    MUST be empty.

One might ask the client to include the port number here, the server
may not know which port the client used if some load-balancer redirected
the layer-4 server address.

> 3.4.  DNSSEC Authentication Chain Data

>    Each RRset in the chain is composed of a sequence of wire format DNS
>    resource records.  The format of the resource record is described in
>    RFC 1035 [RFC1035], Section 3.2.1.  The resource records SHOULD be
>    presented in the canonical form and ordering as described in RFC 4034
>    [RFC4034].
> 
>              RR(i) = owner | type | class | TTL | RDATA length | RDATA

Note that the TTL in the canonical form is the one in the RRSIG, rather
that a typically smaller value in response from the resolver.  Whose
responsibility is it to ensure that the records fed into the signature
verification algorithm have the correct (maximal) TTL?

>    The first RRset in the chain MUST contain the DANE records being
>    presented.  The subsequent RRsets MUST be a sequence of DNSKEY and DS
>    RRsets, starting with a DNSKEY RRset.  Each RRset MUST authenticate
>    the preceding RRset:

Except that of course, as explained below, they don't have to be a
sequence of "DNSKEY" and "DS" RRsets, because wildcards also necessitate
NSEC, NSEC3 or possibly (some decade this century unless scalable QCs
arrive first) NSEC5 records.

>    o  A DNSKEY RRset must include the DNSKEY RR containing the public
>       key used to verify the previous RRset.

I assume that the DNSKEY RRset must be presented in full, because
otherwise how is its signature to be validated?  This even applies
to the root RRset in support of KSK rollover.  While it is possible
to limit the transmitted RRSIG records to just those supported by
the client, I don't see any opportunity to transmit partial RRsets
of any other type.

>    o  For a DS RRset, the set of key hashes MUST overlap with the
>       preceding set of DNSKEY records.

Again, except for the root (whose DS RRs need not be transmitted
at all), all the DS RRsets would surely need to be sent in full,
else their signature cannot be validated...

>    In addition, a DNSKEY RRset followed by a DS RRset MUST be self-
>    signed, in the sense that its RRSIG MUST verify under one of the keys
>    in the DNSKEY RRSET.

Are these instructions to the server (what to send) or to the verifier?
More specifically, the DNSKEY RRset must be accompanied by a signature
made by one of the KSKs whose hash appears in the DS RRset.  If there
are multiple algorithms in the DS RRset (say RSA and ECDSA) then if
at all possible an RRSIG by a KSK for each such algorithm MUST be
included unless the server knows which DNSSEC algorithms are supported
by the client and can safely omit RRSIGs for some of the algorithms.

>    The final DNSKEY RRset in the authentication chain, containing the
>    trust anchor may be omitted.

As mentioned below, that would make RFC5011 KSK rollover rather
difficult, and presumably we don't want clients to eventually cease to
be able to verify chains for lack of fresh trust anchors.

Indeed it is not just the root zone KSKs (trust anchors) that change
from time to time.  Rather, on a more frequent basis the root zone ZSKs
will roll over, and these are probably not part of any stable set of
trust-anchors maintained by the client.  For example, unbound's root
key file on my machine contains only the KSK:

   $ cat /usr/local/etc/unbound/root.key 
   ...
   .       172800  IN      DNSKEY  257 3 8 ...

So a fresh root zone DNSKEY RRset is going to be needed with some
frequency.  Right now the root zone has a single KSK and two ZSKs
and is signed by the KSK:

.                       DNSKEY  257 3 8 ( ... ) ; KSK; alg = RSASHA256 ; key id = 19036
.                       DNSKEY  256 3 8 ( ... ) ; ZSK; alg = RSASHA256 ; key id = 14796
.                       DNSKEY  256 3 8 ( ... ) ; ZSK; alg = RSASHA256 ; key id = 61045
.                       RRSIG   DNSKEY 8 0 172800 ( 20170411000000 20170321000000 19036 . ... )

While the SOA record and the rest of the root zone appears to be signed by
just the 61045 ZSK:

.                       SOA     a.root-servers.net. nstld.verisign-grs.com. (
                                2017032201 ; serial
                                1800       ; refresh (30 minutes)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
.                       RRSIG   SOA 8 0 86400 ( 20170404170000 20170322160000 61045 . ... )

One of the two ZSKs is presumably on its way out...

So it seems to me that the client extension needs to signal whether
the client is in need of a fresh root DNSKEY RRset.  Clients can omit
sending such a signal with most TLS connections and only ask periodically,
say once a day or so, perhaps from a few different servers just in case).

>    If omitted, the client MUST verify that
>    the key tag and owner name in the final RRSIG record correspond to a
>    trust anchor.  There may however be reason to include the trust
>    anchor RRset and signature if clients are expected to use RFC5011
>    compliant key rollover functions inband via the chain data.

But how is the server to know unless the client asks?  So I think
that perhaps the client extension needs to ask (RFC5011-enable flag
and port so far).

>    ...  Wildcard DANE records will need to include the wildcard
>    name, and negative proof (i.e.  NSEC or NSEC3 records) that no closer
>    name exists MUST be included.

And so the earlier text that says DS/DNSKEY only needs to be less
restrictive.

>    Note as well that if a user has a specific TLSA record for port 443,
>    and a different wildcard covering other ports, attackers MUST NOT be
>    able to substitute the wildcard TLSA RRset for the more specific one
>    for port 443.  DNSSEC wildcards must not be confused with the X.509
>    wildcards.

I don't understand this paragraph.  DNSSEC closest encloser proofs are
needed to show that the wildcard record is applicable.  The client knows
that the server is returning a wildcard response, which must prove that
the actual port sought has no explicit TLSA RR.  What am I missing?
Is this just asking the client to do DNSSEC wildcard answer processing
correctly?

> 4.  Construction of Serialized Authentication Chains
> 
>    This section describes a possible procedure for the server to use to
>    build the serialized DNSSEC chain.
> 
>    When the goal is to perform DANE authentication [RFC6698] of the
>    server's X.509 certificate, the DNS record set to be serialized is a
>    TLSA record set corresponding to the server's domain name.

Well, actually domain name *and* protocol *and* port.

>    The domain name of the server MUST be that included in the TLS Server
>    Name Indication extension [RFC6066] when present.  If the Server Name
>    Indication extension is not present, or if the server does not
>    recognize the provided name and wishes to proceed with the handshake
>    rather than to abort the connection, the server uses the domain name
>    associated with the server IP address to which the connection has
>    been established.

Or some suitable default name selected by the server.  I don't think it
is necessary to prescribe a selection mechanism.  The server may be
behind a load-balancer, and the name may be statically configured, rather
than obtained from the local address of the accepted socket.

>    The TLSA record to be queried is constructed by prepending the _port
>    and _transport labels to the domain name as described in [RFC6698],

That covers the label order, is it necessary to repeat it?

>    where "port" is the port number associated with the TLS server.  The
>    transport is "tcp" for TLS servers, and "udp" for DTLS servers.  The
>    port number label is the left-most label, followed by the transport,
>    followed by the base domain name.
> 

Of course there are additional complications when the original name
requires CNAME or DNAME processing to reach the ultimate target domain
where the TLSA records are stored.  Perhaps that's worth describing
in more detail, as that's the non-obvious part of the algorithm.

> 5.  Caching and Regeneration of the Authentication Chain
> 
>    DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
>    have validity periods (specifically signature expiration times).
>    After the TLS server constructs the serialized authentication chain,
>    it SHOULD cache and reuse it in multiple TLS connection handshakes.
>    However, it MUST refresh and rebuild the chain as TTLs and signature
>    validity periods dictate.  A server implementation could carefully
>    track these parameters and requery component records in the chain
>    correspondingly.  Alternatively, it could be configured to rebuild
>    the entire chain at some predefined periodic interval that does not
>    exceed the DNS TTLs or signature validity periods of the component
>    records in the chain.

Perhaps the job of transmitting "canonical" TTLs should also be up to
the server, in which case this section should explain that the server
must replace the TTLs of each record with the corresponding RRSIG max
TTL field.

> 6.  Verification
> 
>    A TLS client making use of this specification, and which receives a
>    DNSSEC authentication chain extension from a server, SHOULD use this
>    information to perform DANE authentication of the server certificate.
>    In order to do this, it uses the mechanism specified by the DNSSEC
>    protocol [RFC4035].  This mechanism is sometimes implemented in a
>    DNSSEC validation engine or library.
> 
>    If the authentication chain is correctly verified, the client then
>    performs DANE authentication of the server according to the DANE TLS
>    protocol [RFC6698], and the additional protocol requirements outlined
>    in [RFC7671].

Some discussion of UKS may be appropriate here, since there'll probably
be some day soon an update to RFC7671 that says that name checks are not
generally optional for DANE-EE(3), but as this protocol militates against
UKS attacks, the original policy of RFC7671 should stand despite any such
(near future) amendation.

> 7.  Trust Anchor Maintenance
> 
>    The trust anchor may change periodically, e.g. when the operator of
>    the trust anchor zone performs a DNSSEC key rollover.  Managed key
>    rollovers typically use a process that can be tracked by verifiers
>    allowing them to automatically update their trust anchors, as
>    described in [RFC5011].  TLS clients using this specification are
>    also expected to use such a mechanism to keep their trust anchors
>    updated.  Some operating systems may have a system-wide service to
>    maintain and keep the root trust anchor up to date.  In such cases,
>    the TLS client application could simply reference that as its trust
>    anchor, periodically checking whether it has changed.

Hence clients should signal servers whether they want the root DNSKEY
RRset, or already have a sufficiently fresh local copy.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 23 Mar 2017 07:53:34 -0800

Thanks for the thorough review, Viktor.  I'll get the straightforward
bits into the draft over the weekend and plan on discussing the ones
proposing changes to the extension or to chain construction and
processing in the working group session.

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Mar 2017 12:14:15 -0400

> On Mar 23, 2017, at 11:53 AM, Melinda Shore <[email-masked]> wrote:
> 

It seems to me that the TLS bits of the draft are close to done and
relatively simple to finish.  Perhaps at this point the reviews the
draft needs are more likely to be found in the DNSOP than the TLSWG.

Is there precedent for doing two working group last calls, one in
the TLS WG to confirm that the TLS bits are done, and then another
in DNSOP to go over the details of the DNS bits, and only then
proceed to IETF LC?

I don't know how many other folks on the TLS WG list are prepared
to do a thorough review the DNSSEC aspects of this draft...
Perhaps the TLS and DNS communities overlap sufficiently that my
concern is not warranted?

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 23 Mar 2017 08:31:24 -0800

> concern is not warranted?

I think it's quite warranted, and we're sending requests
for review to both the dane mailing list (still open even
though the wg shut down) and to dnsop.  The DNS parts are
more complicated than the actual extension mechanism and
need expert review.  We'll be requesting review once the
new version is posted.

Melinda

---

From: Sean Turner <[email-masked]>
Date: Thu, 23 Mar 2017 21:25:38 -0400

> On Mar 23, 2017, at 12:31, Melinda Shore <[email-masked]> wrote:
> 

We’re planning to cc: the DANE, DNSOPS, and DPRIVE WG during WGLC.  This obviously assumes we are there sometime shortly after Chicago.

spt

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Mar 2017 06:55:04 -0500

> draft militates against UKS attacks, that's not a problem.

Yes, I agree. We should add a reference to 7671.

> should probably be replaced by RFC7672 here.

Yes.

> persist these for future use.  That's probably worth a mention...

Yes, and it kind of is mentioned later in the document where there is a
discussion of whether or not to include the trust anchor DNSKEY RRset
in the chain or not. We need to sort out the requirement there.

> the layer-4 server address.

Hmm, I remember you brought up this point a while back, but I can't
remember
the subsequent discussion and what we decided to do about this. I suppose
it may be possible to preconfigure the servers on the other side of the
load
balancer to know the original port to avoid this problem.

> verification algorithm have the correct (maximal) TTL?

I would assume the validator on the TLS client side.

> arrive first) NSEC5 records.

Yes. The need to include NSEC/3 records for the wildcard DNS record case
is mentioned later in the draft, so this text needs to be reconciled with
it.

Also, on the issue of ordered vs unordered sequence of RRsets, the draft at
the moment appears to have contradictory text on this issues. Earlier in
section 3.4 it says:

  "The record sets and
   signatures are presented in the order returned by the DNS server
   queried by the TLS server, although they MAY be returned in
   validation order, starting at the target DANE record, followed by the
   DNSKEY and DS record sets for each intervening DNS zone up to a trust
   anchor chosen by the server, typically the DNS root. "

I know there are proponents of each. We need to decide which it is.

> the client, I don't see any opportunity to transmit partial RRsets

Yes.

> else their signature cannot be validated...

Yes, again.

> by the client and can safely omit RRSIGs for some of the algorithms.

We seem to be quoting generic DNSSEC protocol requirements here. I'd
be in favor of striking this sentence.

> be able to verify chains for lack of fresh trust anchors.

Right, we need to decide whether this protocol extension will support
in-band RFC 5011 key rollover capability or not. If so, the chain will
have to include the trust anchor DNSKEY RRset (or I suppose its
inclusion could be negotiated by client signaling).

One could make the case, that key rollover is best handled by a system
wide service that the TLS client uses (mentioned in the draft). However,
there may again be potential middlebox interference problem here that
could prevent such a service from working reliably (e.g. if the middlebox
prevents the delivery of DNSKEY queries and signed responses).

Another way this problem could be addressed is by regular client software
updates - browsers I believe are comfortable with this mode. The DNS root
key rollover happens (or is at least planned to happen) on a time scale that
is much larger than typical client software updates.

The protocol described here is general purpose though. It could be used
with a custom trust anchor for a different point in the DNS tree where
key rollover schedules are more unpredictable.

> that perhaps the client extension needs to ask (RFC5011-enable flag

The client asks for it, or the server sends it unilaterally, or we decide
that
client TA rollover is handled outside the protocol.

> And so the earlier text that says DS/DNSKEY only needs to be less

Yes (discussed previously).

> Is this just asking the client to do DNSSEC wildcard answer processing

It sounds like it. I would strike this paragraph.

> Well, actually domain name *and* protocol *and* port.

Yes.

> than obtained from the local address of the accepted socket.

Personally, I'm in favor of mandating TLS SNI usage with this extension.
But I lost that argument with other folks, so I defer to consensus.

> in more detail, as that's the non-obvious part of the algorithm.

We need to sort out the ordered vs unordered issue first. We can then
elaborate on CNAME/DNAME processing.

> must replace the TTLs of each record with the corresponding RRSIG max

I would be okay with that, but it doesn't have to be that way. Validating
resolver logic placed in the client can just as easily figure out the
canonical
TTL before signature verification.

> (near future) amendation.

Yes, I agree.

> RRset, or already have a sufficiently fresh local copy.

[See previous discussion]

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Mar 2017 07:00:17 -0500

> chain extension?  If so, perhaps this would be a belated moral victory

I think the reason for the last sentence quoted above is that DNS name
compression is defined in terms of an offset from the beginning of the
DNS message, and the draft as currently written uses a sequence of RRsets
rather than a complete DNS message. I sympathesize with djb's critique.
If DNS wasn't designed in the early 80's then perhaps we would have had
something different.

I supposed we could redefine name compression for this draft to use an
offset from the beginning of the chain data.

Does the proposed compression of certificate chains include extensions
in the Certificate message also? If so, the DNSSEC chain extension would
automatically be covered. Generally speaking, I would not be opposed to
compressing the DNSSEC chain extension with a normal compression algorithm.
Perhaps some empirical measurements might be useful to determine
whether it yields significant enough savings. Large parts of the dnssec
chain (signatures and keys) probably aren't terribly compressible, although
I guess the same issue exists for certificate chains, and if it's worth it
for
the latter ..

-- 
Shumon Huque