Kumar Ashutosh | 30 Mar 11:04 2015
Picon

RFC 6604 Clarification

Hi

As per RFC 6604, section 3

      When an xNAME chain is followed, all but the last query cycle

      necessarily had no error.  The RCODE in the ultimate DNS response

      MUST BE set based on the final query cycle leading to that

      response.  If the xNAME chain was terminated by an error, it will

      be that error code.  If the xNAME chain terminated without error,

              it will be zero.

 

This is a little vague on two accounts:

1. What would be the error code if the server decides to curtail the CNAME chain after a certain length (say 20). Is it still success or do we indicate in some other way.

2. If the CNAME chain points to a Qname for which the auth server is non-authoritative (and recursion is disabled on the auth server.) The server in this case cannot get the response. A direct query for this Qname will result in SERV_FAIL. Should the auth server return SERV_FAIL in this case? Will resolvers respect answers with SERV_FAIL in RCODE and cache the partial response?

 

Can we put a clarification?

 

Thanks

Ashu

Program Manager | Windows Networking| DNS

 

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Wessels, Duane | 21 Feb 02:19 2015
Picon

TTL on DS records

Section 5 of RFC 4034 says:

   The DS RR has no special TTL requirements.

While RFC 4035 Section 2.4 says:

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset

Due the "SHOULD" I'm not sure this is worthy of an errata, but seems rather unfortunate.

Apologies if this is a previously known issue.

DW

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
RFC Errata System | 12 Jan 14:25 2015

[Errata Rejected] RFC6840 (4191)

The following errata report has been rejected for RFC6840,
"Clarifications and Implementation Notes for DNS Security (DNSSEC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Edward Lewis <edward.lewis <at> icann.org>
Date Reported: 2014-12-02
Rejected by: Brian Haberman (IESG)

Section: 5.11

Original Text
-------------
...

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  

Corrected Text
--------------
A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  Each
      authoritative RRset in the zone MUST be signed with each 
      algorithm (though not each key) present in the DNSKEY RRset.  

Notes
-----
Zones aren't signed (per se), the data sets within them are.  But not cut point (NS) and glue.
 --VERIFIER NOTES-- 
 This erratum is being rejected as the nomenclature being updated is understood within the community and is
used in other DNSSEC specifications.  

--------------------------------------
RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20)
--------------------------------------
Title               : Clarifications and Implementation Notes for DNS Security (DNSSEC)
Publication Date    : February 2013
Author(s)           : S. Weiler, Ed., D. Blacka, Ed.
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

bert hubert | 20 Dec 13:58 2014
Picon

Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls

Hi everybody,

I have a question if I am right in concluding something is a protocol
violation, and if we should reward it by papering it over or (finally)
concluding that enough is enough.

A few weeks ago we posted this
http://mailman.powerdns.com/pipermail/pdns-users/2014-December/011004.html
about Microsoft Azure nameservers sending empty answers (AD=1 no less) to
AAAA queries. Microsoft has indicated they'll get to addressing this early
2015, by the way (thanks Mehmet).

However, we're now seeing more and more of this, for example from the most
popular news site in the Netherlands nu.nl: 

$ dig +trace -t aaaa nu-nl.gslb.sanomaservices.nl.

Which ends on:

$ dig -t aaaa nu-nl.gslb.sanomaservices.nl.  <at> 62.69.175.251
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58444
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;nu-nl.gslb.sanomaservices.nl.	IN	AAAA

Note that this is the same pattern as Microsoft Azure. But this empty AA=0
answer leads PowerDNS to:

 nu-nl.gslb.sanomaservices.nl.: Trying IP 62.69.175.251:53 1, asking 'nu-nl.gslb.sanomaservices.nl.|AAAA'
 nu-nl.gslb.sanomaservices.nl.: Got 0 answers from gslb2.sanomaservices.nl. (62.69.175.251),
rcode=0 (No Error), aa=0, in 6ms
 nu-nl.gslb.sanomaservices.nl.: determining status after receiving this packet
 nu-nl.gslb.sanomaservices.nl.: status=NS gslb2.sanomaservices.nl. (62.69.175.251) is lame for
