Subject: [dane] Draft for serializing DNSSEC chains

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jun 2011 14:22:42 -0400

As promised. (This is also the format that Chrome is using for it's
DNSSEC stapled certificate support.)

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

Cheers

AGL

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 28 Jun 2011 15:17:02 -0400

Excellent, this matches what I backed out of your example :)

Couple of quick comments:

- Summary: I think it would be clearer to structure the draft as:
  1. Data structure
  2. How to construct the chain starting from a DNS name
  3. How to verify the chain

- It would be helpful to have a description of the data structure in "at rest" form, as opposed to in "parsing stream" form, in order to separate structure from parsing logic. 

- Because the description of verifier behavior is so focused on parsing, the cryptographic verification steps kind of get lost.  It took me a couple of seconds to find the requirement for matching DS and DNSKEY.

- The document doesn't say anything about how to construct a chain starting from a DNS name.  Given that chain.py is 471 lines, this doesn't seem like a trivial process!

- Considering the differences from normal certs, e.g., in naming practices, it might actually be helpful to have a separate certificate profile for DNSSEC-stapled certificates, and to signal it with something like a CP OID (as for EV).  That wouldn't rule out the use of this extension with other types of certs, but it would provide a simple flag that a stapled cert is different from some other self-signed cert.   

Thanks for writing a spec, I think this could be a useful complement to the DANE RR type.
--Richard

On Jun 28, 2011, at 2:22 PM, Adam Langley wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Jun 2011 20:25:23 +0100

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

Why not DNS wire format? i.e. concatenate the usual encoding of
(1) the trust anchor DNSKEY + RRSIG DNSKEY RRs;
(2) for each intermediate zone cut,
(2a) the delegation DS + RRSIG DS RRs;
(2b) the apex DNSKEY + RRSIG DNSKEY RRs;
(3) the final RR set + RRSIG.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northerly or northwesterly 5 to 7, perhaps gale 8 later in
Trafalgar and Fitzroy. Moderate or rough. Showers. Moderate or good.

---

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jun 2011 15:29:44 -0400

> (3) the final RR set + RRSIG.

It basically is that. The reason for deviating from that exactly are
that I want to keep the chain as small as possible by omitting parts
of it where possible.

Cheers

AGL

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Jun 2011 20:44:14 +0100

Adam Langley <[email-masked]> wrote:
> > Why not DNS wire format?

How much space do you save in practice?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: Mainly west or northwest 4 or 5, increasing 6 at times. Slight
or moderate. Thundery showers then fair. Moderate or poor becoming good.

---

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jun 2011 15:54:48 -0400

> How much space do you save in practice?

Well, for a simple case we save the root key (256 bytes), 3 DS records
(two from . to org and from from org to imperialviolet.org, 148 bytes)
and a DSSIG (128 bytes).

The resulting chain would have been 2820 bytes and it's now only 2288
bytes, so ~15%.

Cheers

AGL

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Jun 2011 21:01:06 +0100

> The resulting chain would have been 2820 bytes and it's now only 2288

You can use the same logic to omit the same records from a wire format
version of the trust chain so I don't think the saving is that big.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: West or southwest 4 or 5. Moderate. Showers.
Good.

---

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jun 2011 16:06:10 -0400

> version of the trust chain so I don't think the saving is that big.

Which is pretty much what it is.

Cheers

AGL

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Jun 2011 21:11:56 +0100

> Which is pretty much what it is.

Well no. The point of using exactly the standard wire format is so that
you can re-use existing serializing and parsing code.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes: Variable mainly southwest 3 or 4, occasionally 5 at first.
Slight or moderate. Showers. Moderate or good.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 28 Jun 2011 16:15:12 -0400

I'm guessing that part of the reason that Adam didn't use the wire formats in the first place is that your average DNS library doesn't give you access to raw RDATA, so you basically have to re-serialize it.  In particular, Adam's generation tool uses "dig" to get DNS info, which indeed does not provide raw wire-format bytes.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Jun 2011 16:46:36 -0400

I think it would also be good to try to get ordering in there so that the
complexity of verification can be minimized.

A lot of the complexity of PKIX path math and DNSSEC validation comes from
the fact that the information received can come in any order, can be
incomplete and can be redundant.

Oddly enough, even though X.509 requires the use of the totally pointless
DER encoding which is a PITA to implement, pretty much every PKI application
allows cert chains to be presented in any order the provider chooses.

PKIX trust paths can have multiple roots, cross certs etc. so it would be
hard to do. But DNSSEC has a single root so it would be good if the spec
said to traverse in one way or the other.

On Tue, Jun 28, 2011 at 4:15 PM, Richard L. Barnes <[email-masked]> wrote:

> I'm guessing that part of the reason that Adam didn't use the wire formats
> in the first place is that your average DNS library doesn't give you access
> to raw RDATA, so you basically have to re-serialize it.  In particular,
> Adam's generation tool uses "dig" to get DNS info, which indeed does not
> provide raw wire-format bytes.
>
> --Richard
>
>
>

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

---

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jun 2011 17:23:25 -0400

> said to traverse in one way or the other.

The draft, as is, requires that the serialization start at the initial
zone (probably the root) and that each step match more labels
(counting right to left) of the target name. I believe that only
permits a single order.

Additionally, the embedded RRDATAs must be in DNSSEC canonical ordering.

Cheers

AGL

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jun 2011 12:26:48 +1000

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> I'm guessing that part of the reason that Adam didn't use the wire formats in
> the first place is that your average DNS library doesn't give you access to 
> raw RDATA, so you basically have to re-serialize it.  In particular, Adam's g
> eneration tool uses "dig" to get DNS info, which indeed does not provide raw 
> wire-format bytes.
> 
> --Richard

