Subject: [dnsext] Reminder: two WGLC closing in one week

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Sep 2008 20:45:47 -0400

Dear colleagues,

This is a reminder that there are two outstanding WGLC open, and that
they both expire in one week.  They are for the following two
documents:

draft-ietf-dnsext-rfc2672bis-dname-14.txt 

draft-ietf-dnsext-dnssec-rsasha256-05.txt

The WGLC for both of these have already been extended in order to
address concerns that many people were on vacation in August.  By my
count, we're not quite to the threshold of reviewers with either of
these.  _PLEASE read them and comment_, or else, by the conventions
adopted by the working group, they'll have to die as far as the
working group is concerned.  Given that we took both of these on as WG
items, we owe it to our colleagues who have worked on them to perform
the review.

Thanks, and best regards,

Andrew (for the chairs)

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

--
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: Scott Rose <[email-masked]>
Date: Fri, 19 Sep 2008 08:23:01 -0400

Since I am one of the co-editors of the dname-bis draft I can't comment
on that one.

I have previously expressed my support for the rsasha256 draft.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Sep 2008 15:12:44 -0400

Hi Andrew -

At Scott's request I took a look at the dname document.  Keep in mind that I'm looking at it pretty much for the first time.  Unfortunately, I don't think its ready for prime-time.  Most of the document is fine - but the section on DNSSEC is woefully lacking.

DNSSEC unfortunately makes things more difficult.  Having DNAMEs plus DNSSEC stretches the complications almost to the breaking.

The section needs more than a 1 page description of why DNSSEC servers need to understand DNAME, it needs a discussion of the various combinations of modes in which a resolver can find itself when following a DNAME chain.

For example - what happens if the DNAME is signed, but the referenced target isn't?  What happens if both are signed, but the resolver doesn't have a trust anchor for the target but has one for the DNAME? For the DNAME but not the target?  What happens if the DNAME is directly reachable (e.g. querier is a validating recursive resolver) but the target is available only through a forwarder?  What happens if the DNAME and the target are signed with different algorithm and the querier only understands one of they.

I can see about a number of  different ways to have different resolvers behave given different combinations.  I think they need to be called out and a specific behavior proposed for each prior to sending this forward.

One proposal, once the "must be signed bit" is set (e.g. DNAME or target subordinate to a trust anchor without a delegation to unsecure), then ALL data must be signed to be considered valid.  (Not sure this is the right way of doing things, but its a conversation starter).

Sorry - Mike

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Sep 2008 10:16:28 +1000

In message <[email-masked]>, Michael StJohns writes:
> Hi Andrew -
> 
> At Scott's request I took a look at the dname document.  Keep in mind that I'm 
> looking at it pretty much for the first time.  Unfortunately, I don't think its
>  ready for prime-time.  Most of the document is fine - but the section on DNSSE
> C is woefully lacking.
> 
> DNSSEC unfortunately makes things more difficult.  Having DNAMEs plus DNSSEC st
> retches the complications almost to the breaking.

	How?
 
> The section needs more than a 1 page description of why DNSSEC servers need to 
> understand DNAME, it needs a discussion of the various combinations of modes in
> which a resolver can find itself when following a DNAME chain.

	Why?  DNAME is a method to synthesis a CNAME.  Once you have the
	CNAME you give it the *same* trust level that you gave the DNAME
	and proceed as if there was just a CNAME there.
 
> For example - what happens if the DNAME is signed, but the referenced target is
> n't?

	What happens if a CNAME validates and the name it points to doesn't?

> What happens if both are signed, but the resolver doesn't have a trust an
> chor for the target but has one for the DNAME?  For the DNAME but not the target

	What happens if a CNAME is signed an it's target is signed but you
	don't have a trust anchor for the target?

> ?  What happens if the DNAME is directly reachable (e.g. querier is a validatin
> g recursive resolver) but the target is available only through a forwarder?

	What happens is the CNAME is directly reachable but the target is
	available only through a forwarder?

> What happens if the DNAME and the target are signed with different algorithm
> and the querier only understands one of they.

	What happens if the CNAME and the target are signed with different
	algorithm and the  querier only understands one of they?

> I can see about a number of  different ways to have different resolvers behave 
> given different combinations.  I think they need to be called out and a specifi
> c behavior proposed for each prior to sending this forward.

	Why.  The answers to DNAME are really no different to how you handle
	the CNAME.

	The only thing really different about DNAME is to handle YXDOMAIN.

	Mark
 