'gslb.sanomaservices.nl.', trying sibling IP or NS
 nu-nl.gslb.sanomaservices.nl.: Failed to resolve via any of the 2 offered NS at level 'gslb.sanomaservices.nl.'
 nu-nl.gslb.sanomaservices.nl.: failed (res=-1)

And this means we send out a SERVFAIL to our client, since all servers are
'lame'.  This makes some programs very unhappy.

We are (as is any resolver implementor) receiving pressure not to do this,
and to paper over this behaviour. There is a workaround available in the URL
above.

We think the time has to come to say 'no, if you run a non-confirming
implementation, you deserve all the pain you get'. 

But before we make a stand, what do you think? Should we accept empty AA=0
AD=1 answers as "NO ERROR"? 

Please let us know.

	Bert

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Paul Hoffman | 14 Dec 23:30 2014

Middleboxes and EDNS(0)

Greetings again. Section 6.1.1.1 of RFC 6891 says:

   OPT RRs MUST NOT be cached,
   forwarded, or stored in or loaded from master files.

Section 6.2.6 says:

   Middleboxes that simply forward requests to a recursive resolver MUST
   NOT modify and MUST NOT delete the OPT record contents in either
   direction.

If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR on a query coming in my left side, what do
I send that OPT RR out the right side? Do I follow the first or the second quote?

--Paul Hoffman
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

KSK Rollover SOI | 12 Dec 20:08 2014
Picon

Solicitation for Statements of Interest regarding Root KSK Rollover

ICANN, as the IANA functions operator, in cooperation with Verisign as the
Root Zone Maintainer and the National Telecommunications Information
Administration (NTIA) as the Root Zone Administrator, together known as
the Root Zone Management (RZM) partners, seek to develop a plan for
rolling the DNS root zone key-signing key (KSK). The KSK is used to sign
the
root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the
Internet’s root zone. The Root Zone Partners are soliciting five to seven
volunteers from the community to participate in a Design Team to develop
the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with
the RZM partners will form the Design Team to develop The Plan.

Individuals interested in volunteering approximately 5 hours per week for
the Design Team should consult the announcement:

https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf


and submit their Statement of Interest to ksk-rollover-soi <at> icann.org no
later than January 16, 2015.

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
RFC Errata System | 2 Dec 17:36 2014

[Editorial Errata Reported] RFC6840 (4191)

The following errata report has been submitted for RFC6840,
"Clarifications and Implementation Notes for DNS Security (DNSSEC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191

--------------------------------------
Type: Editorial
Reported by: Edward Lewis <edward.lewis <at> icann.org>

Section: 5.11

Original Text
-------------
...

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  

Corrected Text
--------------
A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  Each
      authoritative RRset in the zone MUST be signed with each 
      algorithm (though not each key) present in the DNSKEY RRset.  

Notes
-----
Zones aren't signed (per se), the data sets within them are.  But not cut point (NS) and glue.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20)
--------------------------------------
Title               : Clarifications and Implementation Notes for DNS Security (DNSSEC)
Publication Date    : February 2013
Author(s)           : S. Weiler, Ed., D. Blacka, Ed.
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Hosnieh Rafiee | 24 Oct 10:33 2014

Review request - new version of CGA-TSIG draft - draft-rafiee-intarea-cga-tsig-11

Folks,

I have revised CGA-TSIG document . You can find the following summary in the introduction as well. Just to
motivate more people to review the draft, the following is the description of the mechanism.

Thanks Joel Halpern for his comments and reviews which helped to improve its readability and content.

I would love to receive your inputs on this version so that I know whether now it is easily readable and
understandable. :-)

Thanks,
Best,
Hosnieh

< https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11 >
------------------------------
Overview of CGA-TSIG/e Mechanisms
The purpose of CGA-TSIG and CGA-TSIGe is to minimize the human intervention required to accomplish a
shared secret or key exchange (automation as much as possible), secure authentication, with the end
result of providing data confidentiality to prevent DNS spoofing. Minimizing the amount of human
intervention reduces the vulnerability to attacks introduced by human errors. As explained earlier,
CGA-TSIG/e can be used to assist DNSSEC server in last mile of Internet. CGA-TSIG/e supports both IPv4 and
IPv6 scenarios. In the IPv6 scenario, the algorithms use Cryptographically Generated Addresses (CGA)
[RFC3972] or Secure Simple Addressing Scheme for IPv6 Autoconfiguration (SSAS) [1]. Both CGA and SSAS
provide the nodes with the necessary proof of IP address ownership by providing a cryptograp
 hic binding between a host's public key and its IP address without the need for the introduction of
