Subject: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Jan 2014 12:22:40 -0500

Dear colleagues,

For my sins, I have been following some of the recent discussions
about "Internet governance".  One of the discussions over on the
"1net" list (http://1net-mail.1net.org/mailman/listinfo/discuss) is
about the control by one particular government of the DNS root zone,
and how uncomfortable that makes some other governments.  The
consequence has been renewed discussion on a somewhat older proposal
for splitting up the management of the root zone keys.  The proposal
can be found at
http://www.internetgovernance.org/wordpress/wp-content/uploads/SecuringTheRoot.pdf.

The proposal has the appealing property that nobody can "hijack" the
root, and if you don't trust any particular actor then the approach
ensures that it is at least technically difficult (or detectable) that
someone has acted alone.  But it has always seemed to me that the
approach would result in a very great increase in the size of the root
key RRset as well as the RRSIGs necessary at least over the DNSKEY
RRset.  One response to this
(http://1net-mail.1net.org/pipermail/discuss/2014-January/001057.html)
is, "So what?  It's the root.  It'll be widely cached, and TCP is a
small price to pay for this on the occasions it's needed."

I am not sure I am so sanguine, but this put in my mind the
draft-ietf-dnsop-respsize draft, which I now realise was never
published as an RFC.

I'd like this thread to discuss the "so what, use TCP!" remark.  I'd
also like to ask either the chairs or the WG whether
draft-ietf-dnsop-respsize-14 needs revision and, if so, what revision
to be publishable, because I think it's needed advice.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Jan 2014 13:54:56 -0500

> http://www.internetgovernance.org/wordpress/wp-content/uploads/SecuringTheRoot.pdf.

It's interesting to see that what was actually built in 2009/2010 is largely compatible (at the high-level diagram level) with what was proposed, except that there's only a single RKO and it's called IANA. The general framework (as deployed today) whereby KSRs are sent from the RZM to the RKO and ceremonies are held at the RKO to process them seems eminently extensible, at least in theory.

However, each RKO you add increases the operational risk that an SKR from that RKO might not be obtained within the required window, which puts zone publication in jeopardy. It also adds points where political concerns might lead to a refusal to sign. Since a KSR is not linked to a specific set of proposed changes to the root zone, a refusal to sign would presumably be on general/philosophical grounds rather than in reaction to any particular proposed change to the root zone.

Timing for KSK rollover would have to be carefully managed, since it seems like having multiple RKOs roll their KSKs in overlapping windows would be a recipe for grand hilarity.

> root,

Well, in fact any RKO can hijack the root (by which I mean put its publication in jeopardy for people validating against that RKO's trust anchor). They can just refuse to process a KSR; during the time window corresponding to that KSR, validators depending solely on that RKO's trust anchor would see the namespace go dark.

[If validators took the approach of installing trust anchors from each and every RKO to mitigate this possibility, then they are effectively saying "I'm happy so long as at least one RKO is happy even if all the others are deeply miserable", which doesn't sound like it achieves the document's objectives.]

In terms of custody of each KSK, multiple RKOs means multiple opportunities to compromise private key assets. That's a change to the risk profile. Also, one RKO performing key ceremonies is tedious enough, imagine if there were five times as many :-)

> to be publishable, because I think it's needed advice.

I also think that draft should be published. I think we have a little more operational experience with (and studies that speak to) large responses now than we did when Vixie last lifted the pen on that document, so I imagine it would benefit from some review.

I would be happy to review and/or contribute.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Jan 2014 15:08:49 -0500

On Tue, Jan 14, 2014 at 01:54:56PM -0500, Joe Abley wrote:

> It's interesting to see that what was actually built in 2009/2010 is
> largely compatible (at the high-level diagram level) with what was
> proposed

I thought that was interesting too.

> However, each RKO you add increases the operational risk that an SKR
> from that RKO might not be obtained within the required window,
> which puts zone publication in jeopardy.

Good point.  I think the idea is that this is a feature, because it's
supposed to be the Mutually-Assured Destruction threat that will
prevent the USG from unilaterally removing some country from the root
zone (that seems to be the threat people are worried about.  Why is
left as an exercise for the reader.  Note that I do not promise there
is a solution to this exercise).

> [If validators took the approach of installing trust anchors from
> each and every RKO to mitigate this possibility, then they are
> effectively saying "I'm happy so long as at least one RKO is happy
> even if all the others are deeply miserable", which doesn't sound
> like it achieves the document's objectives.]

It _might_, if the idea were instead that validators used n of m.  Ben
Laurie had a not-completely-dissimilar idea for root TA distribution
entered in the "rollover" competition back in 2006 or so.  See
http://tools.ietf.org/html/draft-laurie-dnssec-key-distribution-02.

Thanks for the observations, which I think are quite helpful.

A

-- 
Andrew Sullivan
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 15 Jan 2014 09:04:12 +1000

If multiple independent entities sign, can't they elect to use shorter
algorithms?

I know 'short can be spoofed' is out there, but since there are now n *
<512> instead of 1 * 2048 is it not theoretically possible that at a cost
of more complexity, it can be demonstrated that as long as 1) the sigs are
all current 2) all the sig agree then the risk of n 512-bit signings is not
necessarily worse than one 2048 or 4096 bit signing, for the specific need
we have: proof of correctness. (n is unstated. 512 is a nonce. I have no
idea what the sweet spot of keysize and number of keys would be.)

therefore, if this is true, trading complexity for keysize might not
increase the initial bootstrap zone transfer size that much.

I am not a cryptographer and do not play one on TV

On Wed, Jan 15, 2014 at 6:08 AM, Andrew Sullivan <[email-masked]>wrote:

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

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Jan 2014 18:15:08 -0500

On 2014-01-14, at 18:04, George Michaelson <[email-masked]> wrote:

> If multiple independent entities sign, can't they elect to use shorter algorithms?
> 
> I know 'short can be spoofed' is out there, but since there are now n * <512> instead of 1 * 2048 is it not theoretically possible that at a cost of more complexity, it can be demonstrated that as long as 1) the sigs are all current 2) all the sig agree then the risk of n 512-bit signings is not necessarily worse than one 2048 or 4096 bit signing, for the specific need we have: proof of correctness. (n is unstated. 512 is a nonce. I have no idea what the sweet spot of keysize and number of keys would be.)