> One proposal, once the "must be signed bit" is set (e.g. DNAME or target subord
> inate to a trust anchor without a delegation to unsecure), then ALL data must b
> e signed to be considered valid.  (Not sure this is the right way of doing thin
> gs, but its a conversation starter).
> 
> Sorry - Mike
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Sep 2008 20:08:18 -0400

At 15:12 -0400 9/22/08, Michael StJohns wrote:

>For example - what happens if the DNAME is signed, but the referenced
>target isn't?

There's no problem.  The querier can cryptographically verify that 
the rewrite (DNAME) is true and also determine that there is no 
ancillary data provided for the target's authenticity.

>What happens if both are signed, but the resolver doesn't have a trust
>anchor for the target but has one for the DNAME? For the DNAME but not
>the target?

Same situation - remember that DNSSEC is "security for the querier."

>What happens if the DNAME is directly reachable (e.g. querier is a validating
>recursive resolver) but the target is available only through a forwarder?

DNSSEC is end-to-end, so it doesn't matter the path the data takes. 
If you are saying that the target is not signed and only comes from a 
cache, again, then the querier can only get what it gets.

>and the querier only understands one of they.

Same as answer #2.  DNSSEC is protection from the querier's perspective.

>given different combinations.  I think they need to be called out and a
>specific behavior proposed for each prior to sending this forward.

All we need is interoperability, not full agreement. ;)

>One proposal, once the "must be signed bit" is set (e.g. DNAME or target
>subordinate to a trust anchor without a delegation to unsecure), then ALL
>data must be signed to be considered valid.  (Not sure this is the right
>way of doing things, but its a conversation starter).

"Must be signed bit?"  Data is expected to have a signature if the 
querier can build a "chain" from a configured anchor to the data.  A 
querier can "expect" a signature and barf is one is not received.  A 
querier, upon seeing no DS set at a delegation point (signed negative 
response) has to deal with their being no signature - the querier 
can't ever "demand" a signature (as in "must be signed").

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Sep 2008 21:24:29 -0400

I started to write a longish response, but got to a point where I think I have a question that sort of explains where I'm coming from.  For Mark's message asking how this differs from CNAME - there are basically two types of CNAME - those with targets under the original trust anchor and those that aren't. The former have no real cascade implications as long as the final target and all of the intermediates are under the same trust anchor.

The latter type are most like DNAME, I haven't seen any security analysis of a CNAME cascade.  I may have missed it over the years - if so I apologize for my ignorance.

In the most complex lookup case, we've got cascades of CNAME and DNAME lookups - each being treated in isolation from each other for security purposes.  Is this a correct treatment?  Or just the treatment that's possible given the current definitions?

For example, we start a query in a secure zone - it validates; but DNAMEs into an unsecure zone; and bounces (CNAMEs) back into a secure zone which also validates.  Is the "result" secure, unsecure or some other state?  

Original query is:  "www.somewhere.example.com A" and we have a trust anchor for somewhere.example.com
At somewhere.example.com is a DNAME into unsecure.com which is not signed or for which we have no trust anchor.
At www.unsecure.com is a CNAME pointing at www.otherexample.com
We have a trust anchor for otherexample.com and the zone contents will verify.
At www.otherexample.com is a A record - the answer to our original query.

It turns out the original data at www.unsecure.com was an A record... a hacker got in and changed it.

Does the result parse out as verified?  Should it?

Given that once a validator wanders in to an insecure zone, it can be steered where ever, should we ever mark that data as "trusted validated"?  Sure the last question validated, but the fact that it did is probably worthless for determining the security of the query response.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Sep 2008 12:21:27 +0200

At 21:24 -0400 9/22/08, Michael StJohns wrote:

>At somewhere.example.com is a DNAME into unsecure.com which is not 
>signed or for which we have no trust anchor.
>It turns out the original data at www.unsecure.com was an A 
>record... a hacker got in and changed it.
>

This isn't a problem for the DNS, it's a problem for the application.

DNSSEC will allow the querier to know that it got some records and 
they are verified, it will also know that it got other records for 
which there is no ancillary protection information.  DNSSEC will not 
permit "protected" records to be spoofed (within the bounds of what 
it can do).

So far as whether the "final answer" is right, that's an issue for 
applications.  The application would have to make the judgement 
whether it would accept the "chain" of DNAMEs and CNAMEs - or judge 
what the semantics of the proofs are.

Perhaps a discussion of this belongs in the Security Considerations 
of DNSSEC bis.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Michael StJohns <[email-masked]>
Date: Wed, 24 Sep 2008 18:04:52 -0400

If "intermediate validation to protect legacy stub resolvers" were deprecated, I'd agree with you.  (can we please huh huh can we deprecate it????) 