infrastructure. For example, in DNS stub resolver to resolver scenario, CGA-TSIG provides this sec
 ure authentication by receiving the IP address of a DNS resolver via an option from a secure Router
Advertisement (RA) or from DHCPv6 server that is protected via SAVI approaches [savi-dhcp]. When it
(client) wants to resolve a query, it sends a DNS query message by only setting algorithm type to
"CGA-TSIG" without signing this message or adding any more information. This is because resolver does
not need to verify the client and a client can be anonymous. If resolvers supports CGA-TSIG algorithm,
then it sends a DNS query response message by setting algorithm type to "CGA-TSIG", include required
parameters such as its public key in CGA-TSIG data (to be verifiable on client), sign this message and
submit it. When the client receives this message, since there is a binding between this publ
 ic key and the IP address of the resolver, by verifying the signature, the client makes sure that this public
key belongs to the target resolver. In other word, public key of the resolver is sent in
  a same message as a DNS query (no separate message is required). In case of DNS confidentiality
(CGA-TSIGe), if this client haven't already cached the public key of the resolver, it sends an empty DNS
query message by only setting the algorithm type to "CGA-TSIGe". Then the resolver knows that it should
submit its public key to the client. Since this binding exists, client can use the public key of the DNS
resolver to exchange a random value (called shared key). Then DNS resolver uses AES or other secure
symmetric algorithm to encrypt all DNS message with this random value received from this client.
In case the network is not secure, user can easily introduce the IP address of trusted resolver (or select
home resolver from the list of trusted resolvers in its computer). 
In IPv4 scenarios, the algorithms use the hash of public key as an authentication approach. For example, in
resolver scenario, the client receives the DNS resolver's hash of (IPv4 + public key) from a DHCPv4 server
that is protected by SAVI approaches or other monitoring approaches. If the network is not reliable, then
this hash value can be introduced once manually to the stub resolver. The other option is that when the
client receives the IP address or hash of (IPv4 + public key) securely from a secure DHCP server or an option
in RA message, it caches this value in a list of trusted resolver (called trusted list). Whenever there is
no trusted resolver available (like public network), the implementation can provide a way for the user to
select one of the trusted resolver stored in this tr
 usted list or it can be some random selection mechanisms. This will avoid any manual configuration for the
user. However, if this trusted list is empty and the network is not reliable, the only way 
 to provide this reliability is to introduce the DNS server's IP address manually. Similar to IPv6
