Re: BIND9 DNSSEC algorithm rollover for inline-signed zone

[Jim Popovitch]

On Mon, Oct 10, 2016 at 7:51 AM, Sebastian Wiesinger
 wrote:
>
> http://dnsviz.net/d/blau.beer/V_tTtQ/dnssec/
>
> After the DS TTL expired I removed the old DS, so the zone now looks
> like this:
>
> http://dnsviz.net/d/blau.beer/V_t2Hg/dnssec/
>

TBH, the prior one looks cooler than the later.

-Jim P.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND9 DNSSEC algorithm rollover for inline-signed zone

[Sebastian Wiesinger]

* Tony Finch  [2016-10-10 12:36]:
> I thought the algorithm rollover process is required to be: introduce new
> ZSK and KSK and sign the zone; wait for old records to expire; flip the DS
> from old to new; wait for old DS to expire; delete old ZSK and KSK and
> RRSIGs. A double-DS algorithm rollover will cause your zone to go bogus.

I did the "double DS" approach, first publish new KSK/ZSK, wait for
Zone TTLs, then a second DS was introduced. The zone looked like this:

http://dnsviz.net/d/blau.beer/V_tTtQ/dnssec/

After the DS TTL expired I removed the old DS, so the zone now looks
like this:

http://dnsviz.net/d/blau.beer/V_t2Hg/dnssec/

Last step will be after DS TTL expires (again) removing the old KSK
and ZSK.

It seems to work. After doing this I discovered that the .tz TLD did
it the same way:

https://singapore52.icann.org/en/schedule/mon-tech/presentation-ksk-algorithm-09feb15-en.pdf

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND9 DNSSEC algorithm rollover for inline-signed zone

[Tony Finch]

Mark Andrews  wrote:
> Sebastian Wiesinger  wrote:
> >
> > Thank you for explaining this for me. I was reading RFC6781, which I
> > now realize is probably outdated in this regard so I was a bit
> > confused.

RFC 7583 (DNSSEC Key Rollover Timing) is also worth reading.

> > > Once named has completed signing the zone with the new algorithm
> > > and all the slaves have the fully signed zone and the caches have
> > > expired any RRsets which are only signed with the old algorithm you
> > > can add DS records for the new algorithm for the zone.
> >
> > This only applies when I change the DS record, right? I assume that I
> > can add the new one instantly and remove the old one later when all
> > caches have expired the old data.
>
> There are always timing considerations with DNSSEC.  You prepublish
> DS records or you have multiple KSKs.  You have multiple signatures
> or you have multiple ZSKs.  It's all about having what you need to
> validate available regardless of when the records are learnt or from
> where.

It is (was?) my understanding that validators are supposed to check that
the DNSKEY RRSIGs include at least all of the algorithms present in the DS
RRset. This is to protect against RRSIG-stripping downgrade attacks.

However RFC 6840 (DNSSEC Clarifications) section 5.11 says

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.  A validator
   MAY have a configuration option to perform a signature completeness
   test to support troubleshooting.

which is weaker than I thought it was.

I thought the algorithm rollover process is required to be: introduce new
ZSK and KSK and sign the zone; wait for old records to expire; flip the DS
from old to new; wait for old DS to expire; delete old ZSK and KSK and
RRSIGs. A double-DS algorithm rollover will cause your zone to go bogus.

This page has a pretty good description of the whys and wherefores, what
Unbound's validator requires, and what its algorithm rollover bug was:
https://unbound.net/documentation/info_algo.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or
moderate. Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND9 DNSSEC algorithm rollover for inline-signed zone

[Mark Andrews]

In message <20161007164742.ga18...@danton.fire-world.de>, Sebastian Wiesinger 
writes:
> * Mark Andrews  [2016-10-06 23:33]:
> > > is there a guide for an algorithm rollover with BIND9 for an
> > > inline-signed zone? I want to roll from RSA to ECDSA but I'm unable to
> > > find a good guide for it. I already looked at the ISC DNSSEC Guide but
> > > it doesn't seem to cover that the RRSIGs made by the new keys need to
> > > be published before the DNSKEYs themselves are published in the zone.
> > 
> > Because there is no such requirement.  Just create the keys in the
> > new algorithm and let named sign the zone.
> > 
> > The DNSSEC RFC's were written with rules for zone publishers and
> > rules for zone validators.  These were designed to around the fact
> > that the DNS is loosely coherent and that you can't update everything
> > simultaneously.  That means thay you can expect that you won't find
> > signatures for every alorithm in the DNSKEY RRset in the answers.
> 
> Thank you for explaining this for me. I was reading RFC6781, which I
> now realize is probably outdated in this regard so I was a bit
> confused.