Actually your average DNS library MUST give you access to the raw
forms to support unknown RR types.

"dig" is not a library.  It is a diagnotic tool and it will printout
unknown records.  It just doesn't have a flag to print them all out
as unknown.

Mark

; <<>> DiG 8.3 <<>> ns . +dnssec 
;; res options: init recurs defnam dnsrch no-tld-query dnssec edns0
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34629
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 3
;; QUERY SECTION:
;;	., type = NS, class = IN

;; ANSWER SECTION:
.			4d6h2m39s IN NS  k.root-servers.net.
.			4d6h2m39s IN NS  g.root-servers.net.
.			4d6h2m39s IN NS  d.root-servers.net.
.			4d6h2m39s IN NS  l.root-servers.net.
.			4d6h2m39s IN NS  b.root-servers.net.
.			4d6h2m39s IN NS  a.root-servers.net.
.			4d6h2m39s IN NS  c.root-servers.net.
.			4d6h2m39s IN NS  h.root-servers.net.
.			4d6h2m39s IN NS  m.root-servers.net.
.			4d6h2m39s IN NS  e.root-servers.net.
.			4d6h2m39s IN NS  i.root-servers.net.
.			4d6h2m39s IN NS  j.root-servers.net.
.			4d6h2m39s IN NS  f.root-servers.net.
.			5d21h35m46s IN TYPE46  \# 147 (	; unknown RR type
	00 02 08 00 00 07 e9 00 4e 12 54 00 4e 09 0b 70 ; ........N.T.N..p
	86 dd 00 7e 43 b6 6e 18 f5 48 e7 a5 20 12 09 96 ; ...~C.n..H.. ...
	24 73 36 35 25 1d 95 12 fd 4b 42 e8 6f 17 fb aa ; $s65%....KB.o...
	5e 09 74 87 52 46 e1 fb cf 98 bc 57 c9 07 71 70 ; ^.t.RF.....W..qp
	e5 cb 5d 69 26 22 a4 99 2f bc 81 90 a1 0d 4e 14 ; ..]i&"../.....N.
	a0 7c b2 c9 71 a2 08 01 69 eb c1 1e 14 e7 85 a4 ; .|..q...i.......
	57 c7 5e 52 95 b3 03 9f e5 34 f6 b5 cf 31 03 d3 ; W.^R.....4...1..
	ff 94 c1 4d 0b d1 a7 ee e8 0a 05 8b ba e0 fc 1f ; ...M............
	94 c9 ff d9 11 1f cf cd 0d bb 72 03 c9 5f 9a 46 ; ..........r.._.F
	3c da f8 )					; <..

;; ADDITIONAL SECTION:
f.root-servers.net.	3d5h30m44s IN A  192.5.5.241
f.root-servers.net.	3d5h30m44s IN AAAA  2001:500:2f::f
; EDNS: version: 0, udp=4096, flags=8000

;; Total query time: 14 msec
;; FROM: bsdi.dv.isc.org to SERVER: 127.0.0.1
;; WHEN: Wed Jun 29 12:24:14 2011
;; MSG SIZE  sent: 28  rcvd: 441

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Jun 2011 23:55:07 -0400

> forms to support unknown RR types.

You are rather lucky if your average DNS library supports SRV records, let
alone the unknown records.

This is being fixed, but the state of the application world is much worse
than most imagine.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jun 2011 14:34:19 +1000

In message <BANLkTi=[email-masked]>, Phillip Hallam-
Baker writes:
> --0016369fa25217fc1204a6d1c0ec
> Content-Type: text/plain; charset=ISO-8859-1
> 
 
	You average resolver library can look up all types.  It may
	not be able to break them down in type specific ways but
	it can return a answer from which the application can extract
	the desired records.

	To look up a submission SRV records one would do the following
	in the 1982 version of libresolv.

	unsigned char buf[65535];
	int n;

	n = res_query("_submission._tcp.example.net", C_IN, 33, buf,
		      sizeof(buf));

	You then need to parse buf to extract the SRV record but
	that is all well defined.

	Which is almost identical to how you would query for it with a modern
	version of libresolv.
	
	unsigned char buf[65535];
	int n;

	n = res_query("_submission._tcp.example.net", ns_c_in, ns_t_srv, buf,
		      sizeof(buf));
	
	One can do similar with most other resolver libraries.  Some
	will give you the entire DNS response.  Others will extract
	the records for you and present them as opaque blobs.

	The DNS message format was designed to allow unknown records
	types to be queried for and returned without the intermedite
	nameservers and libraries knowing anything about the type.

	RFC 1034 and RFC 1035 supported the passing of unknown record
	types.  They just didn't have a master file format for them.

	Mark

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jun 2011 01:50:53 -0400

I guess that would work for the application programmers who still code in C
or C++. That is not where the industry has been for a decade now.

On Wed, Jun 29, 2011 at 12:34 AM, Mark Andrews <[email-masked]> wrote:

> > > > the first place is that your average DNS library doesn't give you
> access
> > > to
> > > > eneration tool uses "dig" to get DNS info, which indeed does not
> provide
> > > raw
> > > > wire-format bytes.
> > > >
> > > > --Richard
> > >

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jun 2011 16:21:21 +1000

In message <[email-masked]>, Phillip Hallam-
> or C++. That is not where the industry has been for a decade now.

The concepts are language independent.

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Jun 2011 10:47:01 +0100

Richard L. Barnes <[email-masked]> wrote:

> I'm guessing that part of the reason that Adam didn't use the wire
> formats in the first place is that your average DNS library doesn't give
> you access to raw RDATA, so you basically have to re-serialize it.