scenario, the public key is sent by the resolver in a DNS query response message. When this client resolves
any query response, it compare the hash of (resolver's source IP address + public key) with what is
available on its own and if there is a match, it verifies the resolver and accepts the message. In case of DNS
confidentiality (CGA-TSIGe), the same approach that is explained in the prior paragraph can be in use.
The detail steps for these scenarios are explained in next sections.

---------------------------------------
[1]< http://tools.ietf.org/html/draft-rafiee-6man-ssas-11 > 

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Matthijs Mekking | 14 Oct 10:49 2014

Re: How are people implementing hold-down in RFC 5011?

On 13-10-14 17:58, Michael StJohns wrote:
> At 04:59 AM 10/13/2014, Matthijs Mekking wrote:
>> Hi,
>>
>> On 09-10-14 18:46, Michael StJohns wrote:
>>> At 07:57 PM 10/7/2014, Paul Hoffman wrote:
>>>> Thanks for the clarifications. I still have a bunch of
>>>> questions, and I really do wonder if implementers agree with
>>>> your interpretations.
>>
>>
>>>>>
>>>>>> 2: Attacker's zone: B signs (A Br C) (Here, "Br" means "B
>>>>>> with the REVOKE bit set".)
>>>>>
>>>>> 2 is actually B and C sign (Br C).
>>>>
>>>> When the RFC says "and signing it with B", it might be clearer
>>>> if it says "and signing it with B and C". It is far from clear
>>>> which messages from the attacker are for public consumption
>>>> (which would be seen by the zone owner) and which are meant for
>>>> restricted relying parties.
>>>
>>> That's not actually a matter of concern for the zone owner. The
>>> incantation to revoke a key K is "K signs (Kr)".  As I noted
>>> elsewhere, you can't actually have multiple disjoint DNSKEY
>>> RRSets for a given name, so that you end up doing a union of all
>>> the keys to be signed into a single DNSKEY RRSet and you provide
>>> signatures by all signers over all the keys.
>>
>> When the RFC says "and signing it with B" in section 2.2 Add
>> Hold-Down, it talks about adding C to the DNSKEY RRset. C is still
>> a stand-by key and does not necessarily need to sign the DNSKEY
>> set. C will still be added to the validator in the AddPend state.
>>
>> When B is revoked, you do want to sign with both B and C: B to
>> self-sign (Br) and C to sign the DNSKEY RRset.
>
> It depends.  If A is still sacrosanct - then the usual incantation
> for the owner will be  "A and B sign (A Br C Z)" where C is a new
> trust anchor and Z is the ZSK.    C becomes a standby trust anchor
> and doesn't have to actually sign the root DNSKEY RRSet until it's
> placed into active service.

The scenario above is for the attacker, he has no incentive of keep 
publishing A.

> For the attacker, trying to add a new trust anchor that he owns (N),
> the incantation is going to be "B and N sign (B N X)" where X is a
> ZSK owned by the attacker.
>
> The attacker - if all he holds is B - can't sign Br until after the
> Add Holddown period expires if he's trying to add a new attacker
> owned trust anchor.
>
>
>
>>> With respect to the relying party - he doesn't know and can't
>>> tell - who originated the DNSKEY and signature data he's seeing.
>>> It's a crap shoot as to which version of the "truth" (owner or
>>> attacker) he sees.  The 5011 model is designed to make it as
>>> difficult as possible for an attacker to feed its version of
>>> truth to a specific validating resolver for a long enough period
>>> of time so that resolver installs a new trust anchor AND never
>>> sees the revocation of the compromised trust anchor.
>>>
>>>
>>>>>> Immediately after the relying party has seen (2), B can
>>>>>> never be
>>>> trusted again, even while they are waiting for the hold-down
>>>> timer for adding C.
>>>>>
>>>>> Revocation takes place immediately.  Once the bit is set and
>>>>> validly
>>>> signed, the key is revoked and can't be used for anything
>>>> except signing the revocation.  So in B and C sign (Br C), the
>>>> signature over the keys by B only has impact on Br,  The
>>>> signature by C over the keys only has impact if C has already
>>>> been added to the validators trust anchor set.
>>>>
>>>> Yup.
>>>>
>>>>>> Later in Section 2.2, it says:
>>>>>>
>>>>>> In the given example, the zone owner can recover from a
>>>>>> compromise by revoking B and adding a new key D and signing
>>>>>> the DNSKEY RRSet with both A and B.
>>>>>>
>>>>>> The time progression here sounds like: 1: Owner's zone: A
>>>>>> signs (A B) 2a: Attacker's zone: B signs (A Br C) 2b:
>>>>>> Owner's zone: B signs (Br) and A signs (A D) and B signs (A
>>>>>> D) 2a happens before 2b because that is how the owner
>>>>>> discovers that B
>>>> was compromised.
>>
>> I think the time progression is as follows:
>>
>> 1a:  Owner's zone: A signs (A B) 1b:  Attacker's zone: B signs (B
>> C) 2a:  Owner's zone: A and B signs (A Br D) 2b:  Attacker's zone:
>> B and C signs (Br C)
>>
>> The owner should do step 2a before the attacker is able to do 2b.
>
>
> Right, but 2a can happen as soon as the owner notices something hinky
> with the zone or suspects a compromise.  2b can't happen until 1b has
> been out in the wild for the entire Add Holddown time otherwise the
> attacker is throwing away its only mechanism for installing new trust
> anchors.