There are multiple mechanisms.  A implementation doesn't have to
support all of them.  Prepublishing RRSIGs before publishing DNSKEYs
was not part of the design of DNSSEC.

> > Once named has completed signing the zone with the new algorithm
> > and all the slaves have the fully signed zone and the caches have
> > expired any RRsets which are only signed with the old algorithm you
> > can add DS records for the new algorithm for the zone.
> 
> This only applies when I change the DS record, right? I assume that I
> can add the new one instantly and remove the old one later when all
> caches have expired the old data.

There are always timing considerations with DNSSEC.  You prepublish
DS records or you have multiple KSKs.  You have multiple signatures
or you have multiple ZSKs.  It's all about having what you need to
validate available regardless of when the records are learnt or from
where.


> Regards
> 
> Sebastian
> 
> -- 
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND9 DNSSEC algorithm rollover for inline-signed zone

[Sebastian Wiesinger]

* Mark Andrews  [2016-10-06 23:33]:
> > is there a guide for an algorithm rollover with BIND9 for an
> > inline-signed zone? I want to roll from RSA to ECDSA but I'm unable to
> > find a good guide for it. I already looked at the ISC DNSSEC Guide but
> > it doesn't seem to cover that the RRSIGs made by the new keys need to
> > be published before the DNSKEYs themselves are published in the zone.
> 
> Because there is no such requirement.  Just create the keys in the
> new algorithm and let named sign the zone.
> 
> The DNSSEC RFC's were written with rules for zone publishers and
> rules for zone validators.  These were designed to around the fact
> that the DNS is loosely coherent and that you can't update everything
> simultaneously.  That means thay you can expect that you won't find
> signatures for every alorithm in the DNSKEY RRset in the answers.

Thank you for explaining this for me. I was reading RFC6781, which I
now realize is probably outdated in this regard so I was a bit
confused.

> Once named has completed signing the zone with the new algorithm
> and all the slaves have the fully signed zone and the caches have
> expired any RRsets which are only signed with the old algorithm you
> can add DS records for the new algorithm for the zone.

This only applies when I change the DS record, right? I assume that I
can add the new one instantly and remove the old one later when all
caches have expired the old data.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND9 DNSSEC algorithm rollover for inline-signed zone

[Mark Andrews]

In message <20161006205713.ga1...@danton.fire-world.de>, Sebastian Wiesinger wr
ites:
> Hello,
> 
> is there a guide for an algorithm rollover with BIND9 for an
> inline-signed zone? I want to roll from RSA to ECDSA but I'm unable to
> find a good guide for it. I already looked at the ISC DNSSEC Guide but
> it doesn't seem to cover that the RRSIGs made by the new keys need to
> be published before the DNSKEYs themselves are published in the zone.

Because there is no such requirement.  Just create the keys in the
new algorithm and let named sign the zone.

The DNSSEC RFC's were written with rules for zone publishers and
rules for zone validators.  These were designed to around the fact
that the DNS is loosely coherent and that you can't update everything
simultaneously.  That means thay you can expect that you won't find
signatures for every alorithm in the DNSKEY RRset in the answers.

One DNSSEC vendor tried to check that there were signatures for
every algorithm in the DNSKEY RRset but was told they were wrong
to do so.  That was a rule for zone publishers not validators.  That
vendor has since fixed their code.

Named behaves as if it is a loosely coherent anycast cluster when
it is signing a zone for the first time with a given algorithm.
This means you will see answers without signatures for all of the
algorithms while it is is the process of signing the zone with a
algorithm for the first time.

Once named has completed signing the zone with the new algorithm
and all the slaves have the fully signed zone and the caches have
expired any RRsets which are only signed with the old algorithm you
can add DS records for the new algorithm for the zone.

Mark

> Regards
> 
> Sebastian
> 
> -- 
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYT
> HE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users