In message <20161125115823.747eb...@pallas.home.time-travellers.org>, Shane Ker
r writes:
> Mark,
>
> At 2016-11-16 08:39:37 +1100
> Mark Andrews <ma...@isc.org> wrote:
>
> > In message <20161116000530.19ed4...@pallas.home.time-travellers.org>,
> Shane Kerr writes:
> > > Dan,
> > >
> > > At 2016-11-15 12:41:01 +0000
> > > Dan York <y...@isoc.org> wrote:
> > > > The draft is at either of:
> > > >
> > > > https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-cryptoalgs/
> > > > https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04
> > > >
> > > > Please send any comments to the list or to us as authors.
> > > >
> > > > I also am maintaining this over in Github at:
> > > > https://github.com/danyork/draft-deploying-dnssec-crypto-algs If you
> > > > are a Github user you are welcome to file an issue there or send text
> > > > in a pull request.
> > > >
> > > > Regardless, we'd just like any feedback (even if to say that it looks
> > > > good).
> > >
> > > I'm curious about this section:
> > >
> > > Note that the key and signatures with the new algorithm will need to
> > > co-exist with the existing key and signatures for some period of
> > > time. This will have an impact on the size of the DNS records.
> > >
> > > [NOTE(OS): Shouldn't we just update the language that requires the
> > > resolver to be so strict and finally be done with this requirement?
> > > Or just give a recommendation in the paragraph on resolver here?]
> > >
> > > One issue that has been identified is that not all commonly-used
> > > signing software releases include support for an algorithm rollover.
> > > This software would need to be updated to support rolling an
> > > algorithm before any new algorithms could be deployed.
> > >
> > > Is there an RFC which says that you have to have multiple signatures?
> > > In principle, shouldn't it be possible to (for example) add a new
> > > DNSKEY record of a ZSK with a new algorithm, wait until you are sure
> > > that all resolvers have the new DNSKEY, and then start signing using
> > > only that key (as for a usual roll)?
> >
> > You either have double signature (new alg + old alg) or you go
> > insecure. Adminstrators choice. Remember that you have to have
> > the new signatures and DNSKEYs in place before the DS is published
> > for the new algorithm and you need to keep the old signatures and
> > DNSKEYs in place after the DS for the old algorithm is removed.
>
> Sorry for being stupid and ignorant here, but again, is there an RFC
> which says you need multiple signatures?
Yes. RFC4035 and RFC6840. Note the words "entire zone". You can't
have two algorithm is use without multiple signatures for each RRset
in the zone.
5.11. Mandatory Algorithm Rules
The last paragraph of Section 2.2 of [RFC4035] includes rules
describing which algorithms must be used to sign a zone. Since these
rules have been confusing, they are restated using different language
here:
The DS RRset and DNSKEY RRset are used to signal which algorithms
are used to sign a zone. The presence of an algorithm in either a
zone's DS or DNSKEY RRset signals that that algorithm is used to
sign the entire zone.
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. It is possible to add algorithms at
the DNSKEY that aren't in the DS record, but not vice versa. If
more than one key of the same algorithm is in the DNSKEY RRset, it
is sufficient to sign each RRset with any subset of these DNSKEYs.
It is acceptable to sign some RRsets with one subset of keys (or
key) and other RRsets with a different subset, so long as at least
one DNSKEY of each algorithm is used to sign each RRset.
Likewise, if there are DS records for multiple keys of the same
algorithm, any subset of those may appear in the DNSKEY RRset.
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.
> I understand that you need multiple signatures on the DNSKEY RRset
> itself, but surely you don't actually need to sign the whole zone with
> multiple signatures? Once I am sure that every validator has the DNSKEY
> RRset with the old and the new DNSKEY ZSK, then I should be able to
> choose either ZSK and use that to sign, right? Why is this different in
> an algorithm roll versus a normal roll?
The aim of the rules are to ensure that if the validator only supports
a single algorithm in the validator that you will have the data
necessary to validate the response if it has cyptographic proof (DS)
that the zone is signed with a algorithm it supports and it has a
chain of trust.
> > > A possibly more important concern is that the RIPE NCC did an algorithm
> > > roll last year, and discovered that Unbound and Verisign DNS require
> > > that the algorithm used by the DS be used to sign the entire zone - not
> > > just the DNSKEY RRSET:
> >
> > That was always required.
>
> Sorry, I'm confused. So the algorithm used by the DS has to sign the
> whole zone? Does that mean that Unbound and Verisign DNS had correct
> behavior and it is now broken? Does that mean that BIND is broken?
No. Unbound and Verisign DNS over stepped the mark. There is the
supply side and the consumption side. The rules are for the supply
side only. RIPE NCC failed to follow the supply side rules.
You can follow all the rules in RFC 4035 and because the DNS is a
loosely coherent system, you can get a DNSKEY RRset and some other
RRset from the same zone (but not instance) where there are not
RRSIGs for one or more of the algorithms in the DNSKEY RRset. As
a zone in only deemed to be signed by a algorithm when it is listed
in the DS RRset (or published trust anchors) this is not (or should
not have been) a issue. It was only when Unbound and Verisign DNS
started enforcing supply side rule in the validator that it became
a issue.
> So confused...
>
> > > https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over
> > >
> > > I think this deserves special merit and probably mention in the draft,
> > > because it means that you have to do both the KSK and ZSK roll
> > > together. The root cause of this is probably considered a bug in the
> > > Unbound and Verisign DNS software and has been fixed... but also
> > > consider that Unbound is a fairly popular DNS software and likely to
> > > have lots of old versions lying around. That means basically that
> > > unless you don't care about breaking a large portion of the Internet we
> > > are stuck with this limitation. :(
> > >
> > > Of course, rolling to a brand new algorithm (post-2015) that arrives in
> > > the future should be fine, since it will only be implemented in newer
> > > versions of the software which support rolling properly. :)
> >
> > I'm not worried about old versions with broken validators. Let
> > them break. When the few reports come in tell them to upgrade to
> > a current version. To work with those old, non RFC compliant,
> > versions you have to publish RRSIGs before you publish DNSKEYs and
> > ISC is not going to hack named to support such behaviour.
>
> Mark, I certainly encourage you to not worry about broken resolvers in
> your own systems. I don't for my own vanity domains.
>
> But surely you can see how this might not be acceptable to other
> people, right? Surely? Like people may actually have reasons why they
> want to make sure their sites are available to as many people as
> possible? Surely?
For how many years should we continue to pander operators using
broken software that has been fixed by the vendor years ago.
Mark
> > They don't interoperate and should have CVEs listed against those
> > versions.
> >
> > > ----
> > >
> > > Finally, mostly as a whine, it's a pity that RFC 6975 forbids
> > > authoritative servers from filtering RRSIG. From a client point of
> view
> > > this would have been a real motivator to including this information,
> > > since an authoritative server could provide the best signatures
> > > possible (smallest/fastest/most secure/patent-free/whatever), and ONLY
> > > those signatures.
> >
> > There are good reasons not to filter RRSIGs. If validators want
> > to only use alg A when alg A and alg B are present in the DS records
> > they are free to write a validator that supports that.
>
> Again, I am confused.
>
> If a validator says "I only support algorithm A", then what reason is
> there to send it signatures for algorithm B?
>
> I can't think of a good reason not to filter RRSIGs, although I fully
> admit that my imagination may just not be up to the task.
>
> Cheers,
>
> --
> Shane
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