Correct.

>>> Yes, D is the owner's replacement for B.    I don't name the keys
>>> as "C" and "D" in section 6.1, but that's what's happening.
>>>
>>> You used "C" as the "Attacker's new trust anchor" in this series
>>> of messages.  I probably would have used something more disjoint
>>> in the explanation.
>>>
>>>
>>> So to clarify.
>>>
>>> 1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand
>>> for any of the regularly generated ZSKs) 2) B is a stand by key -
>>> it's a trust anchor, but not used for regular quarterly signing
>>> 3) The normal DNSKEY RRSet is "A signs (A Z)"
>>
>> Since B is a standby key, it should be "A signs (A B Z)"
>
>
> No.  Once B is added as a trust anchor, it need not be included in
> the root DNSKEY RRSet.   If B is not signing anything, there is no
> reason to include it.

That depends on your key rollover mechanism. In the Double-DS rollover, 
you don't need to add B, in Double-KSK and Double-Signature you do.

But if you want B to keep as a trust anchor at the validator, you better 
leave it in the DNSKEY RRset, otherwise it goes to the `Missing` state, 
an abnormal state. That can't be good.

In the Autotrust implementation, missing trust anchors will be removed 
after a (fairly long) time, otherwise we might end up with a bunch of 
valid, but missing, trust points which are no longer in use. That sounds 
like a weakness in the system.

>>> 4) If A or B is compromised then generate a new key pair C 5)
>>> Assuming A is compromised issue a new RRSET  "A and B sign (Ar B
>>> C Z)"  and propagate that for twice the add hold down time.  (the
>>> add hold down time to get the bits set, the additional time to
>>> pick up stragglers - the additional time is just suspenders and
>>> belt) 6) Once you've done (5) for long enough, issue a new
>>> "normal" RRSET "B signs (B Z)".  C is now a standby key.
>>
>> 6) should be "B signs (B C Z)".
>
>
> Same thing as above.  Once C is a trust anchor, unless its actively
> signing something, there's no need to include it in the DNSKEY RRSet.
> [However, you increase the "take" rate for resolvers the longer you
> leave it there - especially if there are intermittently connected
> resolvers]

Same thing as above. You want to keep it in the DNSKEY RRset, or the 
validator will mark the trust anchor as `Missing`.

> Keys enter the trust anchor set only by being present in the root
> DNSKEY RRSet and signed by a previous trust anchor for a minimum
> period of time (the Add Hold Down).   Keys leave the trust anchor set
> only through revocation.

Right, and to me that sounds like a weakness. Missing trust points 
should be cleaned up too.

Best regards,
   Matthijs

>
> Mike
>
>
>
>
>
>
>> Best regards, Matthijs
>
>

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Matthijs Mekking | 13 Oct 10:59 2014

Re: How are people implementing hold-down in RFC 5011?

Hi,

On 09-10-14 18:46, Michael StJohns wrote:
> At 07:57 PM 10/7/2014, Paul Hoffman wrote:
>> Thanks for the clarifications. I still have a bunch of questions, and
>> I really do wonder if implementers agree with your interpretations.

I have implemented this (http://nlnetlabs.nl/projects/autotrust/) and I 
agree with Michael's interpretations (even if it was after an hour 
asking questions at some past IETF).

I am trying to clarify below, although most stuff seems already 
straighted out.