The standard Unix resolver library gives you the necessary tools to handle
wire format DNS data. If you want something higher-level, use ldns. It
looks like just the thing for this task.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest FitzRoy, Sole: Northwesterly 4 or 5, becoming variable 3 or 4.
Moderate. Fair. Good.

---

From: Adam Langley <[email-masked]>
Date: Wed, 29 Jun 2011 07:21:52 -0400

On Wed, Jun 29, 2011 at 2:19 AM, Rickard Bellgrim <[email-masked]> wrote:
> Isn't the initial_key_tag a little bit weak as a trust anchor? You could easily get a collision here. Perhaps using the DS as initial_ds instead of initial_key_tag?

It's only used in the same way as in DNSSEC: an optimisation. If you
have multiple keys with the same key tag then you have to try all of
them.

Cheers

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jun 2011 11:36:18 -0400

The concepts are independent, the code most certainly is not.

This is why I have spent the past few weeks writing a DNS resolver in C# to
hopefully render the issue moot.

While you can call unmanaged code from a managed environment like C#, the
means of doing so is not at all pretty. And making the result threadsafe is
a nightmare. It is in fact much easier to recode from scratch than to use
the existing stuff.

Calling a math function or a crypto algorithm is one thing, but a DNS
library is by its very nature asynchronous and it is possible to have
multiple queries in flight at the same time. I suspect that a lot of the
objections to using DNS for more sophisticated discovery come from the lack
of decent DNS library support in modern programming languages.

It is easy enough to support an API like this with blocking code:

    EDNS.Client resolver = new EDNS.Client ();

    EDNS.DNSMessage Response;
    int result = resolver.Resolve (Domain, EDNS.DNSType.CAA, out Response);

But most of us would like to have multiple queries in parallel:

            DNSClient Client = new DNSClient ();

            // Non blocking request
            DNSMessage Request = new DNSQueryMessage (Domain, EDNS.DNSType.A
);
            DNSTransaction Transaction1 = Client.Send (Request);

            DNSMessage Request = new DNSQueryMessage
(Domain, EDNS.DNSType.CAA);
            DNSTransaction Transaction2 = Client.Send (Request);

            // Does other useful stuff like create the message headers
            // Can poll status of transactions using DNSTransaction.Complete
()

            Response = Client.Receive (Transaction1);
            Response = Client.Receive (Transaction2);

And that is still much less than you would want a .NET library to provide. A
proper .NET library should let the caller loop things into the asynchronous
caller.

Ultimately, the goal is to produce a subclass of the TcpClient class such
that the only difference that the programmer needs to consider is to replace
the creation method:

public TcpClient(string hostname, int port)

with the creation method:

public InternetClient(string hostname, string service, int port)

The difference here is the level of abstraction. TcpClient connects via
hostname and port and always returns a raw bytestream. InternetClient uses
the DNS to determine what the best connection that is available for a
service. If the best connection is raw TCP it will return that, if it can
form an SSL socket, it will return that.

[Yes, I know that there is also the question of how to specify 'best', but
that is something that is more usually something you want to specify at the
host level or higher and want to avoid embedding in actual applications]

This actually has a major performance advantage in the right hands because
the implementation can also be asynchronous. So in the typical calling
sequence we would have:

// Create the socket
// Generate the message headers
// Check the socket is OK
// Send the first byte

In terms of timing what would be going on is:

// Create the socket
  [Async socket establishment starts]
// Generate the message headers
  [Wait for the socket to be completed]
// Check the socket is OK
// Send the first byte

Now in my preferred programming language, you could just throw up a PAR
statement and it would work anyway, but very few programmers grok that sort
of stuff.

---

From: Rickard Bellgrim <[email-masked]>
Date: Wed, 29 Jun 2011 08:19:05 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam Langley
> Sent: den 28 juni 2011 20:23
> To: [email-masked]
> Subject: [dane] Draft for serializing DNSSEC chains
> 
> As promised. (This is also the format that Chrome is using for it's DNSSEC
> stapled certificate support.)
> 

// Rickard

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jun 2011 09:54:15 +1000

In message <[email-masked]>, Phillip Hallam-
> a nightmare. It is in fact much easier to recode from scratch than to use

There are already plenty of thread safe resolver libraries.  Which
can perform queries in parallel.  They can even be talking to
different sets of recursive servers if you want.  libresolv was
made thread safe in 1900's and no it was not a giant lock.

> statement and it would work anyway, but very few programmers grok that sort

And this has gone very far from the original issue of handling unknown types.

