Subject: Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 09 Mar 2009 11:12:30 -0400

At 13:46 06/08/2008, Paul Hoffman wrote:
>Greetings again. The end of section 2 of this document says:
>    Another advantage of configuring a trust anchor using a DS record is
>    that the entire hash of the public key in the DS RDATA need not
>    necessarily be specified.  A validating resolver MAY support
>    configuration using a truncated DS hash value as a human-factors
>    convenience: shorter strings are easier to type and less prone to
>    error when entered manually.  Even with a truncated hash configured,
>    a validating resolver can still verify that the corresponding DNSKEY
>    is present in the trust anchor zone's apex DNSKEY RRSet.  RFC 2104
>    [RFC2104] offers guidance on acceptable truncation lengths.
>
>This is not correct. You cannot say "here is the SHA-256 hash of a 
>value" and then give less than 256 bits of the hash. If you wanted 
>to do this, you need to define the truncated hash and use that new 
>hash algorithm. So far, none of these truncated hashes have been 
>defined for DNSSEC, although ones could be defined.
>
>Further, it is somewhat optimistic (and possibly sadistic) to think 
>that a user can type Base64 by hand for more than maybe ten 
>characters. This document should assume that the user is using 
>copy-and-paste, and therefore using the full 256 bits of the hash is 
>just as easy as using a truncated hash. If not, new, inherently 
>weaker, truncated hash algorithms need to be defined.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_

You are not the first person to bring this issue up, and upon reflection
we have dropped truncation discussion.

         Olafur

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2009 08:35:40 +1100

In message <[email-masked]>, Olafur Gudmundsson wri
tes:
> --===============0733757033==
> Content-Type: multipart/alternative;
> 	boundary="=====================_777355448==.ALT"
> 
> --=====================_777355448==.ALT
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 

	On a related issue DS -> DNSKEY translations cannot be
	performed until the DNSKEY is published in the zone.  The
	use of DS prevents pre-publishing of keys.

	I can see no real reason to recommend that DS records be
	published in preference to DNSKEY records.

	DNSKEY -> DS is a conversion that can be at anytime.

	This make DNSKEY a better manditory record to publish.

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

---

From: David Blacka <[email-masked]>
Date: Mon, 9 Mar 2009 18:58:41 -0400

> 	use of DS prevents pre-publishing of keys.

Huh?  You can generate a DS from the DNSKEY record that you have  
generated but not yet published, so you can pre-publish the DS just as  
soon as you could pre-publish your DNSKEY.  As for actually *using*  
the DS as a trust anchor, you can't use either the DS or the DNSKEY  
prior to actually publishing and *using* the DNSKEY.  Or maybe I just  
don't understand your point.

> 	published in preference to DNSKEY records.

They are small and easier to eyeball as correct.

> 	This make DNSKEY a better manditory record to publish.

I don't follow.

--
David Blacka                          <[email-masked]>
Sr. Engineer          VeriSign Platform Product Development

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2009 12:55:51 +1100

In message <[email-masked]>, David Blacka wr
> don't understand your point.

	When you pre-publish a DS you prevent implementations that
	use DNSKEYs from taking advantage of that pre-publication.

	When you pre-prepublish DNSKEYs implementations that use
	DS or DNSKEYs can taking advantage of that pre-publication.

---

From: [email-masked]
Date: Tue, 10 Mar 2009 04:11:05 +0000

On Tue, Mar 10, 2009 at 08:35:40AM +1100, Mark Andrews wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

	if the child produces the DS, then the TTL is preserved.
	if the parent produces the DS, then the TTL is not.

	i'd think that would be a reason to use DS as the record to 
	publish.

--bill

---

From: [email-masked]
Date: Tue, 10 Mar 2009 04:12:54 +0000

> 	use DNSKEYs from taking advantage of that pre-publication.

	sounds like an implementation bugll

--bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2009 15:36:10 +1100

> 	if the parent produces the DS, then the TTL is not.

	That depends on the processes used.  There is no reason a
	parent can't produce a DS with a specified TTL.  There is
	also no requirement for the parent to honour the ttl, if
	any, passed to the parent.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2009 15:43:52 +1100

> 	sounds like an implementation bugll

	draft-ietf-dnsop-dnssec-trust-anchor is unfairly trying to
	restrict what is can be used as a trust anchor.  It is
	retroactively changing the specification.
	
   A security-aware resolver MUST be capable of being configured with at
   least one trusted public key or DS RR and SHOULD be capable of being
   configured with multiple trusted public keys or DS RRs.  Since a
   security-aware resolver will not be able to validate signatures
   without such a configured trust anchor, the resolver SHOULD have some
   reasonably robust mechanism for obtaining such keys when it boots;
   examples of such a mechanism would be some form of non-volatile
   storage (such as a disk drive) or some form of trusted local network
   configuration mechanism.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Mar 2009 08:24:53 -0400

>         use of DS prevents pre-publishing of keys.

Once the key is generated a DS of it can be generated.