>> On Oct 7, 2014, at 1:03 PM, Michael StJohns <mstjohns <at> comcast.net> wrote:
>>
>> > At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>> >> Greetings. In reading RFC 5011 more carefully, I am finding that
>> some of the wording is confusing (possibly just to me). I have a few
>> questions for people who have implemented it in systems, but also want
>> to hear from the greater DNS community.
>> >>
>> >> Section 2.2 says:
>> >>
>> >>  Assume two trust point keys A and B.  Assume that B has been
>> >>  compromised.  An attacker could generate and add a new trust anchor
>> >>  key C (by adding C to the DNSKEY RRSet and signing it with B), and
>> >>  then invalidate the compromised key.  This would result in both the
>> >>  attacker and owner being able to sign data in the zone and have it
>> >>  accepted as valid by resolvers.
>> >>
>> >> I am assuming that "invalidate" means "revoke".
>> >
>> > Yes.
>> >
>> >> Pictorially, I think this means the following progression in time:
>> >>  1: Owner's zone: A signs (A B)
>> >>
>> >
>> > 1.5 Attacker's zone: B signs (B C)
>> > (This has to happen for the Add Hold down time until C becomes a
>> valid trust anchor.  In general this is going to be B and C sign (B,
>> C) for the hold down period).
>>
>> There is nothing in the quoted paragraph from the RFC that indicates
>> that the attacker gets C to be a valid trust anchor. It sounds like
>> you meant to say "the attack is only going to work if a relying party
>> trust C, and that will only happen after the hold-down period, so the
>> attacker first introduces C, then only that has succeeded for some
>> desired targets, revokes B".
>
>
> The add hold down time is meant to provide some breathing room for the
> owner against an attacker adding a new trust anchor.  If the attacker
> holds only one key (B), and the owner doesn't revoke it, then eventually
> the attacker can add a new trust anchor (C).  The incantation for the
> attacker is "B and C sign (B C X)" where X is a ZSK key owned by the
> attacker.   The moment that the owner sees something it hasn't itself
> signed, signed with B, then the owner should issue "A and B sign (A, Br,
> D, Z)" where D is the owner's replacement for B and where Z is a ZSK key
> owned by the owner.
>
> Any SEP key can become a trust anchor if it is validly signed and is in
> the DNSKEY RRSet for the add hold down time (plus one retrieval).

All above seems pretty clear.

>> >
>> >> 2: Attacker's zone: B signs (A Br C)
>> >> (Here, "Br" means "B with the REVOKE bit set".)
>> >
>> > 2 is actually B and C sign (Br C).
>>
>> When the RFC says "and signing it with B", it might be clearer if it
>> says "and signing it with B and C". It is far from clear which
>> messages from the attacker are for public consumption (which would be
>> seen by the zone owner) and which are meant for restricted relying
>> parties.
>
> That's not actually a matter of concern for the zone owner. The
> incantation to revoke a key K is "K signs (Kr)".  As I noted elsewhere,
> you can't actually have multiple disjoint DNSKEY RRSets for a given
> name, so that you end up doing a union of all the keys to be signed into
> a single DNSKEY RRSet and you provide signatures by all signers over all
> the keys.

When the RFC says "and signing it with B" in section 2.2 Add Hold-Down, 
it talks about adding C to the DNSKEY RRset. C is still a stand-by key 
and does not necessarily need to sign the DNSKEY set. C will still be 
added to the validator in the AddPend state.

When B is revoked, you do want to sign with both B and C: B to self-sign 
(Br) and C to sign the DNSKEY RRset.

> With respect to the relying party - he doesn't know and can't tell - who
> originated the DNSKEY and signature data he's seeing.  It's a crap shoot
> as to which version of the "truth" (owner or attacker) he sees.  The
> 5011 model is designed to make it as difficult as possible for an
> attacker to feed its version of truth to a specific validating resolver
> for a long enough period of time so that resolver installs a new trust
> anchor AND never sees the revocation of the compromised trust anchor.
>
>
>> >> Immediately after the relying party has seen (2), B can never be
>> trusted again, even while they are waiting for the hold-down timer for
>> adding C.
>> >
>> > Revocation takes place immediately.  Once the bit is set and validly
>> signed, the key is revoked and can't be used for anything except
>> signing the revocation.  So in B and C sign (Br C), the signature over
>> the keys by B only has impact on Br,  The signature by C over the keys
>> only has impact if C has already been added to the validators trust
>> anchor set.
>>
>> Yup.
>>
>> >> Later in Section 2.2, it says:
>> >>
>> >>  In the given example, the zone owner can recover from a compromise by
>> >>  revoking B and adding a new key D and signing the DNSKEY RRSet with
>> >>  both A and B.
>> >>
>> >> The time progression here sounds like:
>> >>  1: Owner's zone: A signs (A B)
>> >>  2a: Attacker's zone: B signs (A Br C)
>> >>  2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D)
>> >> 2a happens before 2b because that is how the owner discovers that B
>> was compromised.