> --0016e68debd4b5f20c04a6db8b0b
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> The concepts are independent, the code most certainly is not.<div><br></div=
> ><div>This is why I have spent the past few weeks writing a DNS resolver in=
>  C# to hopefully render the issue moot.</div><div><br></div><div><br></div>
> <div>While you can call unmanaged code from a managed environment like C#, =
> the means of doing so is not at all pretty. And making the result threadsaf=
> e is a nightmare. It is in fact much easier to recode from scratch than to =
> use the existing stuff.</div>
> <div><br></div><div>Calling a math function or a crypto algorithm is one th=
> ing, but a DNS library is by its very nature asynchronous and it is possibl=
> e to have multiple queries in flight at the same time. I suspect that a lot=
>  of the objections to using DNS for more sophisticated discovery come from =
> the lack of decent DNS library support in modern programming languages.</di=
> v>
> <div><br></div><div><br></div><div>It is easy enough to support an API like=
>  this with blocking code:</div><div><br></div><div><div>=A0 =A0 EDNS.Client=
>  resolver =3D new EDNS.Client ();</div><div><br></div><div>=A0 =A0 EDNS.DNS=
> Message Response;</div>
> <div>=A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, out=
>  Response);</div><div><br></div></div><div><br></div><div>But most of us wo=
> uld like to have multiple queries in parallel:</div><div><br></div><div><di=
> v>
> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient ();</div></div><=
> div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request</div><di=
> v><div><span class=3D"Apple-style-span">=A0 =A0 =A0 =A0 =A0 =A0 DNSMessage =
> Request =3D new DNSQueryMessage (Domain,=A0</span>EDNS.DNSType.A<span class=
> =3D"Apple-style-span">);</span></div>
> </div><div>=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Client.S=
> end (Request);</div><div><br></div><div><div><div>=A0 =A0 =A0 =A0 =A0 =A0 D=
> NSMessage Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.CAA);</di=
> v></div><div>=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Client=
> .Send (Request);</div>
> </div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuf=
> f like create the message headers</div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Can =
> poll status of transactions using=A0DNSTransaction.Complete ()</div><div><b=
> r></div><div><div>=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Tran=
> saction1);</div>
> </div><div><div>=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transa=
> ction2);</div></div><div><br></div><div><br></div><div>And that is still mu=
> ch less than you would want a .NET library to provide. A proper .NET librar=
> y should let the caller loop things into the asynchronous caller.</div>
> <div><br></div><div>Ultimately, the goal is to produce a subclass of the Tc=
> pClient class such that the only difference that the programmer needs to co=
> nsider is to replace the creation method:</div><div><br></div><div><span cl=
> ass=3D"Apple-style-span" style=3D"font-family: &#39;Segoe UI&#39;, Verdana,=
>  Arial; font-size: 17px; "><pre style=3D"padding-top: 5px; padding-right: 5=
> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px; margin-right: =
> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas, Courier, =
> monospace; word-break: break-all; word-wrap: break-word; font-style: normal=
> ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
> <span style=3D"color: blue; ">public</span> TcpClient(<span style=3D"color:=
>  blue; ">string</span> hostname, <span style=3D"color: blue; ">int</span> p=
> ort)</pre></span></div><div><br></div><div>with the creation method:</div><=
> div>
> <br></div><div><span class=3D"Apple-style-span" style=3D"font-family: &#39;=
> Segoe UI&#39;, Verdana, Arial; font-size: 17px; "><pre style=3D"padding-top=
> : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; margin-t=
> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font-fami=
> ly: Consolas, Courier, monospace; word-break: break-all; word-wrap: break-w=
> ord; font-style: normal; font-weight: normal; overflow-x: auto; overflow-y:=
>  auto; ">
> <span style=3D"color: blue; ">public</span> InternetClient(<span style=3D"c=
> olor: blue; ">string</span> hostname, <span style=3D"color: blue; ">string<=
> /span> service, int port)</pre></span></div><div><br></div><div><br></div><=
> div>
> The difference here is the level of abstraction. TcpClient connects via hos=
> tname and port and always returns a raw bytestream. InternetClient uses the=
>  DNS to determine what the best connection that is available for a service.=
>  If the best connection is raw TCP it will return that, if it can form an S=
> SL socket, it will return that.</div>
> <div><br></div><div>[Yes, I know that there is also the question of how to =
> specify &#39;best&#39;, but that is something that is more usually somethin=
> g you want to specify at the host level or higher and want to avoid embeddi=
> ng in actual applications]</div>
> <div><br></div><div>This actually has a major performance advantage in the =
> right hands because the implementation can also be asynchronous. So in the =
> typical calling sequence we would have:</div><div><br></div><div>// Create =
> the socket</div>
> <div>// Generate the message headers</div><div>// Check the socket is OK</d=
> iv><div>// Send the first byte</div><div><br></div><div>In terms of timing =
> what would be going on is:</div><div><br></div><div><div>// Create the sock=
> et</div>
> <div>=A0 [Async socket establishment starts]</div><div>// Generate the mess=
> age headers</div><div>=A0 [Wait for the socket to be completed]</div><div>/=
> / Check the socket is OK</div><div>// Send the first byte</div></div><div><=
> br>
> </div><div><br></div><div>Now in my preferred programming language, you cou=
> ld just throw up a PAR statement and it would work anyway, but very few pro=
> grammers grok that sort of stuff.</div><div><br></div><div><br><div class=
> =3D"gmail_quote">
> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <span dir=3D"ltr">&lt;<a href=
> =3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquot=
> e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
> id;padding-left:1ex;">
> <br>
> In message &lt;<a href=3D"mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail=
> .gmail.com">[email-masked]</a>&gt;, Phi=
> llip Hallam-<br>
> <div class=3D"im">Baker writes:<br>
> &gt; I guess that would work for the application programmers who still code=
>  in C<br>
> &gt; or C++. That is not where the industry has been for a decade now.<br>
> <br>
> </div>The concepts are language independent.<br>
> <font color=3D"#888888"><br>
> --<br>
> </font><div><div></div><div class=3D"h5">Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: <a href=3D"mailto:=
> [email-masked]">[email-masked]</a><br>
> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
>  href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
> </div>
> 
> --0016e68debd4b5f20c04a6db8b0b--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jun 2011 21:01:07 -0400

Yes, but you try calling them from managed code and the results are going to
be less than pretty.

All I am saying is that there is probably a reason that very few
applications seem to be making use of features like SRV and I don't think it
is a problem with the ideas, its in the deployment.

On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews <[email-masked]> wrote:

> > > In message <[email-masked]>,
> Phillip
> > > Hallam-
> > > Baker writes:
> > > > I guess that would work for the application programmers who still
> code in
> > > C
> >  C# to hopefully render the issue
> moot.</div><div><br></div><div><br></div>
> > /span> service, int
> port)</pre></span></div><div><br></div><div><br></div><=
> > div>
> hos=
> > In message &lt;<a href=3D"mailto:
> BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail=

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 10:51:45 -0400

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

I think I may be missing something here, so can someone clarify the
following for me: what happens if someone encodes the chain of trust in one
of these certs, and then the zones in that chain change their keys
(rollovers, revocations, etc.)?  Isn't encoding a dynamic chain of trust in
a static cert a requirements mismatch?

Eric

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jun 2011 11:31:09 -0400

> a static cert a requirements mismatch?

I don't understand the problem here. The RSIG values have an absolute
validity interval (i.e. not relative)

This is a pickled RSIG chain from a specific point in time. It says nothing
about the validity of the chain at any other point in time.

Unless there is a major flaw in DNSSEC, I can't see where there would be an
issue here.
-- 
Website: http://hallambaker.com/

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 11:41:47 -0400

On 6/30/11 11:31 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:

> 
> 
> On Thu, Jun 30, 2011 at 10:51 AM, Osterweil, Eric <[email-masked]>
> wrote:
>> 
>> 
>> 
> I don't understand the problem here. The RSIG values have an absolute validity
> interval (i.e. not relative)
> 

Well if you get a cert, and it says, "I'm valid because the following DNSSE
chain is valid," then you are either using THAT chain instead of the current
chain of trust (in which case I ask why), or something else that I don't
understand.  Why are you using a representation of the delegation tree that
may not be current anymore?

Further, are these certs going to be reissued reliably as the root key
changes?  I see in the draft that this is (obviously) predicated on trusting
a root key, but this value will change (albeit slowly).  So, I guess you
have to re-encode your cert when the root key rolls?

Eric

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Jun 2011 17:09:42 +0100

Osterweil, Eric <[email-masked]> wrote:
> understand.

It is to avoid the latency of extra DNSSEC lookups by the client.

> changes?

Root key rollovers are irrelevant (and in practice impossible) since the
RRSIG records will expire much much more frequently.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Northwest 5 to 7, perhaps gale 8 later. Moderate or rough. Showers.
Good.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 13:18:53 -0400

> It is to avoid the latency of extra DNSSEC lookups by the client.

So, you're proposing an architecture that splits data from its authoritative
sources (DNS zones), and freezes it in a cert whose semantics have no
relationship to DNS, rather than incur a handful of DNS lookups to be sure
the trust is intact?  This is very much more likely to cause problems than
save any.  Keys change for various reasons (including compromises), and
having frozen keys in external stores that have no coupling to the
authoritative sources is a dangerous slippery slope.

> RRSIG records will expire much much more frequently.

They are neither irrelevant nor (theoretically) impossible.  Without more
work they are operationally troubling, but that doesn't mean that one could
never do one.  However, the act of engaging in one (as per
https://www.iana.org/dnssec/icann-dps.txt ) could _become_ impossible if (in
addition to other complexities) we now create external dependencies that
have no feeback to DNS.  If there is (for example) a compromise, that key
needs to be rolled over (or an algo rollover), the machinery exists now to
do so (though testing needs more time).  However, with this approach, there
is no theoretical way to roll without orphaning SSL certs.  This approach
adds an architectural limitation that does not exist now.  Right now we have
operational concerns and the need to enhance mechanisms, not a non-start
situation.

Eric

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 30 Jun 2011 14:16:17 -0400

You keep using words like "freeze" to describe the inclusion of information in a cert.  Not all certs have long lifetimes!  In particular, this system can work with self-signed certs, which a site can issue for itself as often as needed -- including whenever a TTL or validity period expires in the DNSSEC change.

You could think of this as a way of shifting load/latency from the client/online to server/offline -- from fetching/validating DNSSEC records at service time to periodically re-constructing and re-signing a certificate.  

--Richard

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 14:24:02 -0400

Indeed, I know that they _can_ change.  However, they may not (because
people may not realize that them must).  I think this is an important
operational distinction.  If someone simply doesn't change their cert
(perhaps they don't understand the implications of failing to do so), then
we get into trouble.  As an analogy, DNSSEC shouldn't be nearly as
operationally difficult as it is.  If everyone just knew how to use it and
promised to follow best practices... Right? ;)  Managing the crypto in just
one system is hard enough, this seems to inheret baggage from two
crypto-enhanced systems...  :-/

But seriously, what worries me is that people will create certs this way
(using what I'm sure will turn out to be very easy tools), and then just not
regenerate them (if it ain't broke, don't fix it).  These will become
serious problems because large DNSSEC registries simply cannot be
responsible for blacking out a large deployment cross-section if these certs
will suddenly fail to validate.

I chose the term "freeze" because of the relative disconnection between the
cert management process that is trying to reflect the status of the DNS, and
the operational lifecycle of DNS zones.  Is there a better word?  Perhaps
the wording is confusing the issue here?

Eric  

On 6/30/11 2:16 PM, "Richard L. Barnes" <[email-masked]> wrote:

> You keep using words like "freeze" to describe the inclusion of information in
> a cert.  Not all certs have long lifetimes!  In particular, this system can
> work with self-signed certs, which a site can issue for itself as often as
> needed -- including whenever a TTL or validity period expires in the DNSSEC
> change.
> 
> You could think of this as a way of shifting load/latency from the
> client/online to server/offline -- from fetching/validating DNSSEC records at
> service time to periodically re-constructing and re-signing a certificate.
> 
> --Richard
> 
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Jun 2011 20:42:39 +0200 (MEST)

> authoritative sources is a dangerous slippery slope.

I believe the RRSIG validitiy is more in the matter of hours to days.

And for DNSSEC to work smoothly, there are transistion periods for
DNS key rollover, so that when correctly rebuilding the to-be-signed
data from currently valid data (rather than blindly resigning old
data when RRSIG expires), the problem you are describing might not
exist.

-Martin

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 14:49:05 -0400

> I believe the RRSIG validitiy is more in the matter of hours to days.

It varies, and is set by each zone.  Look at this for the current spectrum:
    http://secspider.cs.ucla.edu/images/key-lifetimes.png

> data when RRSIG expires), the problem you are describing might not