Our draft does not in any way make any assumptions about how
trust anchors are "discovered" or "disseminated"
What can be done with a DNSKEY TA can be done with a DS TA.
DS prepublication has the further advantage that it does not expose the
KEY during the "pre-publication period" preventing factoring attacks
on the key during this time period.

>         published in preference to DNSKEY records.

We see nothing but problems by using DNSKEY records.
We want to prevent the configured party from blindly using DNSKEY records
by forcing it to fetch the current DNSKEY RRset and make sure the trust anchor
configured is still there.
By configuring DS instead of DNSKEY the processing is almost the same as it is
for delegations. The last thing we want is a compromised TA can be 
used to sign
forged answers for a long time after the compromised key is Removed/Revoked.

>         This make DNSKEY a better manditory record to publish.

I do not follow

         Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Mar 2009 10:00:47 -0400

At 00:43 10/03/2009, Mark Andrews wrote:

> > > In message <[email-masked]>, 
> David Black
> > a wr
> > > ites:
> > > >

Before this draft there was NO specification what so ever on what trust
anchor configuration should look like.
The trusted-key statement in Bind-9 is OLDER than the DS definition.
One of the disadvantages of being an early adopter is that there frequently
is no guidance on the best way to do things.

draft-ietf-larson-dnsop-trust-anchor-00 was published over 2 years ago.
it was on the agenda of number of DNSOP meetings before begin adopted
14 months ago. This is the first time anyone has raised
an issue with DS being the recommended approach, section 2 has the
justification why DS is better than DNSKEY. Please explain where section
2 is wrong before asking for change in recommendation.
The draft is aiming for Informational status not standards track, thus
implementations are free to ignore the draft, or provide tools that
take a list of DS records and translate that into trusted-key block.

While DS was being defined some people wanted it to be a clone of the 
DNSKEY record
but that approach was rejected. DS is based on PGP key finger prints and that
model has held up well in the real world for creating trust relationships.

>    configured with multiple trusted public keys or DS RRs.

trust-anchor draft does not violate this, just recommends one approach over the
other and explains why that is better practice.
We must learn from history or the same mistakes will be made.

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Mar 2009 10:52:11 -0400

>	This make DNSKEY a better manditory record to publish.

While there's little empirical data on trust anchors to date, my 
inclination is to whole-heartedly disagree with this statement.  So 
long as the DS record points to a unique DNSKEY record and the DS 
record involves less typing than a DNSKEY, I'd want to work with a DS 
record.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Mar 2009 08:19:41 +1100

> record involves less typing than a DNSKEY, I'd want to work with a DS 

	Has anyone on this list ever typed in a DNSKEY or DS as a
	trust anchor?  I would presume that most (99.9999%) people
	would just cut-and-paste or the equivalent.  I call "ease
	of typing" a unjustifiable justification as no one will be
	doing it even for DS records.

	I will agree that DNSKEY's are harder to compare, but I
	believe impossible trumps harder and it is impossible to
	convert a DS to a DNSKEY prior to the publication of the
	DNSKEY in the DNS.  The reverse is not true.

	Mark

---

From: Matt Larson <[email-masked]>
Date: Tue, 10 Mar 2009 17:36:43 -0400

Mark,

On Wed, 11 Mar 2009, Mark Andrews wrote:
> [...] it is impossible to convert a DS to a DNSKEY prior to the
> publication of the DNSKEY in the DNS.

Why would a validator ever need to do this?

Matt

---

From: Chris Thompson <[email-masked]>
Date: 10 Mar 2009 22:01:19 +0000

> doing it even for DS records.

I have to agree with that, except that you probably need more 9's.

> DNSKEY in the DNS.  The reverse is not true.