I think the time progression is as follows:

1a:  Owner's zone: A signs (A B)
1b:  Attacker's zone: B signs (B C)
2a:  Owner's zone: A and B signs (A Br D)
2b:  Attacker's zone: B and C signs (Br C)

The owner should do step 2a before the attacker is able to do 2b.

>> >
>> > What happens at a validator depends on what the validator sees.  In
>> general this goes:
>> >
>> > A Signs (A B)
>> > B is compromised
>> > Owner:  A and B sign (A Br D) - B is revoked and D starts its
>> process of being added as a trust anchor.
>> > Attacker:  B signs (B C)
>> >
>> > The key point is that if the validator sees even one of the "A and B
>> sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail
>> validation leading to C not being added to the trust anchor set.
>>
>> Yes, that's clearly the intent, and it should work (assuming that the
>> resolver follows the "revoke B as soon as you see a B-signed-Br
>> anywhere" rule).
>
>
> I can't help it if they don't read the black and white text of 5011.
>
>
>
>>     A key is
>> considered revoked when the resolver sees the key in a
>>     self-signed RRSet and the key has the REVOKE bit (see
>> Section 7  <http://tools.ietf.org/html/rfc5011#section-7>
>>     below) set to '1'.  Once the resolver sees the REVOKE
>> bit, it MUST
>>     NOT use this key as a trust anchor or for any other purpose
>> except to
>>     validate the RRSIG it signed over the DNSKEY RRSet
>> specifically for
>>     the purpose of validating the revocation.  Unlike the
>> 'Add' operation
>>     below, revocation is immediate and permanent upon receipt of
>> a valid
>>     revocation at the
>> resolver.
>
>
>
>> >> I don't understand why B signs (A D) in 2b. B is already untrusted
>> to anyone who saw 2a, and is untrusted by anyone looking at all of 2b.
>> These instructions seem to be saying "put a signature into the zone
>> that cannot be validated". I would think that 2b should just be "B
>> signs (Br) and A signs (A D)", but that's not what the RFC says.
>> >
>> > You can't actually have two different versions of the DNSKEY RRSet
>> being simultaneously offered by a single responder.  You *can* have
>> multiple signatures over a single DNSKEY RRSet.
>> >
>> > So the above is actually "A and B sign (A Br D)". It's also actually
>> more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs.
>> So you get "B signs Br to revoke itself", "A signs D to add D to the
>> trust anchor set" and "A signs Z so that Z chains to the root of trust".
>> >
>> > That's expressed by a DNSKEY RRSet consisting of B with the revoke
>> bit, D with the SEP bit and Z without the SEP bit with two
>> RRSIG(DNSKEY) records consisting of a signature by A and  a signature
>> by B.
>>
>>
>> On Oct 7, 2014, at 1:10 PM, Michael StJohns <mstjohns <at> comcast.net> wrote:
>>
>> > Sorry -
>> >
>> > This is actually "A and B sign (A Br D and Z)".
>> >
>> > A signing key needs to be included in the DNSKEY RRSet even if its
>> already accepted as a trust anchor.  That's mainly so the key id
>> reference of the RRSIG (DNSKEY) can find the appropriate public key
>> for validation.
>>
>> Why D? Is it a replacement for B because 5011 works better with more
>> than one trust anchor? I didn't see anything in the section that
>> explained D, and from what you say above, it looks like I guessed
>> wrong the first time.
>
>
> Yes, D is the owner's replacement for B.    I don't name the keys as "C"
> and "D" in section 6.1, but that's what's happening.
>
> You used "C" as the "Attacker's new trust anchor" in this series of
> messages.  I probably would have used something more disjoint in the
> explanation.
>
>
> So to clarify.
>
> 1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any
> of the regularly generated ZSKs)
> 2) B is a stand by key - it's a trust anchor, but not used for regular
> quarterly signing
> 3) The normal DNSKEY RRSet is "A signs (A Z)"

Since B is a standby key, it should be "A signs (A B Z)"