In DNSSEC, yes, rollovers are handled "smoothly", but what keeps the cert in
sync?  If a cert exists for (say) a month, but a key rollover happens on
week 1 of the cert's lifetime, then the rollover will have completed long
before someone plans to re-examine and regenerate their cert.  Moreover, how
often do people roll their certs now?  I ask because the existing behavior
is a much better indicator of future behavior than what one _hopes_ people
will do.  Why do you think cert owners will suddenly know how to manage the
cross system dependencies?

Eric

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jun 2011 15:04:16 -0400

There seems to be a lot of confusion here about what such a system can
provide.

As I understand it, the proposal is simply a method of using the DNSSEC
certification chain and the DNS RR formats to establish that the Domain Name
holder authorized the issue of the certificate at the instant of issue.

Thus the only relevant data required to validate the certificate would be
the ICANN DNS root of roots for the time instant that the certificate was
issued.

The rolling of the ICANN root is going to present browsers using this scheme
with the operational challenge of how to update the ICANN root when it
rolls. But that is easily solved for Chrome because it insists on updating
itself at regular intervals. Root rollover is not any sort of issue for the
self signed cert holder.

This approach solve the use cases and requirements stated in the Use cases
and requirements document. It does so without requiring the end point client
to have access to a DNSSEC enabled resolver. It appear to me that it is
considerably better than the scheme proposed in the Hoffman et. al. draft
and it has the benefit of actual deployed code.

This is not the way that I imagined solving the DANE use cases, but this
approach is better than my proposal in respect of the key distribution part.
It does not address the issue of security policy, promiscuous use of SSL,
strict security etc. but that is not a necessity.

The question that comes up as far as security policy is concerned is how
recent a signature should be to be recognized. Should this type of self
signed cert be valid for an hour, a day a week, a year, a decade?

I think we can knock out the idea of an hour or a day pretty easily. The
clock synchronization problem makes systems with cert expiry times of less
than about three days unnecessarily unusable.

At the longer end I would really, really not like to have people recognizing
such certs as valid for more than existing DV certs are recognized.

I think that the max validity of such certs should be pinned at a short
value, that is weeks or months.

It is really easy to automate this type of system. So I don't see a reason
to make the max validity long. The server already has the key, every x hours
it simply checks to see if its SSL cert is out of date and generates a new
one. I would guess that this is why Adam is so keen on the authentication
being to the public key (which is not going to change) rather than the cert.

Rolling the cert is easy in this scheme. Rolling the key will require a DNS
operation, but that can be automated as well.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 30 Jun 2011 15:09:09 -0400

> Managing the crypto in just

I don't think it's quite that bad.  There's not really any PKIX baggage, since the all of the crypto validation comes from the DNSSEC extension.  

The risk of falling out of sync may just be part of the trade-off for speed.  It seems like there's a plausible solution (mod_dnssec_staple), so it doesn't seem like it necessarily has to be a blocking issue.

--Richard

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 15:54:59 -0400

> holder authorized the issue of the certificate at the instant of issue.

This is the crux of the disconnect, the delegation chain is not static, it
doesn't lend itself well to snapshots.  If you take a snapshot w/ a key that
later becomes compromised, and an adversary takes the compromised key and
mints a new cert, how does this approach distinguish them?  In DNSSEC, the
zone will be serving the NEW key, not the old one.  The chain will correct
itself.  This approach would accept the forged cert chain as well as the old
one.

> 
> Thus the only relevant data required to validate the certificate would be the
> ICANN DNS root of roots for the time instant that the certificate was issued.

No, I don't think so. If the cert has the old root key, and chrome has the
new one, then won't it look unverifiable?  The cert will disagree with
what's in DNS.

> with the operational challenge of how to update the ICANN root when it rolls.

Again, I think it is the _CERT_ that has the problem, not the browsers.

> But that is easily solved for Chrome because it insists on updating itself at
> regular intervals. Root rollover is not any sort of issue for the self signed
> cert holder.
> 
> This approach solve the use cases and requirements stated in the Use cases and
> requirements document. It does so without requiring the end point client to
> have access to a DNSSEC enabled resolver. It appear to me that it is
> considerably better than the scheme proposed in the Hoffman et. al. draft and
> it has the benefit of actual deployed code.

Deployed code can still lead to very large outages if the architecture has
problems.  In fact, even if the architecture is "sound" this adds a LOT of
operational complexity by trying to crystallize (maybe not freeze :-P ) the
dynamic chain of trust.

> recent a signature should be to be recognized. Should this type of self signed
> cert be valid for an hour, a day a week, a year, a decade?

No, I don't think so.  You're trying to codify a new/differnt notion of
freshness that is already implicit in the "is it being served in DNS right
now.  Trying to cobble this together from external pieces is dangerous
because it is likely to be wrong/misunderstood/have new operational
complexities that we don't yet understand/etc.

> 
> I think we can knock out the idea of an hour or a day pretty easily. The clock
> synchronization problem makes systems with cert expiry times of less than
> about three days unnecessarily unusable.
> 
> I think that the max validity of such certs should be pinned at a short value,
> that is weeks or months. 