If you sign the DNSKEY RRSet with N KSKs of the same size as the single current KSK, then presumably the expected time for one of them to be factored is N times lower than the expected time to factor a single key, given the same compute resources being available for each key in all cases.

This suggests that if multiple KSKs are used, the keys need to be longer, not shorter, if the same degree of protection is desired.

I'm assuming that what we're talking about is this:

. IN DNSKEY ZSK0
. IN DNSKEY ZSK1
. IN DNSKEY KSK0
. IN DNSKEY KSK1
. IN DNSKEY ...
. IN DNSKEY KSKn
. IN RRSIG DNSKEY KSK0
. IN RRSIG DNSKEY KSK1
. IN RRSIG DNSKEY ...
. IN RRSIG DNSKEY KSKn

(the size of which makes my hair stand on end) and not this:

. IN DNSKEY ZSK0
. IN DNSKEY ZSK1
. IN DNSKEY KSKnew
. IN RRSIG DNSKEY KSK

where KSKnew is some combinatorial function of {KSK0, KSK1, ..., KSKn} since this second approach still requires a single KSKnew to be prepared in a single place in order to generate the RRSIG, which would presumably be a non-goal of de-centralising control of the keys.

> I am not a cryptographer and do not play one on TV

Me neither.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Jan 2014 16:16:00 -0800

On Jan 14, 2014, at 3:04 PM, George Michaelson <[email-masked]> wrote:

> therefore, if this is true, trading complexity for keysize might not increase the initial bootstrap zone transfer size that much.
> 