> 4) If A or B is compromised then generate a new key pair C
> 5) Assuming A is compromised issue a new RRSET  "A and B sign (Ar B C
> Z)"  and propagate that for twice the add hold down time.  (the add hold
> down time to get the bits set, the additional time to pick up stragglers
> - the additional time is just suspenders and belt)
> 6) Once you've done (5) for long enough, issue a new "normal" RRSET "B
> signs (B Z)".  C is now a standby key.

6) should be "B signs (B C Z)".

Best regards,
   Matthijs

> In practice, it may take a little time to get folks together for the key
> ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B
> sign (Ar B Z)" for a few days.  [Which by itself suggests a need to be
> able to do signatures without having everyone physically present]
>
>
> In the above, the attacker's only ploy is to do "A signs (A N X)" where
> N is a new trust anchor key owned by the attacker and X is a new ZSK
> also owned by the attacker.  His hope is that the validly signed (by
> compromised key A) RRSet gets accepted for a short while by specific
> targets and maybe long enough to get a new trust anchor key accepted by
> those specific targets.
>
>
>> --Paul Hoffman
>
>
>
> _______________________________________________
> dnsext mailing list
> dnsext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Michael StJohns | 7 Oct 22:03 2014
Picon
Picon

Re: How are people implementing hold-down in RFC 5011?

At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing
(possibly just to me). I have a few questions for people who have implemented it in systems, but also want to
hear from the greater DNS community.
>
>Section 2.2 says:
>
>   Assume two trust point keys A and B.  Assume that B has been
>   compromised.  An attacker could generate and add a new trust anchor
>   key C (by adding C to the DNSKEY RRSet and signing it with B), and
>   then invalidate the compromised key.  This would result in both the
>   attacker and owner being able to sign data in the zone and have it
>   accepted as valid by resolvers.
>
>I am assuming that "invalidate" means "revoke". 

Yes.  

>Pictorially, I think this means the following progression in time:
>   1: Owner's zone: A signs (A B)
>   

1.5 Attacker's zone: B signs (B C)
(This has to happen for the Add Hold down time until C becomes a valid trust anchor.  In general this is going to
be B and C sign (B, C) for the hold down period).

>2: Attacker's zone: B signs (A Br C)
>(Here, "Br" means "B with the REVOKE bit set".)

2 is actually B and C sign (Br C).

>Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting
for the hold-down timer for adding C.

Revocation takes place immediately.  Once the bit is set and validly signed, the key is revoked and can't be
used for anything except signing the revocation.  So in B and C sign (Br C), the signature over the keys by B
only has impact on Br,  The signature by C over the keys only has impact if C has already been added to the
validators trust anchor set.

>Later in Section 2.2, it says:
>
>   In the given example, the zone owner can recover from a compromise by
>   revoking B and adding a new key D and signing the DNSKEY RRSet with
>   both A and B.
>
>The time progression here sounds like:
>   1: Owner's zone: A signs (A B)
>   2a: Attacker's zone: B signs (A Br C)
>   2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D)
>2a happens before 2b because that is how the owner discovers that B was compromised.

What happens at a validator depends on what the validator sees.  In general this goes:

A Signs (A B)
B is compromised
Owner:  A and B sign (A Br D) - B is revoked and D starts its process of being added as a trust anchor.
Attacker:  B signs (B C)

The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B
signs (B C)" will fail validation leading to C not being added to the trust anchor set.

>I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by
anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot
be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the
RFC says.

You can't actually have two different versions of the DNSKEY RRSet being simultaneously offered by a
single responder.  You *can* have multiple signatures over a single DNSKEY RRSet.

So the above is actually "A and B sign (A Br D)".  It's also actually more like "A and B sign (Br D and Z)" where "Z"
is one of the ZSKs.  So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A
signs Z so that Z chains to the root of trust".  

That's expressed by a DNSKEY RRSet consisting of B with the revoke bit, D with the SEP bit and Z without the SEP
bit with two RRSIG(DNSKEY) records consisting of a signature by A and  a signature by B.

Mike

>So: has anyone implemented what the RFC says? If so, did you try it with some validating resolvers? What
were the results?
>
>Or: am I completely misreading something in this section?
>
>--Paul Hoffman
>_______________________________________________
>dnsext mailing list
>dnsext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/dnsext

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext


Gmane