Should huh?  Take a look at the DNSSEC key lifetimes.  They SHOULD not be
years, but the graph I sent shows that people will do whatever they want.
It's quite important for the underlying systems to not risk breakage any
more than necessary, and this approach has a lot of fragility because of its
cross-system dependencies.
 
> It is really easy to automate this type of system. So I don't see a reason to
> make the max validity long. The server already has the key, every x hours it
> simply checks to see if its SSL cert is out of date and generates a new one. I
> would guess that this is why Adam is so keen on the authentication being to
> the public key (which is not going to change) rather than the cert.

Seriously?  I think reviewing some of the trials and tribulations of exactly
this kind of statement in the DNSSEC operational work would be quite
illuminating.  These "easy" things really turn out to be not so easy,
especially where existing practices work against the new proposals.  This is
a very complex change, even if the mechanics seem easy.

> operation, but that can be automated as well.

I think the operational machinery and learning curve should not be so
greatly underestimated.

Eric

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 30 Jun 2011 15:57:20 -0400

On 6/30/11 3:09 PM, "Richard L. Barnes" <[email-masked]> wrote:

> I don't think it's quite that bad.  There's not really any PKIX baggage, since
> the all of the crypto validation comes from the DNSSEC extension.
> 
> The risk of falling out of sync may just be part of the trade-off for speed.
> It seems like there's a plausible solution (mod_dnssec_staple), so it doesn't
> seem like it necessarily has to be a blocking issue.

Again, I think the operational complexities are being vastly underestimated.
The certs have to be regenerated by authorities for websites based on
changes in DNS zones that exist anywhere along the validation chain.  In
particular, how many web server admins keep track of when the root changes
its ZSKs?  I know of the top of my head, but I still would find it a pain if
I had to go regen certs because someone popped a key somewhere... I still
don't even know how I would find that out?

Eric

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Jun 2011 22:26:31 +0200 (MEST)

> cross system dependencies?

For use with DANE, you really want your X.509 Validity to be far far far
into the future so that it will NEVER happen that you have to replace
your certificate because of PKIX-style expiration.  If you're using
a cert issued by a CA (such as from the TLS X.509 PKI) then the
server cert lifetime will be subject to their policies, of course.

The purpose of the original validity in X.509 is twofold
  -- to maintain the commercial CA business model and invoicing
  for a subscription model (recurring fee or slightly reduced fee
  upfront for the entire period with no refund for unused time).
  -- to limit the growth of CRLs and to allow CAs to eventually
  dispose of their old keys and retire CRL publishing for a CA key.

When a server certificate is _not_ from a traditional PKI, but from
your own CA or self-signed and distributed through DANE, then you
do NOT want any certificate validity to inflict unnecessary
administrative overhead.  The validity of the certificate
is entirely governed by the existence of a signed DANE record
refering to that cert.  And the cert becomes automaticlly invalid
as soon as its DANE record is deleted from the DNS zone and the
RRSIG of any existing/published DNS records expire.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Jun 2011 21:32:48 +0100

>   dispose of their old keys and retire CRL publishing for a CA key.

Not part of the argument on this, but I believe the above
is incorrect. X.509 was originally the authentication framework
for X.500 intended to allow DUAs to authenticate to directories.
For that use-case, an expiry is quite appropriate. Of course
notAfter is a PITA in some other cases and has given rise to
some parts of a business model. But I don't believe that either
of the above reasons were the original intent at all.

S.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 30 Jun 2011 16:47:20 -0400

> don't even know how I would find that out?

It's not really so mysterious, it's just the chain from the name in the cert to the root.  If I'm trying to maintain a cert for isoc.org, I have to monitor 9 records (+RRSIGs)

1. . DNSKEY
2. . DNSKEY 
3. org DS
4. org DNSKEY
5. org DNSKEY
6. isoc.org DS
7. isoc.org DNSKEY
8. isoc.org DNSKEY
9. isoc.org TLSA

So my script polls for these records whenever the TTL expires, and issues a new cert whenever the chain changes.  Seems like a pretty defined scope, and like I said before, a plausible solution.

--Richard

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Jun 2011 22:53:39 +0200 (MEST)

> of the above reasons were the original intent at all.

I don't know just how badly the original designers wanted this,
but certainly these were the obvious characteristics they put into
their design.

But there seem to be USgov CAs that do not seem to use it to limit
CRL growth (or might be using cert lifetimes with revocation policies
that appear somewhat imbalanced with respect to processing performance),
e.g. http://crl.disa.mil/getcrl?DOD%20CA-19
(22 MBytes, >1million revocations including revocation dates of 2008)

If you're being sent S/Mime EMails signed with short-lived certificates,
you may realize just how badly CA-imposed short validity impairs
the usability of a whole system.  The S/Mime signed Emails in my
Outlook mail archives that show "signature invalid" (signer cert expired)
outnumber those with a valid signature by a factor of 5, and that factor
is monotonically increasing.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 1 Jul 2011 01:12:56 +2600 (MEST)

> value, that is weeks or months.

Software that will automatically time-bomb itself with absolutely no
need for it seems like a bad idea.

To completely avoid any detrimental side effects,
simply choose a notafter 30 years into the future is just fine
-- but since there is a 32-bit time_t wrap in early January 2038,
you might want to be conservative and not use a notafter date
beyond Jan 1st, 2038 for a few more years.

There is no security value in validity dates of self-signed X.509
server certs distributed through DANE, so including attributes
that may break interop for some peers when some administrative
procedures are suspended or fail for a short amount of time
seems ridiculous.