I am not a cryptographer but I *do* play one on television, and that proposal is terrible. Breaking asymmetric keys gets logarithmically harder as the key size goes up; that's why no one has publicly broken a 1024-bit RSA key, even though they have had much, much more time (and now-faster CPUs) than the earlier breaks.

It would orders of magnitude easier to break 4 512-bit keys than one 2048-bit key. The work would also parallelize better so that you need smaller systems to do the work.

--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Tue, 14 Jan 2014 16:43:52 -0800

On 01/14/2014 12:08 PM, Andrew Sullivan wrote:
> zone (that seems to be the threat people are worried about.

It historically has been the main threat that several countries are 
worried about, however DNSSEC doesn't do anything to stop it. Other than 
the DS records (if any) the records associated with a given TLD 
(specifically the NS records) in the root are not signed.

Of course as DNSSEC becomes more important removal of the DS records 
will become correspondingly more important, but that's not the threat 
that these people care about.

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 14 Jan 2014 16:50:32 -0800

On 01/14/2014 04:43 PM, Doug Barton wrote:
> Other than the DS records (if any) the records associated with a given
> TLD (specifically the NS records) in the root are not signed.

... obviously the glue records are not signed either of course. My point 
was that it's the delegation that some paranoid countries don't want 
removed, and DNSSEC isn't going to help that.

Doug

---

From: George Michaelson <[email-masked]>
Date: Wed, 15 Jan 2014 11:47:55 +1000

thanks for the cluestick hit. so we can't trade multiple sigs for length,
which means for public benefit reasons adding more visible signers at the
top does irredeemably increase the dataset size because the key size has to
stay high.

there are no free lunches for public accountability.

On Wed, Jan 15, 2014 at 10:16 AM, Paul Hoffman <[email-masked]>wrote:

> I am not a cryptographer but I *do* play one on television, and that
> proposal is terrible. Breaking asymmetric keys gets logarithmically harder
> as the key size goes up; that's why no one has publicly broken a 1024-bit
> RSA key, even though they have had much, much more time (and now-faster
> CPUs) than the earlier breaks.
>
> It would orders of magnitude easier to break 4 512-bit keys than one
> 2048-bit key. The work would also parallelize better so that you need
> smaller systems to do the work.
>
> --Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Jan 2014 12:54:19 +1100

> removed, and DNSSEC isn't going to help that.

And anyone can take the existing root zone, add a delegation and
sign the result with any key of they control.  If a government was
to remove a ccTLD I would suspect that there would be hundreds of
people offering such zones.

Additionally you can just graft on a tld and associated trust anchor
with existing validators if you don't want to regenerate the root
or if you don't want to trust some random person to sign the root
zone for you you can do it that way.

Removal of a ccTLD would cause short term disruption but the net
as a whole would route around the breakage.  We have seen plenty
of examples of this in the past.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Jan 2014 11:30:26 +0000

Andrew Sullivan <[email-masked]> wrote:
>
> It _might_, if the idea were instead that validators used n of m.

N of M validation also solves the other problems Joe mentioned, to do with
key rollover and failure to sign. That is, if a signer drops out (because
it failed to sign the DNSKEY RRset, or because it rolled its key)
validators will continue to work securely, and can update their trust
anchors at leisure.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Jan 2014 11:41:00 +0000

Andrew Sullivan <[email-masked]> wrote:

> I'd like this thread to discuss the "so what, use TCP!" remark.

Nice idea.

http://www.potaroo.net/ispcol/2013-09/dnstcp.html

> I'd also like to ask either the chairs or the WG whether
> draft-ietf-dnsop-respsize-14 needs revision and, if so, what revision to
> be publishable, because I think it's needed advice.

It needs to cover the effect of EDNS0 pseudo-records on truncation, and
the extra DNSSEC records that appear in secure referrals. What about the
interaction between EDNS buffer size and MTU and middleboxes? Haya Shulman
has some attacks that could be discussed in the security considerations
section.

Tony.