But that's exactly seen as a benefit in section 2 of 
draft-ietf-dnsop-dnssec-trust-anchor ("forces priming")
and in previous posts here ("does not expose the KSK to
factorisation attacks during the pre-publication period").
You may consider these nugatory benefits, but perhaps you
should say why.

I admit to a prejudice in favour of DS-shaped trust anchors,
really based on the concept that a trust anchor should be a
certificate "in loco parentis". It fits in with my favourite
spiel about how the root hints "zone" is actually the referral
from Trantor, kept locally only because the RTT to Trantor
is too damn long. On that basis, the trust anchor for the
root zone ought to be the DS record from Trantor.

-- 
Chris Thompson
Email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Mar 2009 09:14:14 +1100

> Why would a validator ever need to do this?

	Because it makes it possible to change DNSKEYs without
	having to have both the old and new key present in the zone
	at the same time.

---

From: Matt Larson <[email-masked]>
Date: Tue, 10 Mar 2009 19:22:16 -0400

> 	having to have both the old and new key present in the zone

I don't see it.  Please explain further.

Matt

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Mar 2009 10:40:59 +1100

> I don't see it.  Please explain further.

	I have a new key I want to introduce.  I add the DS to the
	parent zone at least the ttl(ds) before I start using that
	key in the zone.  After the DS has been published for ttl(ds)
	I can then replace the DNSKEY referred to by the old DS
	with that of the new DS and re-sign the DNSKEY RRset.  Once
	the ttl(dnskey) has expired I can remove the old DS from
	the parent zone.

	I wish to be able to do something similar with trust anchors.
	Publishing DS prevents me from doing so.

	Mark

---

From: [email-masked]
Date: Wed, 11 Mar 2009 08:26:17 +0000

> I have to agree with that, except that you probably need more 9's.

Oh, I don't know about that.

Three 9's should be more than enough accuracy to describe the set of 
people who've ever put a DS or DNSKEY record in their zone files ;-)

Ray

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Mar 2009 10:57:31 -0400

>	trust anchor?  I would presume that most (99.9999%) people

"work with" != type in

>	Publishing DS prevents me from doing so.

There is more than one way to do a key supersession.  I'll describe 
one assuming DS records are installed as trust anchors.

DS(KEY1) is in my validator.  The owner of KEY1 distributes DS(KEY2) 
with a note that it should be installed "by the 15th."  On the 15th, 
DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the 
keyset.  With a 1 week TTL on the key set's RRSIG RR, a week later 
DNSKEY(KEY1) is removed from the set.  At some point after that I can 
remove DS(KEY1) from my validator.

Perhaps the special case here is that the keyset is unique in that 
the signatures for SEP/KSK's are "tied" to the where the key data is. 
I.e., if you have something signed by KEY1, then you have KEY1 
because that something has to be the key set.

If the zone is not run with a KSK/ZSK split, then the removal of KEY1 
is triggered by signing the last RR set by KEY2 and then the TTL.

The principle here is that there is no error if "for a DS record 
there is no corresponding DNSKEY" and vice versa.  All that is needed 
for validation is one "chain of trust."  Accepting dangling 
references is not optimal but provides robustness.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Mar 2009 10:49:03 +1100

> references is not optimal but provides robustness.

	Ed, I'm aware there are multiple ways to do this.  However
	publishing DS records only precludes some methods.  Publishing
	DNSKEY records does not preclude any methods as one can
	*ALWAYS* generate a DS from a DNSKEY.  The reverse requires
	you to look up a key which matches which means it must be
	available to be available to be looked up.

---

From: Joe Baptista <[email-masked]>
Date: Wed, 11 Mar 2009 20:10:58 -0400

You poor souls.  The DNSSEC monster is vast and complex.  So much easier
just to fix the problem instead of this endless gibberish.  It's so complex
it's funny when you consider a simple solution like DNSCURVE -
http://dnscurve.org/ - and so much more secure.  No man in the middle
issues.

Oh well - sorry for the interruption - and carry on.

cheers
joe baptista

On Wed, Mar 11, 2009 at 10:57 AM, Edward Lewis <[email-masked]> wrote:

> There is more than one way to do a key supersession.  I'll describe one
> assuming DS records are installed as trust anchors.
>
> DS(KEY1) is in my validator.  The owner of KEY1 distributes DS(KEY2) with a
> note that it should be installed "by the 15th."  On the 15th, DNSKEY(KEY2)
> is placed in the zone and KEY2 only is used to sign the keyset.  With a 1
> week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed
> from the set.  At some point after that I can remove DS(KEY1) from my
> validator.
>
> Perhaps the special case here is that the keyset is unique in that the
> signatures for SEP/KSK's are "tied" to the where the key data is. I.e., if
> you have something signed by KEY1, then you have KEY1 because that something
> has to be the key set.
>
> If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is
> triggered by signing the last RR set by KEY2 and then the TTL.
>
> The principle here is that there is no error if "for a DS record there is
> no corresponding DNSKEY" and vice versa.  All that is needed for validation
> is one "chain of trust."  Accepting dangling references is not optimal but
> provides robustness.
>
> --

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

---

From: Ralf Weber <[email-masked]>
Date: Thu, 12 Mar 2009 01:40:49 +0100

Moin!

On 12.03.2009, at 01:10, Joe Baptista wrote:

> You poor souls.  The DNSSEC monster is vast and complex.  So much  
> easier just to fix the problem instead of this endless gibberish.   
> It's so complex it's funny when you consider a simple solution like  
> DNSCURVE -http://dnscurve.org/ - and so much more secure.  No man in  
> the middle issues.
DNSCurve solves a different problem. It's about encryption of DNS  
data, while DNSSEC looks on authentication of DNS data. DNSSEC and  
DNSCurve are complementary solutions not contradicting solutions.

> Oh well - sorry for the interruption - and carry on.
Ahem could I ask why you are carrying my companies logo on your  
webpage? If there is an contractual relationship please send me the  
details off list, otherwise please remove it.

On the topic DNSKEY or DS keys as trust anchors I would opt for  
DNSKEYS as there may be publication of trust anchors that may have  
hash/digest algorithms that my resolver/validator doesn't understand.  
This already happened to me :-(.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

Schütze Deine Umwelt | Erst denken, dann drucken

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland  
* Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *

Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies *  
Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Mar 2009 01:16:33 -0400 (EDT)

> 	available to be available to be looked up.

Which can be a good thing. For instance, adding keys to the DLV, I think it
is better to give ISC the DS record. If they cannot get the DNSKEY, neither
can the world, and then you don't want the DLV entry to be included.

Paul