If certificates would be subject to accellerated bit rot impairing
their security, then we should worry about the trust anchors in
browser much more than about a Web-Server using a home-grown server
cert for more than a year. 

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jun 2011 19:48:08 -0400

My operational experience of PKI is clearly different from Martins.

For the purposes of TLS a cert only needs to authenticate the public key
used for key exchange. Non repudiation is not a requirement, decryption of
stored data is not a requirement, archiving is not a requirement.

If we had reliable net time we could set the validity interval at an hour
with no ill effects (well except for timing out fast restarts). Since we do
have those issues a period of 72 hours is probably optimal.

This is a self signed cert. The server creates it using the same key as for
the TLS exchange. The RP need not even check the signature.

The server does not need to store the cert on disk, it can create a new one
each time it starts. In fact it could create a new cert for every connection
if it wanted to (can't think of why it would).

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Jul 2011 09:57:34 +1000

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> It's not really so mysterious, it's just the chain from the name in the cert 
> to the root.  If I'm trying to maintain a cert for isoc.org, I have to monito
> r 9 records (+RRSIGs)

6 RRsets + RRSIGs
 
> 1. . DNSKEY
> 2. . DNSKEY RRSIG (15 days validity)
> 3. org DS	
> 3. org DS RRSIG (5 days validity)
> 4. org DNSKEY
> 5. org DNSKEY RRSIG (20 days validity)
> 6. isoc.org DS
> 6. isoc.org DS RRSIG (20 days validity)
> 7. isoc.org DNSKEY
> 8. isoc.org DNSKEY RRSIG (14 days validity)
> 9. isoc.org TLSA
> 9. isoc.org TLSA (30 days validity)
> 
> So my script polls for these records whenever the TTL expires, and issues a n
> ew cert whenever the chain changes.  Seems like a pretty defined scope, and l
> ike I said before, a plausible solution.

Now having the server maintain a DNS TTL controlled cache of the
records required to validate the TLSA and returning those wouldn't
break anything the DNS zone operators are depending apon.  This
doesn't have to be in the CERT.  You can tentitively trust the CERT,
then request the DNS validation chain, then decide whether you full
trust the CERT.  The only thing the CERT needs is a indication that
the server supports requesting the DNS validation chain.  Even if
the returned validation chain is incomplete the client can request
the missing bits.

Mark

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Jul 2011 02:14:01 +0100

On 30 Jun 2011, at 20:57, "Osterweil, Eric" <[email-masked]> wrote:
> In particular, how many web server admins keep track of when the root changes its ZSKs?  I know of the top of my head, but I still would find it a pain if I had to go regen certs because someone popped a key somewhere... 

No no no. Key lifetimes are not a problem. They are measured in years. You need to care about signature lifetimes which are measured in days.

A web server SSL cert with an embedded DNSSEC trust chain needs to be regenerated daily at least.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jun 2011 21:49:27 -0400

Exactly,

And moreover there are two cases where it is easy to automate a process
reliably, one is when the event happens exactly once and the other is when
it happens every day.

Refreshing certs after a year is hard. If someone breaks the update scheme
it may be 11 months before you find out and by then you don't know who broke
it.

Doing it every day is a perl script. If it is broken you will know soon
enough to fix it.

On Thu, Jun 30, 2011 at 9:14 PM, Tony Finch <[email-masked]> wrote:

> > In particular, how many web server admins keep track of when the root
> changes its ZSKs?  I know of the top of my head, but I still would find it a
> pain if I had to go regen certs because someone popped a key somewhere...
>
> No no no. Key lifetimes are not a problem. They are measured in years. You
> need to care about signature lifetimes which are measured in days.
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 1 Jul 2011 05:33:33 +0200 (MEST)

> it may be 11 months before you find out and by then you don't know who broke

Remembering a non-trivial, non-intuitive administrative procedure
that you do only once a year one year later, that is hard.
(like remembering a complex unique password that you set a year ago
and never used since).

Software can be designed to automatically give you prior notice with
sufficient time left, which specific recurring administrative procedure(s)
will need to be done and when.

> Doing it every day is a perl script. If it is broken you will know soon

I would normally set up "refresh" in a fashion that it is tried
at least 3 times well within the validity period and that I'm notified
about the result, and even if I didn't manage to react on two
failure notifications (vacation, swamped with work, sickness),
the machine would still be running.

> 
> Tony Finch <[email-masked]> wrote:
> >

Daily sounds quite extreme.  What RRSIG lifetimes do you have in mind?
And wouldn't you have to distribute the matching DANE/TLSA record
before you could start using that cert on your server
(wouldn't others that have previous replies with unexpired RRSIGs cached
not request and therefore not see the new record and not be able
to verify the new server cert?)

I'm wondering: is it common for today's web-servers to support in-flight
replacement of the server certificate.  (if your web-server offers
streaming or downloads of huge files, will a server cert update
adversely affect currently active tls sessions?)

-Martin

---

From: Rickard Bellgrim <[email-masked]>
Date: Fri, 1 Jul 2011 08:31:37 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Langley
> Sent: den 29 juni 2011 13:22
> To: Rickard Bellgrim
> Cc: [email-masked]
> Subject: Re: [dane] Draft for serializing DNSSEC chains
> 
> > Isn't the initial_key_tag a little bit weak as a trust anchor? You could easily
> get a collision here. Perhaps using the DS as initial_ds instead of
> initial_key_tag?
> 
> It's only used in the same way as in DNSSEC: an optimisation. If you have
> multiple keys with the same key tag then you have to try all of them.

What I meant was that it is easy to spoof the root key because you are using the key tag as the trust anchor. Or should you use a secure resolver in front of this application?

// Rickard