Subject: Re: WGLC on DNSSEC bis document set

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 Jan 2004 16:11:27 +0900

Olaf Kolkman wrote:

> This is a working group last call for the DNSSEC bis specification.

Though I still can't see any reason to have DNSSEC, I
spent 30 minutes to read:

>      draft-ietf-dnsext-dnssec-intro-08

and felt alarted that it says:

   A security-aware
   resolver should be configured with at least one authentication key or
   a key's DS RR hash as the starting point from which it will attempt
   to establish authentication chains.

My question is, where is the information on key or hash
expiration date stored and how?

I spent another 30 minutes to read:

>      draft-ietf-dnsext-dnssec-records-06
>      draft-ietf-dnsext-dnssec-protocol-04

but can't find any information on it yet.

First, I thought hash of a resolver should be over key and
expiration date, which minimize configuration on resolvers.
But I found it not the case.

							Masataka Ohta

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 15 Jan 2004 03:08:12 -0500 (EST)

> expiration date stored and how?

Some distributors of keys intended for configuration in resolvers may
not expect to ever change their keys.  Some may also distribute chains
of keys, intended to be rolled over at regular intervals.  Some may
even distribute algorithms that generate the key to be used at a
particular time.

Perhaps resolvers should include support for such practices, and I
invite you to make that case to resolver authors in appropriate
forums.  I don't see how this is a protocol issue that needs to be
addressed in these specifications.

-- Sam

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 Jan 2004 20:32:09 +0900

Samuel Weiler;

> even distribute algorithms that generate the key to be used at a

You are arguing that DNSSEC specification is incomplete and not
ready for last call evaluation, unless all the operational details
are specified, which is a valid point against DNSSEC.

> addressed in these specifications.

Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says

   A security-aware

to specify hash should be that of DS RR?

It is necessary to standardize hash information format necessary
for resolvers so that zone administrators do not have to provide
hash information in 1,000 different ways.

						Masataka Ohta

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 15 Jan 2004 08:24:43 -0500

----- Original Message ----- 
From: "Masataka Ohta" <[email-masked]>

> are specified, which is a valid point against DNSSEC.

Not exactly.  Trust anchors are pre-configured and loaded at startup.  This
could be done by any number of means, and some administrators and network
operators may have a preference for another, existing method instead of the
DNS protocol.

> hash information in 1,000 different ways.

At the time of writing, it was assumed to be similar to the DS RDATA.
However, the DS RR can use different algorithms for creating the DNSKEY hash
(SHA1 is the only currently defined one).  How the trusted keys are stored
is strictly an internal resolver issue, not a protocol issue.  Zone
administers do not have to provide the hash of a DNSKEY anyway:  If the
resolver loads with hashes of trusted keys, it can compute those hashes for
the keys it recieves to match with the trusted values.  The resolver does
the work in DNSSEC, not the zone servers.

> Masataka Ohta

Scott

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 15 Jan 2004 13:37:47 -0500 (EST)

> are specified, which is a valid point against DNSSEC.

I'm sorry to hear that I was unclear again.  That seems to be common
in our conversations (see namedroppers on 13 November 2003.)

To the contray, I think trust anchor configuration is a matter of
local policy.  It's a knob, albeit a more complex one than disabling
an untrusted algorithm.  Conventions for it will develop, and they
could have profound impacts on resolvers' configuration interfaces and
the user experience of DNSSEC, but they do not affect the on-the-wire
protocol.  The DNSSECbis document set is complete without documenting
more than the token set of them that it documents now.  Furthermore,
having the base protocol deployed will help us develop more useful
trust anchor configuration schemes.

> to specify hash should be that of DS RR?

As an example of something that might be reasonable.  A gentle nudge
in the right direction.  That's not a 2119 SHOULD.

-- Sam

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 Jan 2004 05:15:15 +0900

Samuel Weiler;

> local policy.

Trust anchor configuration policy of a resolver is a matter
of policy local to the resolver.

However, trust anchor configuration procedure of a resolver
for a zone involves two administrators that there is no
locality.

Standardization is inevitable.

> It's a knob, albeit a more complex one than disabling
> protocol.

To implement something, it is not enough to specify on-the-wire
protocol. It is also necessary to specify what (not necessarily
how, which is an operational issue) kind of information is
obtained off-the-wire.

Resolvers which can not handle key hash expiration is broken,
if there are zones with key expiration.

Protocol specifications to allow for broken implementations
are broken.

> The DNSSECbis document set is complete without documenting
> more than the token set of them that it documents now.

It is incomplete.

> in the right direction.  That's not a 2119 SHOULD.

It is an incomplete attempt to address the real problem.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 Jan 2004 05:23:20 +0900

Scott Rose;

> operators may have a preference for another, existing method instead of the

Can you define what is a "trust anchor" which never appears in
any of the three IDs.

Note that I'm not asking how it is distributed and stored.

							Masataka Ohta

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 15 Jan 2004 15:32:58 -0500

----- Original Message ----- 
> Note that I'm not asking how it is distributed and stored.

Poor word choice in my statement.  I used trust anchor to mean a key that is
to be trusted and used to form an authentication chain in DNSSEC.  An
example would be the root "." zone key, but it could be any zone key, or
even a hash of a zone key.

Scott

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 Jan 2004 05:44:12 +0900

Scott Rose;

> I used trust anchor to mean a key that is

Then, it is insufficient information for resolvers.

						Masataka Ohta

---

From: [email-masked]
Date: Thu, 22 Jan 2004 16:32:17 +0900

>	draft-ietf-dnsext-dnssec-records-06

	sorry that i did not meet the last-call deadline.

	will try to go throgh draft-ietf-dnsext-dnssec-protocoo-04 soon.

itojun

intro-08 3. or 4.
	you may want to enumerate what "most of the threats" are solved, or
	not solved - dnsext-dns-threats have the following sections
	(dnsext-dns-threats section 3 does not apply here as section 3 analyzes
	old-DNSSEC), and it is not easy to relate topics in intro-08 to each
	item.

	2.  Known Threats
	2.1.  Packet Interceptionu
	2.2.  ID Guessing and Query Prediction
	2.3.  Name Gamesco'
	2.4.  Betrayal By Trusted Serversu
	2.5.  Denial of Servicenda!
	2.6.  Authenticated Denial of Domain Names

records-06 1.3.1
	i think it fine to move DSA to OPTIONAL.

records-06 2, 3, 4
	"The xxxx RR is class independent" - which class should I use then?
	(I assume it to be "IN" but there's no guidance)

records-06 2.1.1
	by "Bit X" do you mean 2^X ("bit 0" is LSB), or 2^(16-X) ("bit 0"
	is MSB)?  there's no definition given.  maybe it is better to put
	these bits into diagram (2.1).

records-06 2.2
	description on Flag field seems too restrictive; isn't there any
	chance that Flag field be 1?  i think it better to state "The Flag
	field MUST be represented as an unsigned decimal integer" (e.g.
	no example values).

records-06 3.1.5
	description of signature expiration/inception field is a bit confusing.
	for instance, when expiration is smaller than inception (like
	expiration = 1 and inception = 2^32 - 1), expiration field is not the
	number of seconds since 1970/1/1, but 2^32 more.

	what happens when 2^32 seconds have passed? (year 2106)
	maybe it's better to have these fields 64bit, or have scaling parameter
	like TCP window scaling option?