On Tue, 5 Jan 2021, Ben Schwartz wrote:
One thing I found surprising here is that RFC 6840 Section 5.11 says
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.
If a validator has more confidence in Algorithm A than Algorithm B, it's
frustrating for it to be required to accept a B signature when
Algorithm A indicates that the record is Bogus. Do validators actually behave
this way, checking each signature until they find a valid one?
Perhaps if we updated RFC 6840 to indicate that validators should validate only
the most-preferred available signature (or indeed insist that
all supported signatures are valid), that would reduce the level of concern
here. Zones and resolvers could add more algorithms with no risk of
weakening their security posture.
But it is the zone owner that declares what is acceptable to them for
their domain, by using DS records of the type they want. Why should a
resolver override that?
Also, you would end up building a list of algorithms from worst to best.
This is not always obvious. Sure, the SHA1 vs SHA2 is obvious. Would you
prefer a NIST ECC curve over a GOST ECC curve or not?
DNS RFC's stick to the rule that validators should not be in the space
of determining which crypto algorithm is preferred.
Paul
On Tue, Jan 5, 2021 at 3:24 AM Василий Долматов <vdolma...@gmail.com> wrote:
> 4 янв. 2021 г., в 19:20, Stephen Farrell <stephen.farr...@cs.tcd.ie>
написал(а):
>
>
> Hiya,
>
> On 04/01/2021 16:05, Paul Wouters wrote:
>> While asking is fair, you would also have to define what you
>> do based on the outcome of that ask. You left that out,
>
> I don't think I did omit that. My stated reason to ask was
> to help me figure out what I think about the draft named in
> the subject line. And yes, I do think that if a codepoint
> is being requested for a new version of an existing one
> then asking about how the existing one was used is a good
> thing to do. The case with gost and rsa+sha1/sha256 isn't
> the same because gost is a series of national standards.
>
> > As to answer your question, I believe GOST did not see
> > more than about 5 domains use it in what was clearly a
> > "Testing" deployment.
>
> Thanks. In that case, it sounds like it'd have been better
> to use a private or experimental code point for that kind
> of thing. OTOH, my understanding (based only on hallway
> chats over the years) was that the codepoint was allocated
> for political reasons. Either way, does that mean that a
> lot of effort to implement and test was wasted since that
> codepoint was allocated? If so, avoiding that in future
> would be good, if there's a way to do that.
The situation with GOST in DNSSEC is explainable and was explained
in the list during the discussion of another draft (and to you
personally, AFAIR,
maybe you’ve forgotten that).
To the time when RFC5933 was published and corresponding codepoint was
allocated
it has been known already that new version of underlying standards for
hash and signature were on the way,
so there were no reason to implement it immediately using standards which
will be obsoleted soon.
That explains why there were only several test implementations
performed, which were intended to check
smooth interoperability, if different algorithms were used in DNSSEC
validation chain, with even several
algorithms switches along the chain. The interoperability was proven and
results were presented on
one of the RIPE meetings.
Then the DNSSEC deployment in Russia went into «waiting state», waiting
for:
- new standards to be published in Russia
- reference implementations of it were created by different software
teams with interoperability checks
- making IETF community aware of them by publishing set of Informational
RFC
- «running code» was created for new standards in open-source software
(implementing it in OpenSSL for instance)
- assigning codepoints in DNSSEC registry
Now we are at the last step in this list, and after its completion we
consider that it will become possible to deploy GOST in
DNSSEC.
That explains why there is no wide deployment of GOST in DNSSEC until
now. We prefer slow-pace but reliable way forward.
Btw, the same way was passed for TLS now, after codepoints for GOST in
TLS has been assigned already, we have
several different implementations of TLS with GOST by different software
developer teams and we have a stand for TLS
interoperability check which is run by the team independent from any of
software vendors and performing the check that all
implementations are mutually compatible and aligned with the
corresponding RFCs.
This stand is used for the interoperability check of IPSEC
implementations also and will incorporate DNSSEC in its scope in proper
time.
dol@
>
> Cheers,
> S.
>
> PS: note that I'm neither supporting, nor objecting to,
> Paul's draft in the above.
>
>
>
<OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________
> 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
