Hi Libor,
Thanks for the time and feedback!
If you prefer the dry-run DS to have a static length maybe then you are
more interested in the dry-run equivalent algorithm per actual algorithm
timeline?
It would be interesting to know if your concern for static length arises
from a registry point of view (as also mentioned in section 5.1.1), or
something else.
Although security is unlikely to be an issue currently, it still means
that whichever number we choose today may not work in the future.
If collisions could happen then a dry-run zone could be spoofed.
Although that would not matter for the DNSSEC adoption case as the zone
was unsigned in the first place, the other cases (sections 3.1.2 and
3.1.3) would weaken the security of an already DNSSEC signed zone.
But apart from security, I am also worried about the extra steps needed
to handle the contents of the DS record and using it for DNSSEC (need to
also crop/stretch the key digests while validating).
I would prefer the DNSSEC part to be mostly intact when dry running so
that there is confidence on the reported results and expect the same
behavior when advancing from a dry-run state.
Do my concerns make sense?
Best regards,
-- Yorgos
On 13/07/2022 13:26, libor.peltan wrote:
Hi Willem, Yorgos, Roy, dnsop,
I dare to repeat my support for the ideas in dry-run-dnssec draft.
However, I still don't like the suggested format of dry-run DS record.
Another alternative idea: how about putting the Digest Type into the
first octet of Digest field like in the draft, but cropping (or
stretching) the rest of the actual digest in a way that the overall size
of the resulting Digest field is something "normal" (e.g. 32 octets),
and does not differ based on actual Digest Type? I assume that for
dry-run, the weakened actual security of cropped Digest is not a big deal.
Please consider my thought and employ/deny it as needed.
Best,
Libor
Dne 12. 07. 22 v 16:35 Willem Toorop napsal(a):
Dear dnsop,
We submitted a new version of a “dry-run DNSSEC” draft. The draft
describes a method that allows for testing DNSSEC deployments in real
world DNS(SEC) deployments without affecting the DNS service in case of
DNSSEC errors. Any encountered errors are signaled to the DNS operator
of the faulty zone with DNS Error Reporting
(draft-ietf-dnsop-dns-error-reporting).
This is a new idea which will be presented during dnsop at the IETF114
and was also presented at the IETF113. A recording of the IETF113
presentation is here: https://youtu.be/watch?v=7HxcmvFOnlU&t=3675s
Slides here:
https://datatracker.ietf.org/meeting/113/materials/slides-113-dnsop-dry-run-dnssec-01
We received a lot of feedback with our presentation which we used to
reorganize the draft to convey the idea more clearly and coherently. We
also received some critique and objections which were non-technical in
nature. Below is a list with these objections followed by our response.
** This is another straw on the camel’s back **
Not all resolvers have to support/implement it. Most important is that
provisioning at the registry and signaling of Dry-run is supported. If
needed we can say it is OPTIONAL for resolvers in the draft. We intend
to implement it ourselves in Unbound and have it enabled by default when
error reporting is enabled. We know from experience with trust-anchor
signaling and sentinel record that with only a small, up to date
resolver population, the signaling is already quite substantial.
There are different kinds of straws and this one is one that has the
good cause of enabling operators to deploy DNSSEC with confidence.
** Why not have a duplicate parallel test deployment? **
There is nothing better than testing with your actual user population to
dry-run your DNSSEC deployment. Note that slack’s parallel test
deployment did not show them the Route53 failure that caused them to
have an DNSSEC outage eventually[1]
** Why not sell DNSSEC domains cheaper? **
Yes, we’re all for that too, but that’s orthogonal to seeing what the
actual effect of starting DNSSEC with your deployment with your real
user population would be.
The other objections which were more technical, like for example
“registries supporting only fixed sized hashes per algorithm” and
“couldn’t we normalize the different DS hacks somehow” are all addressed
in the new version of the document.
We’re looking forward to a new round of feedback and critique ;)
Both on-list and in-person at the IETF-114!
Kind regards,
Yorgos, Willem and Roy
Op 11-07-2022 om 23:58 schreef internet-dra...@ietf.org:
A new version of I-D, draft-yorgos-dnsop-dry-run-dnssec-01.txt
has been successfully submitted by Yorgos Thessalonikefs and posted
to the
IETF repository.
Name: draft-yorgos-dnsop-dry-run-dnssec
Revision: 01
Title: dry-run DNSSEC
Document date: 2022-07-11
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.txt
Status:
https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/
Html:
https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec
Diff:
https://www.ietf.org/rfcdiff?url2=draft-yorgos-dnsop-dry-run-dnssec-01
Abstract:
This document describes a method called "dry-run DNSSEC" that allows
for testing DNSSEC deployments without affecting the DNS service in
case of DNSSEC errors. It accomplishes that by introducing a new DS
Type Digest Algorithm that signals validating resolvers that dry-run
DNSSEC is used for the zone. DNSSEC errors are then reported with
DNS Error Reporting, but any bogus responses to clients are
withheld.
Instead, validating resolvers fallback from dry-run DNSSEC and
provide the response that would have been answered without the
presence of a dry-run DS. A further option is presented for clients
to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC
testing.
The IETF Secretariat
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
