Re: [dnsext] Reminder: two WGLC closing in one week
Scott Rose
on that one.
I have previously expressed my support for the rsasha256 draft.
Scott
Andrew Sullivan wrote:
> 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)
>
--
----------------------------------------
Scott Rose Computer Scientist
NIST
ph: +1 301-975-8439
scott...@nist.gov
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Michael StJohns
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
At 08:45 PM 9/18/2008, Andrew Sullivan wrote:
>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
>a...@commandprompt.com
>+1 503 667 4564 x104
>http://www.commandprompt.com/
Mark Andrews
In message <E1KhqqB-...@psg.com>, 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: Mark_A...@isc.org
Edward Lewis
>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.
>What happens if the DNAME and the target are signed with different algorithm
>and the querier only understands one of they.
Same as answer #2. DNSSEC is protection from the querier's perspective.
>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.
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").
>Sorry - Mike
>
>
>
>At 08:45 PM 9/18/2008, Andrew Sullivan wrote:
>>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
>>a...@commandprompt.com
>>+1 503 667 4564 x104
>>http://www.commandprompt.com/
>>
>>--
>>to unsubscribe send a message to namedroppe...@ops.ietf.org with
>>the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://ops.ietf.org/lists/namedroppers/>
>
>
>
>--
>to unsubscribe send a message to namedroppe...@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
Michael StJohns
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.
At 08:16 PM 9/22/2008, Mark Andrews wrote:
>In message <E1KhqqB-...@psg.com>, 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: Mark_A...@isc.org
--
Mark Andrews
In message <2008092301243...@mx.isc.org>, Michael StJohns writes:
>
> 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 ask
> ing how this differs from CNAME - there are basically two types of CNAME - thos
> e with targets under the original trust anchor and those that aren't. The forme
> r 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 th
> is a correct treatment? Or just the treatment that's possible given the curren
> t 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 valid
> ates. Is the "result" secure, unsecure or some other state?
AD is not set by the validating recursive server as not all
components of the answer and authority sections validated
as secure.
> Original query is: "www.somewhere.example.com A" and we have a trust anchor fo
> r somewhere.example.com
> At somewhere.example.com is a DNAME into unsecure.com which is not signed or fo
> r 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?
Has no impact on the setting of AD. Unsecure is unsecure
regardless of whether the answer is what should be there
or not.
> Given that once a validator wanders in to an insecure zone, it can be steered w
> here 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 determi
> ning the security of the query response.
Correct. The entire chain needs to be secure for AD to be set.
Michael StJohns
Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for that matter) is your last conclusion stated as a specific protocol element? I just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to say this. The definition for "secure" in 4.3 only says to trace from the answer to a trust anchor. The definition for insecure *could* be read to say what you said, but then it would be in conflict with the definition for "secure".
I don't disagree with you about the output, but I do disagree that the result is obvious enough not to require specific documentation.
> Given that once a validator wanders in to an insecure zone, it can be steered w
> here 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 determi
> ning the security of the query response.
Correct. The entire chain needs to be secure for AD to be set.
Mark Andrews
In message <2008092302521...@mx.isc.org>, Michael StJohns writes:
> OK - so if the last chain validates, but the intermediate chain was unsecure, t
> hen you return the answer, but don't set the AD bit. If the last chain doesn't
> validate, you return what? The data without the AD bit, or RCODE 2/SERVFAIL?
SERVFAIL. If they ask with cd=1 then they get the full answer.
> (I.e.is it really possible to have data that's both bogus and unsecure?)
A particulare RRset is falls into exactly one of secure, insecure or
bogus post validation.
> Is t
> here any reason to do validation for the third chain in my example once you've
> wandered over into unsecure land?
Yes as you may be asked the later question.
> Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for
> that matter) is your last conclusion stated as a specific protocol element? I
> just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to sa
> y this. The definition for "secure" in 4.3 only says to trace from the answer
> to a trust anchor. The definition for insecure *could* be read to say what you
> said, but then it would be in conflict with the definition for "secure".
A security-aware name server MUST NOT set the AD bit in a response
unless the name server considers all RRsets in the Answer and
Authority sections of the response to be authentic. A security-aware
name server's local policy MAY consider data from an authoritative
zone to be authentic without further validation. However, the name
server MUST NOT do so unless the name server obtained the
authoritative zone via secure means (such as a secure zone transfer
mechanism) and MUST NOT do so unless this behavior has been
configured explicitly.
Mark
Michael StJohns
>In message <2008092302521...@mx.isc.org>, Michael StJohns writes:
>> OK - so if the last chain validates, but the intermediate chain was unsecure, t
>> hen you return the answer, but don't set the AD bit. If the last chain doesn't
>> validate, you return what? The data without the AD bit, or RCODE 2/SERVFAIL?
>
> SERVFAIL. If they ask with cd=1 then they get the full answer.
>
>> (I.e.is it really possible to have data that's both bogus and unsecure?)
>
> A particulare RRset is falls into exactly one of secure, insecure or
> bogus post validation.
Right, but the answer is a mixture of three RRSets - one secure, one unknown and one bogus... which I guess makes the whole thing bogus and results in the return of RCODE 2.
>> Is t
>> here any reason to do validation for the third chain in my example once you've
>> wandered over into unsecure land?
>
> Yes as you may be asked the later question.
Fair enough.
>> Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for
>> that matter) is your last conclusion stated as a specific protocol element? I
>> just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to sa
>> y this. The definition for "secure" in 4.3 only says to trace from the answer
>> to a trust anchor. The definition for insecure *could* be read to say what you
>> said, but then it would be in conflict with the definition for "secure".
>
> A security-aware name server MUST NOT set the AD bit in a response
> unless the name server considers all RRsets in the Answer and
> Authority sections of the response to be authentic.
OK. I can go along with this reading - but I think I'm still not quite done.
So the last question is what goes on when you have the same three queries - except the last one now validates, and the DO bit wasn't set from the stub resolver? (e.g, I won't understand the lack of AD bit)
The simple answer would be to return the three RRSets - but is that the right approach or only one of several correct approaches?
I could argue the paranoids point, that once the answer becomes secure, unless it becomes securely unsecure (by proving there's no DS at a delegation point), then the final answer must either be secure or bogus. In other words, if I get a referral via a CNAME or DNAME into unsecure space, then the final answer should be "bogus".
The above is different than the secure delegation to an unsecure zone: The signed delegation to an unsigned zone is controllable by the delegator. The signed CNAME or DNAME referral to an zone carries no information about whether the referrer/signer believes the target zone/name should be signed.
I'm trying to reconcile this with the general policies on how data is returned from a validating recursive resolver to a non-DNSSEC aware stub resolver. The VRR returns an RCODE 2 for any data below a trust anchor it can't validate (bogus), and returns the data which has no superior trust anchor (unknown), returns the data it was able to validate (secure), and returns the data which was below an unsecure delegation point (unsecure).
I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone from a secure zone is equivalent to an unsecure delegation from that secure zone to a subsidiary, because the target of the DNAME/CNAME can change the DNSSEC status at any time after the CNAME/DNAME is published. Unfortunately, I can't see any way of encoding the DNAME/CNAME signers expectation of security for the target zone in the current definitions.
So if I follow the principal of "if it started out secure and I can't prove it was meant to be unsecure then it should be bogus if I can't validate it" which we follow for on-tree delegations, shouldn't I follow it for off-tree delegations?
Mike
Mark Andrews
You return the answer.
> The simple answer would be to return the three RRSets - but is that the right a
> pproach or only one of several correct approaches?
>
> I could argue the paranoids point, that once the answer becomes secure, unless
> it becomes securely unsecure (by proving there's no DS at a delegation point),
> then the final answer must either be secure or bogus. In other words, if I get
> a referral via a CNAME or DNAME into unsecure space, then the final answer sho
> uld be "bogus".
No. Everything that is not at or below a TA is deemed to
be insecure.
> The above is different than the secure delegation to an unsecure zone: The sig
> ned delegation to an unsigned zone is controllable by the delegator. The signe
> d CNAME or DNAME referral to an zone carries no information about whether the r
> eferrer/signer believes the target zone/name should be signed.
>
> I'm trying to reconcile this with the general policies on how data is returned
> from a validating recursive resolver to a non-DNSSEC aware stub resolver. The
> VRR returns an RCODE 2 for any data below a trust anchor it can't validate (bog
> us), and returns the data which has no superior trust anchor (unknown),
No, it is NOT unkown. It is insecure. You are attempting to introduce
a state which does not exist.
secure -> passes validation
insecure -> no TA or there is a insecure delegation from a secure zone.
bogus -> fails validation
> returns
> the data it was able to validate (secure), and returns the data which was belo
> w an unsecure delegation point (unsecure).
>
> I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone fr
> om a secure zone is equivalent to an unsecure delegation from that secure zone
> to a subsidiary, because the target of the DNAME/CNAME can change the DNSSEC st
> atus at any time after the CNAME/DNAME is published. Unfortunately, I can't se
> e any way of encoding the DNAME/CNAME signers expectation of security for the t
> arget zone in the current definitions.
Each QNAME when following a CNAME chain is independently
validated. When you return the final answer you look at
all the components to determine whether the final answer
is secure (AD could be set if requested) or not.
> So if I follow the principal of "if it started out secure and I can't prove it
> was meant to be unsecure then it should be bogus if I can't validate it" which
> we follow for on-tree delegations, shouldn't I follow it for off-tree delegatio
> ns?
Except you can validate that it is insecure.
Mark
> Mike
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Michael StJohns
Content-Type: text/plain; charset="us-ascii"
At 02:18 AM 9/23/2008, Mark Andrews wrote:
> No, it is NOT unkown. It is insecure. You are attempting to introduce
> a state which does not exist.
>
> secure -> passes validation
> insecure -> no TA or there is a insecure delegation from a secure zone.
> bogus -> fails validation
From 4035...
Secure: An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed and is subject to
signature validation, as described above.
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
Arends, et al. Standards Track [Page 20]
RFC 4035 DNSSEC Protocol Modifications March 2005
Bogus: An RRset for which the resolver believes that it ought to be
able to establish a chain of trust but for which it is unable to
do so, either due to signatures that for some reason fail to
validate or due to missing data that the relevant DNSSEC RRs
indicate should be present. This case may indicate an attack but
may also indicate a configuration error or some form of data
corruption.
Indeterminate: An RRset for which the resolver is not able to
determine whether the RRset should be signed, as the resolver is
not able to obtain the necessary DNSSEC RRs. This can occur when
the security-aware resolver is not able to contact security-aware
name servers for the relevant zones.
--=====================_638747484==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
At 02:18 AM 9/23/2008, Mark Andrews wrote:<br>
<blockquote type=cite class=cite cite="">
No, it is NOT unkown. It
is insecure. You are attempting to introduce<br>
<x-tab> </x-tab>a state
which does not exist.<br><br>
<x-tab> </x-tab>secure
-> passes validation<br>
<x-tab> </x-tab>insecure
-> no TA or there is a insecure delegation from a secure zone.<br>
<x-tab> </x-tab>bogus
-> fails validation</blockquote><br>
From 4035...<br><br>
<pre> Secure: An RRset for which the resolver is able to
build a chain of
signed DNSKEY and DS RRs from a trusted
security anchor to the
RRset. In this case, the RRset
should be signed and is subject to
signature validation, as described above.
Insecure: An RRset for which the resolver knows that it has
no chain
of signed DNSKEY and DS RRs from any
trusted starting point to the
RRset. This can occur when the
target RRset lies in an unsigned
zone or in a descendent of an unsigned
zone. In this case, the
RRset may or may not be signed, but the
resolver will not be able
to verify the signature.
Arends, et
al.
Standards
Track
[Page 20]
RFC
4035
DNSSEC Protocol
Modifications
March 2005
Bogus: An RRset for which the resolver believes that it
ought to be
able to establish a chain of trust but for
which it is unable to
do so, either due to signatures that for
some reason fail to
validate or due to missing data that the
relevant DNSSEC RRs
indicate should be present. This
case may indicate an attack but
may also indicate a configuration error or
some form of data
corruption.
Indeterminate: An RRset for which the resolver is not able
to
determine whether the RRset should be
signed, as the resolver is
not able to obtain the necessary DNSSEC
RRs. This can occur when
the security-aware resolver is not able to
contact security-aware
name servers for the relevant zones.
</body>
<br>
</html>
--=====================_638747484==.ALT--
Mark Andrews
In message <2008092307235...@mx.isc.org>, Michael StJohns writes:
> --=====================_638747484==.ALT
> Content-Type: text/plain; charset="us-ascii"
>
> At 02:18 AM 9/23/2008, Mark Andrews wrote:
> > No, it is NOT unkown. It is insecure. You are attempting to introd
> uce
> > a state which does not exist.
> >
> > secure -> passes validation
> > insecure -> no TA or there is a insecure delegation from a secure zo
> ne.
> > bogus -> fails validation
>
> From 4035...
>
> Secure: An RRset for which the resolver is able to build a chain of
> signed DNSKEY and DS RRs from a trusted security anchor to the
> RRset. In this case, the RRset should be signed and is subject to
> signature validation, as described above.
>
> Insecure: An RRset for which the resolver knows that it has no chain
> of signed DNSKEY and DS RRs from any trusted starting point to the
> RRset. This can occur when the target RRset lies in an unsigned
> zone or in a descendent of an unsigned zone. In this case, the
> RRset may or may not be signed, but the resolver will not be able
> to verify the signature.
If there is no trust anchor then the answer is insecure.
"The resolver knows that it has no chain of signed DNSKEY
and DS RRs from any trusted starting point to the RRset."
> Bogus: An RRset for which the resolver believes that it ought to be
> able to establish a chain of trust but for which it is unable to
> do so, either due to signatures that for some reason fail to
> validate or due to missing data that the relevant DNSSEC RRs
> indicate should be present. This case may indicate an attack but
> may also indicate a configuration error or some form of data
> corruption.
>
> Indeterminate: An RRset for which the resolver is not able to
> determine whether the RRset should be signed, as the resolver is
> not able to obtain the necessary DNSSEC RRs. This can occur when
> the security-aware resolver is not able to contact security-aware
> name servers for the relevant zones.
Which is *not* what you were calling unknown.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Michael StJohns
At 02:18 AM 9/23/2008, Mark Andrews wrote:
>>
>> So the last question is what goes on when you have the same three queries - exc
>> ept the last one now validates, and the DO bit wasn't set from the stub resolve
>> r? (e.g, I won't understand the lack of AD bit)
>
> You return the answer.
>
>> The simple answer would be to return the three RRSets - but is that the right a
>> pproach or only one of several correct approaches?
>>
>> I could argue the paranoids point, that once the answer becomes secure, unless
>> it becomes securely unsecure (by proving there's no DS at a delegation point),
>> then the final answer must either be secure or bogus. In other words, if I get
>> a referral via a CNAME or DNAME into unsecure space, then the final answer sho
>> uld be "bogus".
>
> No. Everything that is not at or below a TA is deemed to
> be insecure.
Actually, there is a pretty large difference in considering security between:
Insecure: Someone I trusted told me that data doesn't need to be signed (e.g. secure delegation to an unsecure zone)
and
Unknown: I have no idea whether or not that data should be secure - it's not under a trust anchor *I KNOW ABOUT* - and because of that I can't make useful statement about its actual security.
>> The above is different than the secure delegation to an unsecure zone: The sig
>> ned delegation to an unsigned zone is controllable by the delegator. The signe
>> d CNAME or DNAME referral to an zone carries no information about whether the r
>> eferrer/signer believes the target zone/name should be signed.
>>
>> I'm trying to reconcile this with the general policies on how data is returned
>> from a validating recursive resolver to a non-DNSSEC aware stub resolver. The
>> VRR returns an RCODE 2 for any data below a trust anchor it can't validate (bog
>> us), and returns the data which has no superior trust anchor (unknown),
>
> No, it is NOT unkown. It is insecure. You are attempting to introduce
> a state which does not exist.
>
> secure -> passes validation
> insecure -> no TA or there is a insecure delegation from a secure zone.
> bogus -> fails validation
yeah - we've had this discussion a number of times. If I have no basis on which to make a security determination, it is indeterminate or unknown. In VRR procesing, that generally means the data is passed along with the AD bit off which is no different than the result for insecure data. The fact the end result is identical from the POV of the querier does not mean the trust states are identical.
With respect to the current problem:
If the middle chain is insecure (e.g. I did CNAME/DNAME into a zone below I trust anchor the VRR has, but that is below a secure unsecure delegation), is this more trustworthy than if the middle chain resolved to an RRSet that had no superior trust anchor?
Again, paranoid's argument suggests that I might consider the former a non-bogus answer and the latter a bogus answer given general DNSSEC principles.
>> returns
>> the data it was able to validate (secure), and returns the data which was belo
>> w an unsecure delegation point (unsecure).
>>
>> I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone fr
>> om a secure zone is equivalent to an unsecure delegation from that secure zone
>> to a subsidiary, because the target of the DNAME/CNAME can change the DNSSEC st
>> atus at any time after the CNAME/DNAME is published. Unfortunately, I can't se
>> e any way of encoding the DNAME/CNAME signers expectation of security for the t
>> arget zone in the current definitions.
>
> Each QNAME when following a CNAME chain is independently
> validated. When you return the final answer you look at
> all the components to determine whether the final answer
> is secure (AD could be set if requested) or not.
Agreed, but the current argument is whether or not there is a meta policy that needs to be applied and not just a min() of all of the independent chain results. What you're identifying is the obvious, but possibly incorrect/insecure approach.
>
>> So if I follow the principal of "if it started out secure and I can't prove it
>> was meant to be unsecure then it should be bogus if I can't validate it" which
>> we follow for on-tree delegations, shouldn't I follow it for off-tree delegatio
>> ns?
>
> Except you can validate that it is insecure.
Actually, you can't. If the middle chain is not under a trust anchor (or rather if the resolver holds no trust anchor) no validation is possible and an attacker can literally do whatever he wants with the result data. And the fact of the AD bit being set or not is mostly irrelevant - the end system is still going to see the data. If the middle chain IS under a trust anchor - there has to be an unsecure delegation for an attacker to get traction.
The more I think about this, the more I begin to believe that for consistency, if you start under a trust anchor, you better be able to end under a trust anchor and that all chains must be able to be validated/authenticated UNLESS you find an unsecure delegation along the way. Otherwise you get this weird state where the originator of the data thought he was doing the right thing (a secure DNAME referral into a secure zone), but that the resolver could find itself returning data that was actually bogus (because it was lacking a trust anchor for the referred zone and an attacker got to it).
The tradeoff here is that doing it this way makes the combination of DNSSEC and DNAME or off-tree CNAME less useful. But what's the right answer from a security perspective? Do we address this by forcing a resolver behavior, or simply by noting the security issues with off-tree DNAME/CNAME referrals?
I obviously don't think the simple answer is as correct as you think it is. That's a matter of opinion and the one for discussion.
Mike
Mark Andrews
As far as your validator is concerned it *is* to treat the
data as insecure. This is what RFC 4035 says to do with
it. There are no "if", "maybe" or "what if". This is
clearly stated.
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
If a name is not under a TA then the first sentence is met.
The second and subsequent sentences give the non trivial
example of when the first sentence can be met. It's not
"This will occur", it's "This can occur" and "In this case".
Perhaps we should have split this into two paragraphs and
as you have failed to see the trivial case add it.
Insecure: An RRset for which the resolver knows that it has no chain
of signed DNSKEY and DS RRs from any trusted starting point to the
RRset.
This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able
to verify the signature. Alternatively this can occur when there
is no trusted starting point at or above the name.
The only time a record is unknown is prior to attempting
to validate or when you can't reach the servers to get the
DNSKEY/DS in the chain that would allow you to validate.
Indeterminate: An RRset for which the resolver is not able to
determine whether the RRset should be signed, as the resolver is
not able to obtain the necessary DNSSEC RRs. This can occur when
the security-aware resolver is not able to contact security-aware
name servers for the relevant zones.
You can ALWAYS reach you TA's as they are part of the
validator's configuration. Therefore you can ALWAYS validate
data which is not under a TA. That validation ALWAYS returns
insecure.
If you use DLV then you need to check with the DLV registry
to detemine if the name is secure or not. I have exactly
the reverse arguement when someone complained that we should
be returning insecure when the DLV lookup timed out. With
DLV you have to prove that the name is not covered by a DLV
record.
However if you still have a island that is not covered by
either a TA or a DLV record then the records are insecure.
Go read the definition of INSECURE in RFC4035.
Name not under TA => INSECURE.
> The more I think about this, the more I begin to believe that for consistency,
> if you start under a trust anchor, you better be able to end under a trust an
> chor and that all chains must be able to be validated/authenticated UNLESS you
> find an unsecure delegation along the way. Otherwise you get this weird st
> ate where the originator of the data thought he was doing the right thing (a s
> ecure DNAME referral into a secure zone), but that the resolver could find its
> elf returning data that was actually bogus (because it was lacking a trust anc
> hor for the referred zone and an attacker got to it).
>
> The tradeoff here is that doing it this way makes the combination of DNSSEC an
> d DNAME or off-tree CNAME less useful. But what's the right answer from a sec
> urity perspective? Do we address this by forcing a resolver behavior, or simp
> ly by noting the security issues with off-tree DNAME/CNAME referrals?
>
> I obviously don't think the simple answer is as correct as you think it is. T
> hat's a matter of opinion and the one for discussion.
>
> Mike
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Edward Lewis
>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?
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
Never confuse activity with progress. Activity pays more.
--
Michael StJohns
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.
Mark Andrews
In message <E1KicTm-...@psg.com>, 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Florian Weimer
> draft-ietf-dnsext-rfc2672bis-dname-14.txt=20
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.
--=20
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Edward Lewis
>If "intermediate validation to protect legacy stub resolvers" were deprecated,
>I'd agree with you. (can we please huh huh can we deprecate it????)
If we deprecate that, what's the point of DNSSEC? DNSSEC is designed
to stem cache poisoning, so that caches don't give out answers they
can't verify to their clients. The client to cache is protected by
TSIG, TKEY, IPSEC, or maybe just crossing one's fingers and hoping
for the link to be secure. (Legacy has to count on the latter -
assuming legacy is pre-TSIG et.al.)
>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).
Or we make use of the CD bit. In early workshops (about 10 years ago
I mean) we ran into the problem that not all computers agreed on the
current time. (NTP wasn't as widespread as it is now.) The way
around that at the time was to use the CD bit and get the answer as
it passed through from the source.
>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.
DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e.,
protect the admission of DNS data to the cache. It wasn't meant to
protect the applications making use of the data. If an application
wants to act like a cache with a verifier, fine. Then it asks for
everything with CD, gets as much raw data, and does it's own check.
If it can't reach the source (because of firewalls, forwarders,
etc.,), well it's up a creek anyway.
To an application - either their is an answer in DNS or not. The
grey area is too hard to make use of, a general solution isn't
useful. It's like with lame delegation testing in the reverse map.
There are a lot of screw ups there, a lot follow certain pathologies
that, even common, make up a small percentage of the total problems.
It isn't worth trying to diagnose for the few predictable
misconfigurations.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Michael StJohns
>Edward Lewis wrote:
>>> 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.
>>
>> DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e.,
>> protect the admission of DNS data to the cache. It wasn't meant to
>> protect the applications making use of the data. If an application
>> wants to act like a cache with a verifier, fine. Then it asks for
>> everything with CD, gets as much raw data, and does it's own check. If
>> it can't reach the source (because of firewalls, forwarders, etc.,),
>> well it's up a creek anyway.
>>
>> To an application - either their is an answer in DNS or not. The grey
>> area is too hard to make use of, a general solution isn't useful. It's
>> like with lame delegation testing in the reverse map. There are a lot of
>> screw ups there, a lot follow certain pathologies that, even common,
>> make up a small percentage of the total problems. It isn't worth trying
>> to diagnose for the few predictable misconfigurations.
>
>
>1. RR exists and here it is.
>2. RR does not exist.
>3. Server not reachable (or otherwise broken).
>
>to
>
>1. RR exists and here it is.
>2. RR does not exist.
>3. RR exists but is broken in some way.
>4. Server not reachable (or otherwise broken).
I don't think its this simple... really.
Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate".
DNSSEC add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states:
1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure.
2. Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid.
3. Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer.
4. Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc.
5. Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust.
Those three DNS states matrix (somewhat) with the 5 security states to actually give you 15 distinct intersections - but a number of those substates collapse into each other. (E.g., secure/exist, secure/non-exist, bogus/exist, bogus/non-exist, any/indeterminate, unsecure/any, unknown/any). You might also consider that DNSSEC extends the original 3 dns resolution states to 4 by adding a "data determinate/dnssec indeterminate" - but those may collapse mostly into the bogus entries.
I'm not trying to be difficult here - but considering each of these intersections and figuring out what to do for each application seems to be a reasonable approach.
Taking specifically email MTA-MTA interactions. It seems to me that you'd treat (secure | unsecure | indeterminate)/exist as states where you'd allow the MTA to connect and deliver, that you'd treat bogus/any as a reportable security error condition and not deliver (- but would you retry?), that you'd treat any/indeterminate as a retry error condition (e.g. temporary failure), and that you'd treat secure/non-exist as a permanent mail delivery failure. What would you do with unknown/non-exist - would you treat as a permanent failure or retry after a long or short interval?
Going back to the DNAME/CNAME stuff - DNSSEC provides a mechanism to indicate to a resolver securely that a chain of trust is being turned off (is ending securely?) (secure delegation to an unsecure zone). CNAME and DNAME do not have any way of indicating the expected security state of the zone to which they point. It seems to me that an application might actually care about this when trying to figure out what to do. Let's pretend for a moment that DNAME has a way of indicating its target status as one of either - must be secure, or don't care. If the must be secure bit is set and the target can't be validated (either as secure or as delegated to unsecure), then the answer for the whole chain is bogus. If the bit isn't set, then security resolution for the target restarts with the target - e.g. if the target is under a trust anchor then it must validate or the chain is bogus. Obviously, this bit doesn't exist - should it?
And finishing up with MTA-MTA - if I use the current model and have a lookup chain to a DNAME that validates, but that the target of the DNAME isn't under a trust anchor - should I deliver the mail? If so, why? If not, why?
What do I do if the MX look up is secure, but the A lookup is unsecure or unknown? Vice versa?
What markings if any should go on an email (header notation) to indicate a forwarding routing was based on data with an "unsecure" or "unknown" trust state? or if the MX was secure and the A wasn't or vice versa?
Should a downstream receiver do anything special for messages marked as above? Would this ever be a reasonable filtering criteria?
>The question is: what should applications do for state 3? My answer
>would be to treat it like state 4, I think, but there's room for debate.
>
>Cheers,
>
>Ben.
>
>--
>http://www.apache-ssl.org/ben.html http://www.links.org/
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff
Alex Bligh
--On 13 October 2008 14:16:52 +0200 Wouter Wijngaards <wou...@NLnetLabs.nl>
wrote:
> I think it is much simpler than that. The application is interested in
> what is known with certainty.
> 1. It is certain the data is valid (secure)
> 2. It is certain that security checks failed (bogus)
> 3. whatever (insecure).
One of the merits of Ben's list was it attempted to list the states "as
a user might see them" without associating them in the first instance
to the workings and terminology of the protocol.
>From the user's point of view, I think you (and, I think Ben) have missed
at least one. Using your numbering above here is what a DNSSEC aware
application might find when looking up the name:
1. We have data, which we know is correct & secure (DNSSEC signatures
verify)
2. We have data, which we know is invalid (DNSSEC shows insecure)
3. We have data, but we are uncertain as to the correctness of the
data (e.g. no DNSSEC information for that zone, or missing DLV
or whatever).
4. We have no data, e.g. we got a SERVFAIL. As I understand, we can't
tell this is secure or not (willing to be corrected here).
Non-DNSSEC-aware resolver stacks return (3) or (4).
As far as I can tell, treating (2) like (4) at the application layer
seems sensible (i.e. I can't see any/many applications distinguishing) (*).
However, an application might handle (1), (3) and [(2)/(4)] at least
as different states (even if only colouring a browser address bar
yet another shade of the rainbow). Compatibility reasons suggest
that legacy applications (non-DNSSEC aware) get to treat (1) and (3)
the same, or every such application will fail when a DNSSEC compliant
library is installed. Given evidence to date suggests adoption of
DNSSEC will be non-instantaneous, this seems mandatory.
(*) interesting nit: state 2 includes secure denial of existence. I am
arguing here secure denial of existence gets treated at the application
layer just like an insecure failure in every circumstance I can think
of. IE, you can spoof a SERVFAIL, DoS the resolver so it times out,
or whatever and it will be treated the same way as a guaranteed denial
of existence through NSEC/NSEC3 at the application layer. I know there
are people who think that maintaining the difference between an
authenticated denial and a failure is useful for more than debugging
purposes, or we wouldn't have spent so long ensuring NSEC's successor
maintained authenticated denial of existence. This implies that they
must see a need for (2) and (4) to be different.
Alex
Edward Lewis
>...CNAME and DNAME do not have any way of indicating the expected security
>state of the zone to which they point. ...
Yes they do. For X CNAME Y, you can determine the security state of
X by flowing down from the root and you can tell the security state
of Y by flowing down from the root. Just as X is not "delegating" to
Y in the sense of NS's, X is not transferring any security state to
Y. X is simply referring to Y. Ditto if this is a DNAME situation.
. (assume a "signed" root)
------/ | \------
/ | \
S S S (S=secure zone)
| | |
S S S
| | |
S U S (U=insecure zone)
| | |
X CNAME Y DNAME Z
|
W
In this case, X has a secured reference to Y. Y isn't protected and
has a rewrite rule to Z. Z is secured. You see from inspection from
a (signed) root down that there is no break in the chain to X and Z,
but there is the break to Y.
DNSSEC is protecting the querier in that you get to validate what you
can (where there is data). But does that help the application? Not
really. This is why I think DNSSEC is there just to benefit the DNS,
not the application.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Alex Bligh
--On 13 October 2008 14:47:28 +0100 Ben Laurie <b...@links.org> wrote:
> If I am delivering mail, and the domain does not exist, I bounce it. If
> I get SERVFAIL, I hold on to it and try again later.
Ah yes. Agreed. So that makes the states:
1. We have data, which we know is correct & secure (DNSSEC signatures
verify)
2. We have data, which we know is invalid (DNSSEC signature failure)
3. We have data, but we are uncertain as to the correctness of the
data (e.g. no DNSSEC information for that zone, or missing DLV
or whatever).
4. We have a failure, e.g. we got a SERVFAIL. As I understand, we can't
tell this is secure or not (willing to be corrected here).
5. We have no data, and the absence of data is correctly authenticated
(e.g. by NSEC/NSEC3)
6. We have no data, but the response is invalid (DNS signature failure
on NSEC/NSEC3 proof of denial of existence)
7. We have no data, but we are uncertain as to its correctness (e.g.
NXDOMAIN in vanilla DNS)
I think 2 and 4 in the above are (at an application layer) the same,
in that if I spoof by sending bogus answers, that should result in
the same action as DoS and timeout, or spoofing SERVFAIL or whatever.
That would suggest treating 6 the same as these two as well.
By the same logic that a non-DNSSEC-aware application should treat
1 and 3 the same, it should treat 5 and 7 the same I presume.
Alex
Edward Lewis
>1. We have data, which we know is correct & secure (DNSSEC signatures
> verify)
>3. We have data, but we are uncertain as to the correctness of the
> data (e.g. no DNSSEC information for that zone, or missing DLV
> or whatever).
DNSSEC says nothing about "correctness." If the IP address is typed
wrong by the zone admin, DNSSEC will sign the result.
"Missing DLV" is something that cannot be diagnosed from the packet
arriving on port 53. If you have no trust anchor for a name and you
get signed data owned by that name, it is indistinguishable whether
the name has a key and you don't know it ("missing DLV") versus
someone inserting falsely signed data just so you deduce it is
missing.
DNSSEC only says "this answer looks good" or "doesn't look good."
Trying to figure out whether the answer's disposition is
temporary/permanent, correct/incorrect, trustworthy/not takes more
than just the DNS data and more than just the query at hand.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Alex Bligh
--On 13 October 2008 10:57:30 -0400 Edward Lewis <Ed.L...@neustar.biz>
wrote:
> DNSSEC says nothing about "correctness." If the IP address is typed wrong
> by the zone admin, DNSSEC will sign the result.
Sorry - I was using 'correct' as a term without any prior terminological
commitments to mean "not only is there data but it is signed but all the
signatures match" (I believe this corresponds to DNSSEC's 'secure' status
but that also covers for instance secure denial).
> "Missing DLV" is something that cannot be diagnosed from the packet
> arriving on port 53. If you have no trust anchor for a name and you get
> signed data owned by that name, it is indistinguishable whether the name
> has a key and you don't know it ("missing DLV") versus someone inserting
> falsely signed data just so you deduce it is missing.
My point was that it is (I think) possible to distinguish between faults
where a resolver cannot verify a signature presented (e.g. signature
added promiscuously to signed data, no trust anchor found) and where
the signature doesn't match the data (e.g. data tampered with on the
wire).
In the former case (number 3 in my email), it seems to me one
doesn't know whether the signature is added as some form of attempted
attack (where one might think one should trust the data less) or whether
one just doesn't have the right trust anchors configured (where one
might think one should just treat the data as if it weren't signed
at all), so treating the data as if it were unsigned (the rest of
my case 3) seems fine.
In the latter class of errors, there is no proper explanation for that,
and best ignore the data entirely.
> DNSSEC only says "this answer looks good" or "doesn't look good." Trying
> to figure out whether the answer's disposition is temporary/permanent,
> correct/incorrect, trustworthy/not takes more than just the DNS data and
> more than just the query at hand.
I was under the misapprehension that this was precisely what this thread
was concerned with! DNSSEC doesn't only say the answer looks good, or
does not look good. It also occasionally fails entirely (e.g. SERVFAIL).
Further, a DNSSEC aware resolver will also occasionally give results
found through vanilla (non-DNSSEC) DNS. That, plus there is clearly a
differentiation between results and no results for a DNSSEC aware
version of (e.g.) gethostbyname.
Alex
Michael StJohns
>Michael StJohns wrote:
>>> missing keys, etc. 5. Insecure transition from secure - I've got
>> valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME
>> point into an area of the tree with Unknown trust.
>
>1? (Oh, I do now, having read below more carefully)
>
>But you do have a point.
Yup. More on this in my response to Ed's note which follows.
>> Those three DNS states matrix (somewhat) with the 5 security states
>> to actually give you 15 distinct intersections - but a number of
>> those substates collapse into each other. (E.g., secure/exist,
>> secure/non-exist, bogus/exist, bogus/non-exist, any/indeterminate,
>> unsecure/any, unknown/any). You might also consider that DNSSEC
>> extends the original 3 dns resolution states to 4 by adding a "data
>> determinate/dnssec indeterminate" - but those may collapse mostly
>> into the bogus entries.
>
>We should actually figure out what all the distinct states are, rather
>than handwave.
That's really all I'm saying. If we want DNSSEC to be useful at the application level we need to do something like this.
>> I'm not trying to be difficult here - but considering each of these
>> intersections and figuring out what to do for each application seems
>> to be a reasonable approach.
>>
>> Taking specifically email MTA-MTA interactions. It seems to me that
>> you'd treat (secure | unsecure | indeterminate)/exist as states where
>> you'd allow the MTA to connect and deliver, that you'd treat
>> bogus/any as a reportable security error condition and not deliver (-
>> but would you retry?), that you'd treat any/indeterminate as a retry
>> error condition (e.g. temporary failure), and that you'd treat
>> secure/non-exist as a permanent mail delivery failure. What would
>> you do with unknown/non-exist - would you treat as a permanent
>> failure or retry after a long or short interval?
>
>As with many security decisions, this would depend on requirements. I
>can imagine running an MTA in an environment that only wants to trust
>DNSSEC (or in a mythical future where everything is IPv6, sorry, I mean
>DNSSEC), and so configuring this to "retry but eventually fail" in the
>usual way.
>
>For most people transitioning to DNSSEC, then I'd treat this as a
>permanent failure.
Right. That's probably a reasonable approach... now to get it standardized... :-)
>>
>> Going back to the DNAME/CNAME stuff - DNSSEC provides a mechanism to
>> indicate to a resolver securely that a chain of trust is being turned
>> off (is ending securely?) (secure delegation to an unsecure zone).
>> CNAME and DNAME do not have any way of indicating the expected
>> security state of the zone to which they point. It seems to me that
>> an application might actually care about this when trying to figure
>> out what to do. Let's pretend for a moment that DNAME has a way of
>> indicating its target status as one of either - must be secure, or
>> don't care. If the must be secure bit is set and the target can't be
>> validated (either as secure or as delegated to unsecure), then the
>> answer for the whole chain is bogus. If the bit isn't set, then
>> security resolution for the target restarts with the target - e.g. if
>> the target is under a trust anchor then it must validate or the chain
>> is bogus. Obviously, this bit doesn't exist - should it?
>
>Interesting question. Perhaps it should.
>
>> And finishing up with MTA-MTA - if I use the current model and have a
>> lookup chain to a DNAME that validates, but that the target of the
>> DNAME isn't under a trust anchor - should I deliver the mail? If so,
>> why? If not, why?
>>
>> What do I do if the MX look up is secure, but the A lookup is
>> unsecure or unknown? Vice versa?
>>
>> What markings if any should go on an email (header notation) to
>> indicate a forwarding routing was based on data with an "unsecure" or
>> "unknown" trust state? or if the MX was secure and the A wasn't or
>> vice versa?
>
>Routing headers aren't very rigidly defined now, so this seems orthogonal.
Each hop in email routing adds a Received-From line. Would it make sense to tag that line in some manner or to add a different element related to DNSSEC? Not saying that we should or not - but that the discussion is part of DNSSEC plus MTA-MTA handling standardization.
Mike
>> Should a downstream receiver do anything special for messages marked
>> as above? Would this ever be a reasonable filtering criteria?
>>
>>
>>
>>> The question is: what should applications do for state 3? My answer
>>> would be to treat it like state 4, I think, but there's room for
>>> debate.
>>>
>>> Cheers,
>>>
>>> Ben.
>>>
>>> -- http://www.apache-ssl.org/ben.html
>>> http://www.links.org/
>>>
>>> "There is no limit to what a man can do or how far he can go if he
>>> doesn't mind who gets the credit." - Robert Woodruff
>>
>>
>>
>
>
>--
>http://www.apache-ssl.org/ben.html http://www.links.org/
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff
--
Michael StJohns
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Michael,
>
>I think it is much simpler than that. The application is interested in
>what is known with certainty.
>1. It is certain the data is valid (secure)
>2. It is certain that security checks failed (bogus)
>3. whatever (insecure).
>
>accurately, 'no security available').
This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn't quite get all the states covered.
>A mail application could deliver 1 and 3, but not 2(bogus). Or it might
>examine the AD bit on replies and only deliver 1.
>
>When a DNAME or CNAME chain crosses a BOGUS entry, the DNAME or CNAME
>chain result is bogus. When a DNAME or CNAME chain has all items secure,
>the DNAME or CNAME chain result is secure. All other cases are insecure
>(i.e. the chain has one insecure element and the other elements are
>insecure or secure).
>
>I do not think a 'must be secure' bit is needed. Only when all items in
>the chain are secure is the result secure, and does the AD bit get set.
The AD bit gets set (or not) when you return data from a recursive nameserver, but that doesn't really describe how an application doing its own DNSSEC validation should handle this type of data.
It may be that your approach of if anything is bogus its all bogus, else if everything is secure its all secure, else its unsecure is correct. BUT - this seems at odds with the general DNSSEC contract that says we don't transition to an unsecure state unless we do it securely. If I'm the zone owner of the zone with the DNAME, and I'd doing a reference to another zone that - at the time I did the delegation - I knew to be secure, shouldn't I expect that DNSSEC should flag it if someone tries to resolve this and finds an unsecure zone? Again if not, why not? And why isn't this as much of a downgrade attack as all the other various schemes that have been described to me?
Mike
>Best regards,
> Wouter
>
>Michael StJohns wrote:
>> At 01:36 AM 10/13/2008, Ben Laurie wrote:
>>> 1. RR exists and here it is.
>>> 2. RR does not exist.
>>> 3. Server not reachable (or otherwise broken).
>>>
>>> to
>>>
>>> 1. RR exists and here it is.
>>> 2. RR does not exist.
>>> 3. RR exists but is broken in some way.
>>> 4. Server not reachable (or otherwise broken).
>>
>> I don't think its this simple... really.
>>
>> Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate".
>>
>> DNSSEC add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states:
>>
>> 1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure.
>> 2. Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid.
>> 3. Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer.
>> 4. Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc.
>> 5. Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust.
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>
>iEYEARECAAYFAkjzPDQACgkQkDLqNwOhpPg4hgCfZJrXXhwSeXgeZiU9W4FZ5Wwi
>O84AoKnIBWKPbaVGzxeCueQWk5L0WslT
>=tjtc
>-----END PGP SIGNATURE-----
Michael StJohns
Hi Ed -
I agree that you can determine the security state of X and the security state of Y by examining trust anchors, dlv etc. But that's not the question. The question is "What is the security state of the compound answer XY?"
From Marc Andrew's and somewhat from Wouter's email, it could be a new state "unauthenticated" - because the response out of an intermediate resolver is to return the data but not set the AD bit. I say new, because it's different than unknown, secure, and bogus and wouldn't be returned for the same reasons that you would return it for unsecure data under a single trust anchor. But even that begs the question of what an application should do with it.
Later, Mike
At 09:45 AM 10/13/2008, Edward Lewis wrote:
>At 7:38 -0400 10/13/08, Michael StJohns wrote:
>
>>...CNAME and DNAME do not have any way of indicating the expected security
>>state of the zone to which they point. ...
>
>Yes they do. For X CNAME Y, you can determine the security state of X by flowing down from the root and you can tell the security state of Y by flowing down from the root. Just as X is not "delegating" to Y in the sense of NS's, X is not transferring any security state to Y. X is simply referring to Y. Ditto if this is a DNAME situation.
>
>
> . (assume a "signed" root)
> ------/ | \------
> / | \
> S S S (S=secure zone)
> | | |
> S S S
> | | |
> S U S (U=insecure zone)
> | | |
> X CNAME Y DNAME Z
> |
> W
>
>In this case, X has a secured reference to Y. Y isn't protected and has a rewrite rule to Z. Z is secured. You see from inspection from a (signed) root down that there is no break in the chain to X and Z, but there is the break to Y.
>
>DNSSEC is protecting the querier in that you get to validate what you can (where there is data). But does that help the application? Not really. This is why I think DNSSEC is there just to benefit the DNS, not the application.
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis +1-571-434-5468
>NeuStar
>
>Never confuse activity with progress. Activity pays more.
--
Michael StJohns
>DNSSEC only says "this answer looks good" or "doesn't look good." Trying to figure out whether the answer's disposition is temporary/permanent, correct/incorrect, trustworthy/not takes more than just the DNS data and more than just the query at hand.
DNSSEC says the answer looks good - SECURE
or doesn't look good - BOGUS
or DNSSEC told me I shouldn't care about DNSSEC past some point - UNSECURE
or I have no information which would let me determine what DNSSEC thinks about the data - UNKNOWN
"Trustworthy" begs a definition here for what "looks good" means in relationship to "trusting" DNS data.
Edward Lewis
>Hi Ed -
>
>I agree that you can determine the security state of X and the security
>state of Y by examining trust anchors, dlv etc. But that's not the question.
>The question is "What is the security state of the compound answer XY?"
The security state - in the eyes of DNS that is easy. If the X
passes the DNSSEC test, Y passes the test as being unsigned, and Z
passes the DNSSEC test, the answer is "AD." IOW, there's nothing
suspicious about the result as far as the DNS is concerned.
It's fair to ask though "what's the value" of piecemeal checking. My
answer is that "it's out of scope" for DNS.
> From Marc Andrew's and somewhat from Wouter's email, it could be a new
>state "unauthenticated" - because the response out of an intermediate resolver
>is to return the data but not set the AD bit. I say new, because it's
>different than unknown, secure, and bogus and wouldn't be returned for the
>same reasons that you would return it for unsecure data under a single trust
>anchor. But even that begs the question of what an application should do
>with it.
>
>Later, Mike
After the debate in Winter 2001 (SLC IETF) over the AD bit not being
tied to cryptography, I'd set the AD bit in the response. I(f i)t's
authenticated to the responding server.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Michael StJohns
At 12:23 PM 10/13/2008, Michael StJohns wrote:
>At 08:16 AM 10/13/2008, Wouter Wijngaards wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Hi Michael,
>>
>>I think it is much simpler than that. The application is interested in
>>what is known with certainty.
>>1. It is certain the data is valid (secure)
>>2. It is certain that security checks failed (bogus)
>>3. whatever (insecure).
>>
>>Thus, your numbers 1, 3, 5 are folded into insecure (or maybe more
>>accurately, 'no security available').
>
>This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn't quite get all the states covered.
.... confused you with a later email by Alex.
--
Michael StJohns
Content-Type: text/plain; charset="us-ascii"
At 12:44 PM 10/13/2008, Edward Lewis wrote:
>At 12:30 -0400 10/13/08, Michael StJohns wrote:
>>Hi Ed -
>>
>>I agree that you can determine the security state of X and the security
>>state of Y by examining trust anchors, dlv etc. But that's not the question.
>>The question is "What is the security state of the compound answer XY?"
>
>The security state - in the eyes of DNS that is easy. If the X passes the DNSSEC test, Y passes the test as being unsigned, and Z passes the DNSSEC test, the answer is "AD." IOW, there's nothing suspicious about the result as far as the DNS is concerned.
You sure about that answer? Pretend all you're doing is looking up Y. Since Y is UNSECURE, shouldn't you get an answer with the AD bit cleared? So shouldn't the compound answer also clear the AD bit?
Let's go a bit further. Let's say that the validating intermediate resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS for the three legs of the triad. Should it return the SECURE and UNSECURE parts and also do a SERVFAIL? RFC 4035 - 5.5 is unclear on this:
>5.5. Resolver Behavior When Signatures Do Not Validate
>
> If for whatever reason none of the RRSIGs can be validated, the
> response SHOULD be considered BAD. If the validation was being done
> to service a recursive query, the name server MUST return RCODE 2 to
> the originating client.
*SOME* of the RRSIGs can be validated... *sigh* Does the response still return an RCODE 2?
>It's fair to ask though "what's the value" of piecemeal checking. My answer is that "it's out of scope" for DNS.
--=====================_1045147750==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
At 12:44 PM 10/13/2008, Edward Lewis wrote:<br>
<blockquote type=cite class=cite cite="">At 12:30 -0400 10/13/08, Michael
StJohns wrote:<br>
<blockquote type=cite class=cite cite="">Hi Ed -<br><br>
I agree that you can determine the security state of X and the
security<br>
state of Y by examining trust anchors, dlv etc. But that's not the
question.<br>
The question is "What is the security state of the compound answer
XY?"</blockquote><br>
The security state - in the eyes of DNS that is easy. If the X
passes the DNSSEC test, Y passes the test as being unsigned, and Z passes
the DNSSEC test, the answer is "AD." IOW, there's nothing
suspicious about the result as far as the DNS is
concerned.</blockquote><br>
You sure about that answer? Pretend all you're doing is looking up
Y. Since Y is UNSECURE, shouldn't you get an answer with the
AD bit cleared? So shouldn't the compound answer also clear the AD
bit?<br><br>
Let's go a bit further. Let's say that the validating intermediate
resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS
for the three legs of the triad. Should it return the SECURE and
UNSECURE parts and also do a SERVFAIL? RFC 4035 - 5.5 is unclear on
this:<br><br>
<br>
<blockquote type=cite class=cite cite=""><pre>5.5. Resolver
Behavior When Signatures Do Not Validate
If for whatever reason none of the RRSIGs can be validated,
the
response SHOULD be considered BAD. If the validation
was being done
to service a recursive query, the name server MUST return
RCODE 2 to
the originating client.
</pre><font face="Courier New, Courier"></font></blockquote><br>
*SOME* of the RRSIGs can be validated... *sigh* Does the response
still return an RCODE 2?<br><br>
<br><br>
<br>
<blockquote type=cite class=cite cite="">It's fair to ask though
"what's the value" of piecemeal checking. My answer is
that "it's out of scope" for DNS.</blockquote><br>
</body>
<br>
</html>
--=====================_1045147750==.ALT--
Edward Lewis
>At 10:57 AM 10/13/2008, Edward Lewis wrote:
>>DNSSEC only says "this answer looks good" or "doesn't look good."
>>Trying to figure out whether the answer's disposition is
>>temporary/permanent, correct/incorrect, trustworthy/not takes more
>>than just the DNS data and more than just the query at hand.
>
>
>DNSSEC says the answer looks good - SECURE
>or doesn't look good - BOGUS
>or DNSSEC told me I shouldn't care about DNSSEC past some point - UNSECURE
>or I have no information which would let me determine what DNSSEC
>thinks about the data - UNKNOWN
>
>"Trustworthy" begs a definition here for what "looks good" means in
>relationship to "trusting" DNS data.
This is the kind of debate that'll never end, judging from past
incarnations of this thread. To me, an answer that is under a trust
anchor and below a null DS set is "looks good" as far as DNSSEC is
concerned. I.e., to me, UNSECURE == SECURE == UNKNOWN, when I
consider the "bottom line" of the query-response. I guess I have a
Machiavellian (ends justify the means, i.e., all that matters are the
ends) streak in me.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Edward Lewis
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
I'll apologize, the indenting of quotes isn't working, so if I jumble
up what I'm replying to...
At 13:07 -0400 10/13/08, Michael StJohns wrote:
>You sure about that answer? Pretend all you're doing is looking up Y.
>Since Y is UNSECURE, shouldn't you get an answer with the AD bit cleared?
>So shouldn't the compound answer also clear the AD bit?
Back in 2001 Brian and I went on and on about the meaning of the AD
bit. To me it meant that the DNSSEC process had been completed and
we were happy. He said that "we were happy." The point of
contention was how an authoritative server set the bit.
In the first generation, authoritative servers would validate all
records as they were read from the zone file or via XFR. (I forget
how we dealt with dynamic update then.) This practice got quite
onerous and Brian decided it wasn't worth the effort as "well, if you
can't trust your own filesystem you are hosed."
I'm pinning this as Brian vs. me, but I'm just doing that for the drama.
Well, he and I went at it for 100+ messages. Finally he won - the AD
bit meant that the answering server was happy with what it was giving
back. An AD bit and a TSIG to the server was all a stub should need -
i.e., TSIG says "I trust you" and the AD bit said "well, the one I
trust is happy, ergo I am happy."
So - if X and Z are signed and validated and Y is determined to not
have any possible chance at being validated, all three are "happy"
states and the AD bit ought to be set.
I realize that there is a boat load of security professionals that
are uncomfortable with the notion that you can declare something
checked if there is nothing to check. That represented my position
in the thread long ago. Truth is, the world is not as the security
folks see.
Most folks are "innocent until proven guilty" types, not "guilty
until proven innocent." And that was reflected in the result of the
thread and the RFC 3655 (obsoleted by the last round of DNSSEC RFCs).
Let's go a bit further. Let's say that the validating intermediate
resolver queried without the CD bit set gets SECURE, UNSECURE and
BOGUS for the three legs of the triad. Should it return the SECURE
and UNSECURE parts and also do a SERVFAIL? RFC 4035 - 5.5 is unclear
on this:
I don't think it matters what you choose to do, i.e.,
per-implementation choice won't violate interoperability.
If a server replies with just X and Y (as SECURE and UNSECURE), the
querier would realize the answer is not complete and have to go off
and try to get Z (BOGUS) and see a SERVFAIL. IF the server
immediately gives back a SERVFAIL, you save a round trip but the
querier won't get the SECURE and UNSECURE X and Y.
5.5. Resolver
Behavior When Signatures Do Not Validate
If for whatever reason none of the RRSIGs can be validated,
the
response SHOULD be considered BAD. If the validation
was being done
to service a recursive query, the name server MUST return
RCODE 2 to
the originating client.
*SOME* of the RRSIGs can be validated... *sigh* Does the response
still return an RCODE 2?
It's not meant to be interpreted as "some is the opposite of none"
but "none" versus "at least one (chain) works." The problem is that
this section is deficient - it only thinks of looking for X (no
consideration of CNAME or DNAME). The text needs to be rewritten to
handle CNAME and DNAME (or any other lookup altering) processing.
This ought to be marked as an issue for the DNSSECbis document.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--============_-988128433==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure
and</title></head><body>
<div>I'll apologize, the indenting of quotes isn't working, so if I
jumble up what I'm replying to...</div>
<div><br></div>
<div>At 13:07 -0400 10/13/08, Michael StJohns wrote:</div>
<div>>You sure about that answer? Pretend all you're doing is
looking up Y. </div>
<div>>Since Y is UNSECURE, shouldn't you get an answer with
the AD bit cleared?</div>
<div>>So shouldn't the compound answer also clear the AD bit?</div>
<div><br></div>
<div>Back in 2001 Brian and I went on and on about the meaning of the
AD bit. To me it meant that the DNSSEC process had been
completed and we were happy. He said that "we were
happy." The point of contention was how an authoritative
server set the bit.</div>
<div><br></div>
<div>In the first generation, authoritative servers would validate all
records as they were read from the zone file or via XFR. (I
forget how we dealt with dynamic update then.) This practice got
quite onerous and Brian decided it wasn't worth the effort as
"well, if you can't trust your own filesystem you are
hosed."</div>
<div><br></div>
<div>I'm pinning this as Brian vs. me, but I'm just doing that for the
drama.</div>
<div><br></div>
<div>Well, he and I went at it for 100+ messages. Finally he won
- the AD bit meant that the answering server was happy with what it
was giving back. An AD bit and a TSIG to the server was all a stub
should need - i.e., TSIG says "I trust you" and the AD bit
said "well, the one I trust is happy, ergo I am
happy."</div>
<div><br></div>
<div>So - if X and Z are signed and validated and Y is determined to
not have any possible chance at being validated, all three are
"happy" states and the AD bit ought to be set.</div>
<div><br></div>
<div>I realize that there is a boat load of security professionals
that are uncomfortable with the notion that you can declare something
checked if there is nothing to check. That represented my
position in the thread long ago. Truth is, the world is not as
the security folks see.</div>
<div><br></div>
<div>Most folks are "innocent until proven guilty" types,
not "guilty until proven innocent." And that was
reflected in the result of the thread and the RFC 3655 (obsoleted by
the last round of DNSSEC RFCs).</div>
<div><br></div>
<div>Let's go a bit further. Let's say that the validating
intermediate resolver queried without the CD bit set gets SECURE,
UNSECURE and BOGUS for the three legs of the triad. Should it
return the SECURE and UNSECURE parts and also do a SERVFAIL? RFC
4035 - 5.5 is unclear on this:</div>
<div><br></div>
<div>I don't think it matters what you choose to do, i.e.,
per-implementation choice won't violate interoperability.</div>
<div><br></div>
<div>If a server replies with just X and Y (as SECURE and UNSECURE),
the querier would realize the answer is not complete and have to go
off and try to get Z (BOGUS) and see a SERVFAIL. IF the server
immediately gives back a SERVFAIL, you save a round trip but the
querier won't get the SECURE and UNSECURE X and Y.</div>
<div><br></div>
<div><br></div>
<div><tt>5.5. Resolver<br>
Behavior When Signatures Do Not Validate<br>
<br>
If for whatever reason none of the RRSIGs can be
validated,<br>
the<br>
response SHOULD be considered BAD. If the
validation<br>
was being done<br>
to service a recursive query, the name server MUST
return<br>
RCODE 2 to</tt></div>
<div><tt> the originating client.</tt></div>
<div><tt><br></tt></div>
<div><br></div>
<div>*SOME* of the RRSIGs can be validated... *sigh* Does the
response still return an RCODE 2?</div>
<div><br></div>
<div>It's not meant to be interpreted as "some is the opposite of
none" but "none" versus "at least one (chain)
works." The problem is that this section is deficient - it
only thinks of looking for X (no consideration of CNAME or DNAME).
The text needs to be rewritten to handle CNAME and DNAME (or any other
lookup altering) processing.</div>
<div><br></div>
<div>This ought to be marked as an issue for the DNSSECbis
document.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Never confuse activity with progress. Activity pays
more.</div>
</body>
</html>
--============_-988128433==_ma============--
Edward Lewis
>Broadly I agree, except I think you can also choose BOGUS == UNSECURE ==
>UNKNOWN.
Such a strategy is akin to (today) only using IPv6. ;) That is, most
of the network is not doing DNSSEC and not doing IPv6.
Equating SEURE, UNSECURE, and UNKNOWN is what I think is more to the
spirit of DNSSEC and incremental deployment. It's a recognition that
what can be secure is but you still have access to the legacy network.
Equating BOGUS, UNSECURE, and UNKNOWN is a paranoid strategy, only
trusting what you can see and touch.
In some circles I can understand the paranoia. But most of the
economy needs open access and a willingness to accept risk.
>Anyone who wants anything more nuanced than that can (and will, anyway)
>write their own s/w :-)
I hope they also realize they are a, umm, niche market... ;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Edward Lewis
>In other words: you agree that you can also choose it.
You can choose whatever you want whenever you want. Local policy
always trumps all other policies.
There's what I would recommend for "general purpose implementations"
and then there is what I would implement for turnkey implementations.
All that matters is that they ultimately interoperate and still meet
each situation's needs.
Michael StJohns
After thinking about this topic for a while, I'm still bothered by the inconsistency of treatment here.
But I think I have a possible mechanism - at least for DNAME.
DNAME is the pretty much the equivalent of a delegation - only sideways. Why not treat it like any other delegation? In other words, in addition to the records currently permitted at a DNAME node, add DS to the list. This would require slightly overloading the meaning of DS, but in a way that doesn't break the model too much.
If a DNAME node does not have at least one corresponding DS record (proven by NSEC/NSEC3), the validation rules are exactly the same as if you'd not included a DS for a subordinate delegation. E.g. no DNSSEC is expected in the target zone.
Since one of either DNAMEs or NS records can be present at a node (I think that's correct), the interpretation of the DS record is dependent on which of these two is present. If the type is DNAME, the DS record points to a DNSKEY record at the target name and the chain has to continue from there.
This gets away from the problem where a resolver has one trust anchor, but doesn't have a trust anchor for the target zone at the cost of requiring some administration of the DS at the DNAME.
Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if you have trust anchors for any further targets - the validation answer is UNSECURE. This is required for consistency - different resolvers have different sets of trust anchors. It's not all that coherent to get BOGUS from one, UNSECURE from another and UNKNOWN from a third if you can avoid it. Chaining security back to the original trust anchor and evaluating security in terms of data that chains back ONLY to that trust anchor seems to be the most consistent approach.
In any event, I think this is at least somewhat backwards compatible.
Let the mud slinging begin... :-)
Mike
Mark Andrews
In message <E1KsoTF-...@psg.com>, Michael StJohns writes:
>
> After thinking about this topic for a while, I'm still bothered by the incons
> istency of treatment here.
>
> But I think I have a possible mechanism - at least for DNAME.
>
> DNAME is the pretty much the equivalent of a delegation - only sideways. W
> hy not treat it like any other delegation? In other words, in addition to th
> e records currently permitted at a DNAME node, add DS to the list. This woul
> d require slightly overloading the meaning of DS, but in a way that doesn't b
> reak the model too much.
>
> If a DNAME node does not have at least one corresponding DS record (proven by
> NSEC/NSEC3), the validation rules are exactly the same as if you'd not inclu
> ded a DS for a subordinate delegation. E.g. no DNSSEC is expected in the targ
> et zone.
>
> Since one of either DNAMEs or NS records can be present at a node (I think th
> at's correct), the interpretation of the DS record is dependent on which of t
> hese two is present. If the type is DNAME, the DS record points to a DNSKEY
> record at the target name and the chain has to continue from there.
So I create a DNAME pointing into a zone I don't own and
add a DS pointing to a forged DNSKEY. This DNSKEY is then
marked as trusted and I now have control of a zone I don't
own.
> This gets away from the problem where a resolver has one trust anchor, but do
> esn't have a trust anchor for the target zone at the cost of requiring some a
> dministration of the DS at the DNAME.
>
> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e.
> DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if
> you have trust anchors for any further targets - the validation answer is UN
> SECURE. This is required for consistency - different resolvers have differen
> t sets of trust anchors. It's not all that coherent to get BOGUS from one, U
> NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining
> security back to the original trust anchor and evaluating security in terms o
> f data that chains back ONLY to that trust anchor seems to be the most consis
> tent approach.
There are only three possible outputs from a validating resolver.
The *all* of the answer and authority sections are SECURE (ad=1).
All of the answer and authority sections passed validation (got
SECURE or INSECURE) and some part was INSECURE (ad=0).
Validation failed for some part and you get SERVFAIL.
There is no UNKNOWN output. Records without a trust anchor are
INSECURE.
> In any event, I think this is at least somewhat backwards compatible.
>
> Let the mud slinging begin... :-)
>
> Mike
>
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Michael StJohns
>In message <E1KsoTF-...@psg.com>, Michael StJohns writes:
>>
>> After thinking about this topic for a while, I'm still bothered by the incons
>> istency of treatment here.
>>
>> But I think I have a possible mechanism - at least for DNAME.
>>
>> DNAME is the pretty much the equivalent of a delegation - only sideways. W
>> hy not treat it like any other delegation? In other words, in addition to th
>> e records currently permitted at a DNAME node, add DS to the list. This woul
>> d require slightly overloading the meaning of DS, but in a way that doesn't b
>> reak the model too much.
>>
>> If a DNAME node does not have at least one corresponding DS record (proven by
>> NSEC/NSEC3), the validation rules are exactly the same as if you'd not inclu
>> ded a DS for a subordinate delegation. E.g. no DNSSEC is expected in the targ
>> et zone.
>>
>> Since one of either DNAMEs or NS records can be present at a node (I think th
>> at's correct), the interpretation of the DS record is dependent on which of t
>> hese two is present. If the type is DNAME, the DS record points to a DNSKEY
>> record at the target name and the chain has to continue from there.
>
> So I create a DNAME pointing into a zone I don't own and
> add a DS pointing to a forged DNSKEY. This DNSKEY is then
> marked as trusted and I now have control of a zone I don't
> own.
I think you're confusing how you might implement this with what I actually said.
When doing this, you have to do the analysis first for the non-cached approach. Where you do all the validations and lookups from the beginning. THEN think about how you cache the data to keep from polluting trust states.
For caching, you only mark the apex DNSKEY (and its subordinate data) of the target zone as trusted ONLY for queries that are referred in via the off-tree DNAME and DS. If you come at it any other way you don't trust the data unless you have a superior trust anchor. (Yup I know - more cruft, but relative to DNSSEC probably not a great portion of the cruft).
Let's say the recursive validating resolver doesn't have a superior trust anchor for the target - a direct query for the target gets the data with an output state of unknown/unsecure. An indirect query via the DNAME - assuming the target is signed and the DS chain validates - has the possibility of getting data with an output state of secure - or for that matter bogus (in which case no data or partial data is returned).
If you do have a configured trust anchor for the target zone and that validation doesn't match the DS referral from the DNAME - well - that's probably one of the BOGUS cases. If you don't have a configured trust anchor for the target zone, umm... then the owner of the DNAME can steer you pretty much wherever he wants - even a zone that's somewhere that doesn't have a trust anchor so how is this worse?
You are correct that if you implement this so the resolver takes the indirect trust and caches it as absolute trust then the owner of any DNAME under any trust anchor can pollute the trust cache on that resover. So don't implement it this way....
>> This gets away from the problem where a resolver has one trust anchor, but do
>> esn't have a trust anchor for the target zone at the cost of requiring some a
>> dministration of the DS at the DNAME.
>>
>> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e.
>> DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if
>> you have trust anchors for any further targets - the validation answer is UN
>> SECURE. This is required for consistency - different resolvers have differen
>> t sets of trust anchors. It's not all that coherent to get BOGUS from one, U
>> NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining
>> security back to the original trust anchor and evaluating security in terms o
>> f data that chains back ONLY to that trust anchor seems to be the most consis
>> tent approach.
>
> There are only three possible outputs from a validating resolver.
>
> The *all* of the answer and authority sections are SECURE (ad=1).
>
> All of the answer and authority sections passed validation (got
> SECURE or INSECURE) and some part was INSECURE (ad=0).
>
> Validation failed for some part and you get SERVFAIL.
>
> There is no UNKNOWN output. Records without a trust anchor are
> INSECURE.
There's a difference between the output from a validator and the output from a validating resolver - but I digress...
We're just going to have to agree to disagree. I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data). That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point. So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-)
Edward Lewis
>After thinking about this topic for a while, I'm still bothered by the
>inconsistency of treatment here.
What inconsistency?
>But I think I have a possible mechanism - at least for DNAME.
>
>DNAME is the pretty much the equivalent of a delegation - only sideways.
>Why not treat it like any other delegation? In other words, in addition to
>the records currently permitted at a DNAME node, add DS to the list.
>This would require slightly overloading the meaning of DS, but in a way
>that doesn't break the model too much.
This makes as much sense as "matrix management." DNAME isn't a
delegation, it's a query restart. What if the DNAME says there is a
DS for the target but following the tree down to the target has no
DNAME?
>This gets away from the problem where a resolver has one trust anchor, but
>doesn't have a trust anchor for the target zone at the cost of requiring
>some administration of the DS at the DNAME.
This is not a problem. If the target of the DNAME is not DNSSEC
protected, it doesn't matter to the DNS. The application maybe, but
what can it do? If the target administrator has not signed the zone,
then the application simply cannot validate the answer via DNSSEC.
>another and UNKNOWN from a third if you can avoid it. Chaining security back
>to the original trust anchor and evaluating security in terms of data that
>chains back ONLY to that trust anchor seems to be the most
>consistent approach.
I think you are expecting too much from DNSSEC.
Thinking about this scenario, if your application really needed
security like this, why would there be the situation of secure DNAME
insecure DNAME secure? Although this flip-flop may happen, will it
happen where it matters? Is it realistic? Or are we whacking with a
sledgehammer at a shadow?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Michael StJohns
>Michael StJohns wrote:
>
>
>If I chose to point a DNAME at an unsecured domain, then that was my
>choice, and I should live with it. If I don't want the domain to be
>unsecured, then I should either not delegate to it, or ensure it is
>secured by non-protocol means (e.g. by owning the domain myself, by
>contract, by sufficient purchase of beer for the domain owner, etc.)
Hi Ben -
One of the problem we get with DNS is that there are two views of the data (at least) - the publisher's, and the resolver's views. DNSSEC makes this more complicated by the presence or absence of certain trust anchors.
As publisher, I have a signed domain, and as publisher, I publish a DNAME also pointing at a signed domain. I've done my due diligence as you suggest - I even own the target zone.
As resolver, I get a trust anchor for the first domain (more probably for a parent of the domain), but I don't have any a priori information that the target domain is also signed (or even that I had a redirect to that zone), so I don't know to get a trust anchor for it. There's no way of encoding in DNS/DNSSEC the publishers security intentions with respect to the complete DNAME chain. This leads to the problem where the publisher thought it was delegating into a signed zone, but the resolver thought the zone was unknown (no superior trust anchor). The resolver has no way of telling that the publisher really thought this zone was signed and that the resolver should return a BOGUS answer if the target zone wasn't.
Answering Ed's question about inconsistency here: In a resolution without indirect records (e.g. DNAME, CNAME, MX, etc), the resolvers expectation about the security state of the answer are originally set by the presence or absence of a trust anchor and, assuming the trust anchor is present, that expectation changes only upon proof that it should (e.g. signed delegation into unsigned zone). With DNAME, once the resolver starts doing lookups in the target zone, it restarts its expectation of the state of the answer based on what it knows about trust anchors for the target. There is no chain of proof possible from the DNAME zone to the target zone in this model.
My suggestions are an attempt to provide a chain of proof from the original trust anchor (provided by the DNAME publisher or its parent) through to the final answer. If that chain of proof validates, the resolver can say something useful about the entire answer chain and the final answer and I think that's the only case in which this is true. The case where the resolver just happens to have trust anchors for the DNAME zone and all of the target zones says useful things about each individual zone lookup, but not about the compound answer (I can elaborate here about DNAME publisher expectations and target zone publisher actions if necessary).
>--
>http://www.apache-ssl.org/ben.html http://www.links.org/
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff
--
Michael StJohns
>At 20:54 -0400 10/22/08, Michael StJohns wrote:
>>After thinking about this topic for a while, I'm still bothered by the
>>inconsistency of treatment here.
>
>What inconsistency?
See my note to Ben.
>>But I think I have a possible mechanism - at least for DNAME.
>>
>>DNAME is the pretty much the equivalent of a delegation - only sideways.
>>Why not treat it like any other delegation? In other words, in addition to
>>the records currently permitted at a DNAME node, add DS to the list.
>>This would require slightly overloading the meaning of DS, but in a way
>>that doesn't break the model too much.
>
>This makes as much sense as "matrix management." DNAME isn't a delegation, it's a query restart. What if the DNAME says there is a DS for the target but following the tree down to the target has no DNAME?
I'm not sure what you're getting at here. DNAMEs point off tree. So if I have
foo.example.com DNAME otherexample.com
foo.example.com DS <ds data>
foo.example.com NSEC [DNAME, DS] <target>
otherexample.com DNSKEY <data pointed to by the DS>
otherexample.com <rest of the RRs>
DNAME says go look at another zone.
DS says here's how you bridge the trust.
If you're saying, what happens if you do a DNAME to a name subordinate to the DNAME - isn't that one of those illegal cases for DNAME?
>>This gets away from the problem where a resolver has one trust anchor, but
>>doesn't have a trust anchor for the target zone at the cost of requiring
>>some administration of the DS at the DNAME.
>
>This is not a problem. If the target of the DNAME is not DNSSEC protected, it doesn't matter to the DNS.
This is a problem. DNAME publisher thought the target was protected, resolver didn't have trust anchors for it.
>The application maybe, but what can it do? If the target administrator has not signed the zone, then the application simply cannot validate the answer via DNSSEC.
>
>>another and UNKNOWN from a third if you can avoid it. Chaining security back
>>to the original trust anchor and evaluating security in terms of data that
>>chains back ONLY to that trust anchor seems to be the most consistent approach.
>
>I think you are expecting too much from DNSSEC.
>
>Thinking about this scenario, if your application really needed security like this, why would there be the situation of secure DNAME insecure DNAME secure? Although this flip-flop may happen, will it happen where it matters? Is it realistic? Or are we whacking with a sledgehammer at a shadow?
I used that one as an example to try and figure out what the output state was and got an answer from all of you that was inconsistent with the general contract. In the case I'm proposing - once you went unsecure - as provide by the DS chain through the DNAME - then you'd stay unsecure, just like you do now with signed delegations into unsigned zones.
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis +1-571-434-5468
>NeuStar
>
>Never confuse activity with progress. Activity pays more.
>
Michael StJohns
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Michael,
>
>semantics more. Get a new type code, like DLV did.
Fair - but the the new record will pretty much have the same syntax and semantics.
>That said, lets sling some mud :-)
>
>Michael StJohns wrote:
>> At 11:43 PM 10/22/2008, Mark Andrews wrote:
>>>> DNAME is the pretty much the equivalent of a delegation - only sideways. W
>>>> hy not treat it like any other delegation? In other words, in addition to th
>>>> e records currently permitted at a DNAME node, add DS to the list. This woul
>>>> d require slightly overloading the meaning of DS, but in a way that doesn't b
>>>> reak the model too much.
>>>>
>
>So you want the owner of the DNAME to indicate if he is referring to a
>secured zone or not (using a hash of a key). And the validator can then
>check if the destination is really secure. This needs only one bit:
>target of redirection is supposed to be secure yes/no.
I considered this - but that means that you need to ensure that all the resolvers have the second and subsequent trust anchors and that's problematic. Encoding the chain of trust as part of the DNAME referral means that I as publisher don't have to worry (much) about whether or not the resolver has my target's trust anchor.
>The chain of trust runs parralel to the delegation hierarchy, and I
>think sideways chains of trust need not enter the picture here. Not for
>your DNAME concerns.
>
>Although the above is what I think you want. I think the current DNAME
>situation is fine. The resolver can see if the target of a DNAME
>redirection is secure or not based on trust anchors, and is going to set
>the security result of the entire DNAME-chain to the lowest security
>encountered anyway.
Yeah, except there's no way of encoding this in a return from a validating recursive resolver to a non-DNSSEC aware stub. The one bit approach that tells the resolver to block a return unless the entire answer validates (or is securely unsecure) is slightly better, but gets into a coherence issue.
>>>> This gets away from the problem where a resolver has one trust anchor, but do
>>>> esn't have a trust anchor for the target zone at the cost of requiring some a
>>>> dministration of the DS at the DNAME.
>
>Yeeks how to keep that DS up to date. Better one bit: target secure, it
>does not suffer from key rollover.
If I'm DNAMEing to a zone, I'm going to have to set up some protocol for dealing with changes to that zone. A variant of the trust anchor update stuff would work here.
>>>> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e.
>>>> DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if
>>>> you have trust anchors for any further targets - the validation answer is UN
>>>> SECURE. This is required for consistency - different resolvers have differen
>>>> t sets of trust anchors. It's not all that coherent to get BOGUS from one, U
>>>> NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining
>>>> security back to the original trust anchor and evaluating security in terms o
>>>> f data that chains back ONLY to that trust anchor seems to be the most consis
>>>> tent approach.
>>> There are only three possible outputs from a validating resolver.
>>>
>>> The *all* of the answer and authority sections are SECURE (ad=1).
>>>
>>> All of the answer and authority sections passed validation (got
>>> SECURE or INSECURE) and some part was INSECURE (ad=0).
>>>
>>> Validation failed for some part and you get SERVFAIL.
>>>
>>> There is no UNKNOWN output. Records without a trust anchor are
>>> INSECURE.
>
>I agree with Mark here.
>
>> We're just going to have to agree to disagree. I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data). That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point. So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-)
>
>No.
>
>You see when a validator encounters a securely-insecure delegation, I
>mean a proof that a DS is absent. Then it knows that the remainder is
>not signed with a chain of trust from the trust anchor that it has been
>following. However, the result is simply insecure, and not somehow
>magically more secure that a result obtained without a trust anchor at
>all. What is the extra security afforded by a securely insecure
>delegation? The result is as prone to modification as a result obtained
>for a domain without trust anchor.
It's a fair comment. Here's why I continue to fight this. A trust anchor provides two pieces of information: a public key, and by the mere presence of the trust anchor the initial state of a virtual "zone is signed" bit. The absence of the trust anchor does not equate to "zone is not signed" but to "resolver doesn't know whether the zone is signed"
Think of it this way, the unknown state is like the X state in ASIC circuitry design. You may end up treating it as a 0 or 1 at some point, but you have to figure out a way of collapsing it to the 0 or 1 first. Resolvers basically collapse the X to a 0 - unsecure - because they don't have the ancillary information (trust anchor) to treat it as a 1. The resolver doesn't know if the zone is signed, but it has no way of proceeding unless it treats the zone as unsigned. The transition from X to 0 is not secure - there's no cryptographic proof to do the state setting. This differs from a secure transition from secure to unsecure - from 1 to 0 - by doing a signed delegation to an unsigned zone.
I actually can at some point see some policy wonk requiring that resolvers under the wonk's control will not resolve names unless they are under a trust anchor. He won't care about the fact that some delegations are to unsecure zones - he's just concerned about getting DNSSEC deployed. So yes - I still think there's a difference.
While I was going through this exercise of answering your email, Ben's and Ed's I came up with a pretty good example of why I think this (chaining through a DNAME) is necessary.
I work for the example.com company. My local recursive resolver has been set up with example.com trust anchors. The example.com zone includes a set of records which describe the SSH fingerprints for those machines. example.com is sold to otherexample.com and a DNAME record is placed into the system to do the redirect. My local resolver still only has the trust anchor for example.com. I go to a new machine asking the "newmachine.example.com" question to retrieve the SSH fingerprint (I'm an old timer - I'm still using old scripts). I get an answer for the SSH fingerprint and for an A record - which has been cheerfully forged by a data thief. I go to that machine, update the 10 gig of ssn's, names and birthdates that I'm archiving from a machine I'm about to rebuild. That machine is somewhere in russia, china, new york, etc... and its not a company machine.
Out of band, I (person, machine whatever) was told I could rely on the data returned from the resolver for security purposes. (And this is why I've told people over the years that DNSSEC should not be relied upon to validate anything other than DNS data). My machine was set up with that assumption in mind. The local resolver is doing what its supposed to do under the current DNAME interpretation. My machine is doing what it is supposed to do with the data. But I got screwed.
>Of course, the two domain set ups have a different operational
>configuration. So although you can give them different names (which can
>be useful for other things, such as operator debugging), they have the
>same level of security.
>
>>>> Let the mud slinging begin... :-)
>
>Cheers,
> Wouter
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>
>iEYEARECAAYFAkkAKB4ACgkQkDLqNwOhpPin2gCgtHuA1I2S/+Gok9TQ3BNnN7Pw
>Z+MAn2YAD/HLWriLwP0y2+q55FScRfW8
>=nwDQ
>-----END PGP SIGNATURE-----
Edward Lewis
>My suggestions are an attempt to provide a chain of proof from the original
>trust anchor (provided by the DNAME publisher or its parent) through to the
>final answer.
I think that's all out of bounds for DNSSEC. DNSSEC is protecting
the transfer of data within the DNS.
o What if you go to a signed NAPTR record, get a replacement name that
is unsigned, then a replacement string that goes to a signed SRV which
leads to an unsigned A record?
o What if you to to a web page that has a signed A record but are then
redirected to a web page that has no signed address record?
DNAME, CNAME, NAPTR, and some applications the query changes from the
start to end of the whole DNS session. I'm now defining (becuase it
is convenient for my side of the argument) "DNS session" to consist
of any number of DNS iterations leading to the satisfaction of the
application. DNSSEC protects the iteration, not the session.
o What does DNS tell a user if an application, outside of the DNS, changes
the name sought as a result of it's lookup process, starting from a name
that was DNSSEC validated to a name that has no DNSSEC ancillary data?
More or less, I don't think the problem (as I understand what Mike
wants) is solvable or is commonplace enough (or even realistic) to
warrant something so radical as barfing the DS record. (Heck, it's a
hack Olafur invented, that was one of the three things I didn't like
about it an eon ago - ask him.)
Too bad I can't make it to Bethesda tonight so we could talk this
over at the corner of Del Ray and Norfolk. (I.e., where there would
be witnesses.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Mark Andrews
In message <E1Kt301-...@psg.com>, Michael StJohns writes:
> At 06:59 AM 10/23/2008, Ben Laurie wrote:
> >Michael StJohns wrote:
> >
> >I don't understand the rationale behind all this complication.
> >
> >If I chose to point a DNAME at an unsecured domain, then that was my
> >choice, and I should live with it. If I don't want the domain to be
> >unsecured, then I should either not delegate to it, or ensure it is
> >secured by non-protocol means (e.g. by owning the domain myself, by
> >contract, by sufficient purchase of beer for the domain owner, etc.)
>
> Hi Ben -
>
> One of the problem we get with DNS is that there are two views of the data (a
> t least) - the publisher's, and the resolver's views. DNSSEC makes this more
> complicated by the presence or absence of certain trust anchors.
>
> As publisher, I have a signed domain, and as publisher, I publish a DNAME als
> o pointing at a signed domain. I've done my due diligence as you suggest - I
> even own the target zone.
Signing the zones and publishing DS / DLV records is due
diligence. At that point you need to trust that the resolver
operator will do due diligence and configure all known trust
anchors or use a DLV service.
Yes there will be configurations that will not return SECURE
when there is theoretically enough information to return
SECURE.
And the simple answer is to just ensure that there is a
chain of trust from the root to both zones. If you are
unhappy about the lack of trust chains lobby your politicians
and registry operators to get the root and infrastructure
zones signed.
This is not something we need to "fix" using technology.
What we have today is complicated enough to manage without
having to track cross zone pseudo delegations.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Michael StJohns
>In message <E1Kt301-...@psg.com>, Michael StJohns writes:
>> At 06:59 AM 10/23/2008, Ben Laurie wrote:
>> >Michael StJohns wrote:
>> >
>> >I don't understand the rationale behind all this complication.
>> >
>> >If I chose to point a DNAME at an unsecured domain, then that was my
>> >choice, and I should live with it. If I don't want the domain to be
>> >unsecured, then I should either not delegate to it, or ensure it is
>> >secured by non-protocol means (e.g. by owning the domain myself, by
>> >contract, by sufficient purchase of beer for the domain owner, etc.)
>>
>> Hi Ben -
>>
>> One of the problem we get with DNS is that there are two views of the data (a
>> t least) - the publisher's, and the resolver's views. DNSSEC makes this more
>> complicated by the presence or absence of certain trust anchors.
>>
>> As publisher, I have a signed domain, and as publisher, I publish a DNAME als
>> o pointing at a signed domain. I've done my due diligence as you suggest - I
>> even own the target zone.
>
> Signing the zones and publishing DS / DLV records is due
> diligence. At that point you need to trust that the resolver
> operator will do due diligence and configure all known trust
> anchors or use a DLV service.
I haven't a clue how you would expect to administer this. When was the last time you heard of someone running a zone who changed it out for a DNAME announcing this to the world?
5011 provides a mechanism to track changes in trust anchors without having to have an out of band path to those changes. Are you proposing that we create some sort of DNAME announcement protocol? Or are you suggesting something else?
Let's work this further. Say .COM is signed, but .EDU isn't. Say I'm in a secure zone under .com - example.com. Say the DNAME is from subzone.example.com to otherzone.edu. Say otherzone.edu is signed. Say the resolver has a trust anchor for .COM. How the heck do I as the owner of subzone.example.com figure out which resolvers to tell about the change??
In many (most?) organizations, the guys who run the authoritative servers and update the data in the zones are not the guys who run the local resolvers, so even in the same organization the administrators may not realize they need to do something special. Certainly the DNAME documentation doesn't describe any operational considerations related to DNSSEC.
> Yes there will be configurations that will not return SECURE
> when there is theoretically enough information to return
> SECURE.
>
> And the simple answer is to just ensure that there is a
> chain of trust from the root to both zones. If you are
> unhappy about the lack of trust chains lobby your politicians
> and registry operators to get the root and infrastructure
> zones signed.
That may be the simple answer, but even simple answers are difficult. See above.
And the fact that all nodes chain to a trust anchor is not sufficient to say that there is an unbroken chain of trust from the first trust anchor to the last answer.
> This is not something we need to "fix" using technology.
> What we have today is complicated enough to manage without
> having to track cross zone pseudo delegations
*sigh* There's complicated and there's correct. If its complicated and wrong, its still wrong.
Edward Lewis
>How the heck do I as the owner of subzone.example.com figure out which
>resolvers to tell about the change??
The answer is "you don't" and "DNSSEC never promised you could."
Remember that the, okay, a fundamental rule of DNSSEC is that it is
there to protect the resolver and not the authority of the data. You
(as an admin) don't have any tools to reach out and touch your
audience. Just as DNSSEC does not guarantee the answer will get
through (no DoS prevention) it only guarantees that what is received
can be validated (if the stars align). DNSSEC is driven from the
resolver and not the authority.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--
Stephane Bortzmeyer
Souissi but he is too busy to write now.]
On Thu, Oct 23, 2008 at 11:10:48PM +0200,
Edward Lewis <Ed.L...@neustar.biz> wrote
a message of 46 lines which said:
> o What if you go to a signed NAPTR record, get a replacement name
> that is unsigned, then a replacement string that goes to a signed
> SRV which leads to an unsigned A record?
The reasonable thing to do, security-wise, is to decide that the
validity of the "DNS session" is the validity of the *worse*
iteration. If all the "DNS iterations" yield Secure and one yields
Insecure, the whole session is Insecure. If some yield Secure, some
Insecure, and one yields Bogus, the net result is Bogus.
This will make things more difficult to debug, but, from a security
point of view ("the strength of the chain is the strength of the
weakest link"), it seems the only thing to do.
It will be difficult to implement because a validating resolver cannot
know what iterations are in the same session. You'll have to do it in
the application.
> o What if you to to a web page that has a signed A record but are
> then redirected to a web page that has no signed address record?
More complicated to handle since it is not purely DNS. Is the HTTP
redirection done over TLS? :-)
Edward Lewis
>[Warning, most of the ideas here come from my colleeague Mohsen
>Souissi but he is too busy to write now.]
He provides a good "straight man" [http://en.wikipedia.org/wiki/Comic_foil]...
>The reasonable thing to do, security-wise, is to decide that the
>validity of the "DNS session" is the validity of the *worse*
>iteration. If all the "DNS iterations" yield Secure and one yields
>Insecure, the whole session is Insecure. If some yield Secure, some
>Insecure, and one yields Bogus, the net result is Bogus.
That's valid - but remember that DNSSEC does not protect the DNS
session, just the passing of data through the system of servers.
Consider the query for "T_ANY" towards any authoritative server's
apex (of any zone hosted). The return includes SOA, NS, and maybe
other record sets. DNSSEC can be used to set-wise individually
validate, but not report a status for the entire answer. (As in,
there's just one RCODE field, no way to say "this is good, that bad,
that good.)
We were frustrated by that inability when writing the code way back.
>More complicated to handle since it is not purely DNS. Is the HTTP
>redirection done over TLS? :-)
And that's also directly working into the point I was making, the
security of the session is dependent on all sorts of things, in this
case external to DNSSEC. DNSSEC can't (as in lacks the bit fields
to) "protect" the chain from what the consuming user types into the
browser and where the HTTP protocol ultimately sends the user.
Yes, a bit far fetched and out of bounds for a DNS argument. I
mentioned this example to show why we really can't go even "half-way"
to securing a CNAME/DNAME/query re-direction/write "path" through the
DNS, just the data as it is presented. You have to also trust the
software correctly implements the protocol, not just sign the data.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
--