Since we're still touting the utility of having an intermediate make a decision about what it wants to send to a stub based on the intermediate's understanding of security, we need to pick a consistent understanding of that security.  (In other words, the application we're concerned with here is the stub side server of the validating resolver).

Mike

ps - anyone want to take a whack at documenting how various applications should handle various DNSSEC outcomes?  The ones I can think of off the top of my head that should be done are: SMTP (both submitter to MTA and MTA to MTA), HTTP (what the browser does *before* the user gets involved - pretty sure just exposing the DNSSEC resolution state isn't the best answer), SSH,  peer-to-peer.

At 06:21 AM 9/24/2008, Edward Lewis wrote:
>DNSSEC will allow the querier to know that it got some records and they are verified, it will also know that it got other records for which there is no ancillary protection information.  DNSSEC will not permit "protected" records to be spoofed (within the bounds of what it can do).
>
>So far as whether the "final answer" is right, that's an issue for applications.  The application would have to make the judgement whether it would accept the "chain" of DNAMEs and CNAMEs - or judge what the semantics of the proofs are.
>
>Perhaps a discussion of this belongs in the Security Considerations of DNSSEC bis.
>--

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Sep 2008 08:39:08 +1000

In message <[email-masked]>, Michael StJohns writes:
> If "intermediate validation to protect legacy stub resolvers" were deprecated,
>  I'd agree with you.  (can we please huh huh can we deprecate it????) 
> 
> Since we're still touting the utility of having an intermediate make a decisio
> n about what it wants to send to a stub based on the intermediate's understand
> ing of security, we need to pick a consistent understanding of that security. 
>  (In other words, the application we're concerned with here is the stub side s
> erver of the validating resolver).

	If any part fails to pass validation the client gets SERVFAIL
	after repeated attempts to get the answer.

	If it passes validation and the client doesn't ask for AD
	you just get the ordinary answer.

	If it passes validation and the client asks for AD (by
	setting DO or AD) you get the answer with AD set iff all
	of the RRsets in the answers and authority sections are
	proved secure otherwise you get the answer without AD set.

	Mark

> Mike
> 
> ps - anyone want to take a whack at documenting how various applications shoul
> d handle various DNSSEC outcomes?  The ones I can think of off the top of my h
> ead that should be done are: SMTP (both submitter to MTA and MTA to MTA), HTTP
>  (what the browser does *before* the user gets involved - pretty sure just exp
> osing the DNSSEC resolution state isn't the best answer), SSH,  peer-to-peer.
> 
> >DNSSEC will allow the querier to know that it got some records and they are v
> erified, it will also know that it got other records for which there is no anc
> illary protection information.  DNSSEC will not permit "protected" records to 
> be spoofed (within the bounds of what it can do).
> >
> >So far as whether the "final answer" is right, that's an issue for applicatio
> ns.  The application would have to make the judgement whether it would accept 
> the "chain" of DNAMEs and CNAMEs - or judge what the semantics of the proofs a
> re.
> >

---

From: John Dickinson <[email-masked]>
Date: Thu, 25 Sep 2008 10:16:09 +0100

> draft-ietf-dnsext-dnssec-rsasha256-05.txt

I have read this draft and support it progressing with the issues  
raised so far addressed.

A few minor typos:
throughout - the words "resource records" are followed by the acronym  
(RRs) multiple times.
2.1 - s/key size for RSA/SHA-256 keys MUST/size of keys used for RSA/ 
SHA-256 MUST/
2.2 - s/key size for RSA/SHA-512 keys MUST/size of keys used for RSA/ 
SHA-512 MUST/
3 - s/follow /uses /
the first line of 4.1 should say keys not signatures.

John

---

From: Florian Weimer <[email-masked]>
Date: Fri, 26 Sep 2008 18:33:13 +0200

> draft-ietf-dnsext-rfc2672bis-dname-14.txt 

I've read the draft and have got three minor nits:

DO necessarily implies UD because the synthesized CNAME is not signed
and thus not visible to a DNSSEC client (section 3.1).

The resolution algorithm in section 3.2 should be omitted because it
potentially conflicts with the wildcard-clarify work.

I'm not sure the advice in section 5.3.1 is entirely correct.  The gap
signalled by NSEC RRs does not necessarily lie completely below the
DNAME.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Sep 2008 07:03:30 +1000

In message <[email-masked]>, Florian Weimer writes:
> * Andrew Sullivan:
> 
> > draft-ietf-dnsext-rfc2672bis-dname-14.txt=20
> 

	DO indicates that you want the DNSSEC records.
	UD indicates that you don't want the synthesised CNAME.

	There are cases where you don't want DO to imply UD.
	Think humans reading the output.
 
	Mark