Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jan 2021 16:38:02 +0000

On Dec 31, 2020, at 2:09 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> On 31/12/2020 21:48, Eric Rescorla wrote:
>> 1. Don't allocate a code point at all
>> 2. Allocate the code point but in some manner that makes clear
>>    we don't endorse it (effectively what TLS does for algorithms
>>    like this)
>> 3. Allocate the code point without comment
> 
> FWIW, I kind of agree with ekr, both as to the options
> and on my current preference to not too easily loosen
> up for DNSSEC.

To be clear, the loosening that is being discussed is from making it "standards required" to "RFC required". (We briefly discussed going to "specification required", but there was little appetite for that.)

> That said, I wonder as to the actual deployment of algs
> that we'd not recommend, especially given the relative
> scarcity of DNSSEC signing.

Well, exactly. This discussion arose because a few Russian folks want the revised GOST algorithms to have a code point allocated. Currently, for them to do that, the IETF would have to put the new GOST algorithms on standards track. We did that for the last algorithm, but it is not clear if we want to do that again. 

> Does anyone have a pointer to survey-like material that
> has a focus on rarer algorithms in DNSSEC? One reason to
> ask is that from a first glance it looks to me like .ru
> isn't using gost, which would be telling, if correct.
> 
> To be clear: I don't think spending much time debating
> how to handle algs for an infinitesimal number of zones
> is that worthwhile, so that'd be another reason to prefer
> the status quo, if that is the case.

The status quo (standard required) will likely absorb a lot of time for the IETF if the WG decides to move the revised GOST forward. It will also probably land in the CFRG. Reducing the requirement to RFC required allows their document to be informational.

The WG already has RFC 8624 that talks about what implementers should do with various algorithms. Clearly, it will need to be updated for the revised GOST regardless of whether the WG changes the IANA considerations.

Also, as a reminder, this isn't only about GOST. In the coming years, there will be a raft of post-quantum signing algorithms with different signature and key size ratios that people will want adopted. Putting every one of them on standards track seems onerous to some of us.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 1 Jan 2021 16:53:13 +0000

Hiya,

I note that you didn't answer my question about actual use
of gost and guess that's because you don't have that data
to hand. I'm still interested in that if someone has info
because grounding this in reality seems likely better.

On 01/01/2021 16:38, Paul Hoffman wrote:
> The status quo (standard required) will likely absorb a lot of time
> for the IETF if the WG decides to move the revised GOST forward. It
> will also probably land in the CFRG. Reducing the requirement to RFC
> required allows their document to be informational.
> 
> The WG already has RFC 8624 that talks about what implementers should
> do with various algorithms. Clearly, it will need to be updated for
> the revised GOST regardless of whether the WG changes the IANA
> considerations.
> 
> Also, as a reminder, this isn't only about GOST. In the coming years,
> there will be a raft of post-quantum signing algorithms with
> different signature and key size ratios that people will want
> adopted. Putting every one of them on standards track seems onerous
> to some of us.
Sure, I get all that, but the trade-off is between our time
vs. some properties of the deployed DNS so it may or may not
be that us spending time is the better/cheaper option overall
even if that's a PITA for us. Personally I could more easily
figure out my position on this if I knew how much gost was
really in use. (If it's negligible, then one could argue that
moving the current gost alg to historic or something might be
the better option.)

Cheers,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jan 2021 17:58:36 +0000

> because grounding this in reality seems likely better.

Correct, I have no such data, but others might. The .ru domain (and other domains where GOST might have any traction) are not open for research.

> moving the current gost alg to historic or something might be

The WG has already adopted the revised GOST document as a WG item; what you are proposing (if the current use is negligible) would be in the opposite direction.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 1 Jan 2021 18:42:31 +0000

Hiya,

On 01/01/2021 17:58, Paul Hoffman wrote:
> The WG has already adopted the revised GOST document as a WG item;
> what you are proposing (if the current use is negligible) would be in
> the opposite direction.
I wasn't "proposing" that, just posing it as a possible
option that might or might not be sensible to consider
depending on the facts relating to usage if/when we can
get 'em. Absent usage information, I'm not at all sure
whether or not any change from the status quo is warranted.

Cheers,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 4 Jan 2021 12:31:16 +0100 (CET)

> Il 01/01/2021 19:42 Stephen Farrell <[email-masked]> ha scritto:
> 
>  
> Hiya,
> 

We could ask the proponents of new algorithms for information on current or expected usage. However, if adoption is relevant to any kind of decision on what to do with an algorithm proposal, this should better be formalized somewhere and applied evenly to all algorithms that may appear in the future. Personally, I think that some expectation of adoption would be useful not to clutter the list of algorithms, but the threshold should be quite low.

Also, as the IETF is the global SDO for DNS, it should make sure to encompass the needs of all Internet communities around the world. If a local community wants or needs for any reason to use a "globally non-standard" algorithm, there should be ways for this to happen without asking them to prove adoption of that algorithm on a global scale. Eric's points on fragmentation, implementation burden, potential incompatibilities are valid, but they should play out at usage level, not at the standardization one. We should just make it clear to proponents that adopting a rare algorithm may make them incompatible with the rest of the planet, but whether this is acceptable or not is up to them - and they may even not have a choice, due to non-technical factors which won't be affected by whether we recognize the algorithm or not. In this regard, having an intermediate "supported but not globally recommended" classification level, with lower procedural barriers, seems like a useful thing to me.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jan 2021 04:21:10 -0800

On Mon, Jan 4, 2021 at 3:31 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> We could ask the proponents of new algorithms for information on current
> or expected usage. However, if adoption is relevant to any kind of decision
> on what to do with an algorithm proposal, this should better be formalized
> somewhere and applied evenly to all algorithms that may appear in the
> future. Personally, I think that some expectation of adoption would be
> useful not to clutter the list of algorithms, but the threshold should be
> quite low.
>
> Also, as the IETF is the global SDO for DNS, it should make sure to
> encompass the needs of all Internet communities around the world. If a
> local community wants or needs for any reason to use a "globally
> non-standard" algorithm, there should be ways for this to happen without
> asking them to prove adoption of that algorithm on a global scale. Eric's
> points on fragmentation, implementation burden, potential incompatibilities
> are valid, but they should play out at usage level, not at the
> standardization one.

This seems to conflate standardization with code point assignment.
Standards are recommendations and our recommendation is that people use
particular algorithms. As the example of TLS shows, we can allow that
without standardizing those algorithms.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Jan 2021 13:03:15 +0000

Hiya,

On 04/01/2021 11:31, Vittorio Bertola wrote:
> We could ask the proponents of new algorithms for information on
> current or expected usage. 

WRT GOST, we're not really talking about an algorithm but
rather a national crypto standards scheme that selects sets
of algorithms. For such things, whether from Russia or the
US or anywhere, I think it's quite fair to ask "how has
version N deployment gone?" as part of considering how to
handle version N+1. Indeed, it'd seem wrong not to ask and
get an answer.

And "how to handle" isn't always "adoption" but could as
I said result in deprecating version N if nobody really
cares about it - in such a case that'd help implementers
and better reflect reality.

Cheers,
S.

> However, if adoption is relevant to any
> kind of decision on what to do with an algorithm proposal, this
> should better be formalized somewhere and applied evenly to all
> algorithms that may appear in the future. Personally, I think that
> some expectation of adoption would be useful not to clutter the list
> of algorithms, but the threshold should be quite low.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Jan 2021 09:23:23 -0500 (EST)

On Mon, 4 Jan 2021, Stephen Farrell wrote:

> version N deployment gone?"

Why is that fair? I'd say the community was quite busy and
possibly made some mistakes in the past. I don't think that
is a valid barrier for the future. For example, would we
bar NIST or the US from ever standarizing a new RNG? :P

> and better reflect reality.

If a national government wants something, we could ask for
at least one implementation to be planned. But using this
meassure as a way to stop these seems wrong. It would move
the possible standarization from IETF to say openssl or
bind.

I do think one issue is how often GOST (or FIPS) updates
their algorithms and obsoletes older ones. That might
cause a faster depletion of the registry then we'd like.

But on the other side, if would be nice if we could become
faster with obsoleting algorithms too. Why is there still
RSASHA1 deployed....

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Jan 2021 15:27:46 +0000

Hiya,

On 04/01/2021 14:23, Paul Wouters wrote:
> Why is that fair? 

Eh? Seems to me that asking about the facts is fair.
I have a hard time envisaging a way it could be unfair
tbh, so your question surprises me.

> I'd say the community was quite busy and

You seem to be assuming that the goal of asking is to
justify saying "no." That wasn't my intent - I just think
we make better decisions if we know the deployment facts,
rather than our decisions being based on whomever is
good at rhetoric or automatically giving nation-states
or mega-companies whatever they ask.

WRT a new RNG - yes if one was suggested from a US or
any source, then we absolutely should be very careful with
that. Mind you, I can't think of an iana registry that
has RNG algs as entries so maybe it's not a super-good
example.

> at least one implementation to be planned. 

That was not what I suggested asking. I'd just like to know
if or how much the current gost stuff gets used with dnssec.

> But using this

Yep. Allocating codepoints for things that don't get used (if
that is the case with gost algs and dnssec which I *still*
don't know any more about), doesn't help us move on from
things that did get used.

Cheers,
S.

> 
> Paul
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Mon, 4 Jan 2021 15:51:11 +0000

On Mon, Jan 04, 2021 at 04:21:10AM -0800, Eric Rescorla wrote:
> > ...

the social contract for code point assignment should be openness and
transparency. that would mean nonproprietary systems documented in an
RFC. the judgement connoted by that RFC would not be recommendation
but rather clarity. the explicit recommendation should be "avoid using
this for your own signatures but be aware that some signatures will use
this and you would benefit from being able to validate those."

-- 
Paul Vixie

---

From: Jim Reid <[email-masked]>
Date: Mon, 4 Jan 2021 16:05:31 +0000

> On 4 Jan 2021, at 15:27, Stephen Farrell <[email-masked]> wrote:
> 

It’s a bit odd to be asking about fairness now. [Better late than never I suppose.] IIRC nobody asked about usage when typecodes got issued for DNSSEC algorithms - until now. It was just assumed, perhaps wrongly, they would be used.

However I think you’re conflating two different things Stephen. This I-D is a sensible and pragmatic solution to a real problem. Mandating a standards-track RFC to get a new DNSSEC type code is unreasonable. [Dare I say unfair? :-)] So let’s fix that.

The question of whether a new DNSSEC crypto algorithm will get used/supported or not can be discussed as and when there’s an I-D proposing to adopt one. And of course there’s a meta-discussion to be had about how/where that discussion takes place. IMO some sort of lightweight expert review process like the one used for RR typecode allocation seems appropriate. It doesn’t necessarily follow that writing up such an (Informational?) RFC guarantees an IANA type code allocation. YMMV.

BTW, does anyone ask usage questions before typecodes get allocated for algorithms/modes used in TLS crypto?

I suport WG adoption of draft-hoffman-dnssec-iana-cons and am willing to review it. Maybe there needs to be another I-D to document the process for adding and deprecating DNSSEC type codes?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Jan 2021 11:05:30 -0500 (EST)

> tbh, so your question surprises me.

While asking is fair, you would also have to define what you
do based on the outcome of that ask. You left that out, so
at best I can interpret is that you would partially base any
IETF decision about algorithm N+1 on results of algorithm N.

> or mega-companies whatever they ask.

But that brings us back to the original issue, what are the requirements
for getting an allocation? If it is "with IETF approval that includes
a history of your previous work", then that is pretty close to IETF
doing a full evaluation, AKA the path of Standards Track. This again
puts the IETF in the middle of nation state crypto politics. We should
not want that. Now if you said nation states get at most one allocation
per 5 years or something equally neutral and measurable, then I might
agree. But in that case, I think Tim's solution is a better one that
accomplishes the same - give out a chunk of numbers, but hold on to a
bunch for true international / IETF usage.

> has RNG algs as entries so maybe it's not a super-good

But you understand why I use it as example. It would be the
equivalent of asking the USG/NSA/NIST about their "algorithm N"
as part of considering "algorithm N+1". For example, IETF
declaring SHA3 a "nation state algorithm". (the tricky
thing here is that the US seems grandfathered in as a non
nation state entity on those occasions when it is)

> if or how much the current gost stuff gets used with dnssec.

What is the relevance of this, if not to take it into account
of the decision making process of N+1 ?

Should the failure of adoption of RSAMD5 in DNSSEC have been used
to evaluate RSASHA256 ?  The early code points in DNSSEC suffered
from the general lack of DNSSEC deployment at the time. I'm sure
that is as valid for RSAMD5 as it was for GOST. The lack of
these deployments where unrelated to the algorithm.

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.

> things that did get used.

This is where we fundamentally disagree. If a government asks for a
codepoint, they don't do it so it does not get used. Clearly,
the intent is that it will be used. Whether that will be true
in the future might be hard to say for either the requester
of the code point or for the IETF. This is very different from
say me as an individual asking for a (likely vanity / unwise)
code point.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Jan 2021 11:18:24 -0500 (EST)

On Mon, 4 Jan 2021, Jim Reid wrote:

> Maybe there needs to be another I-D to document the process for adding and deprecating DNSSEC type codes?

You mean something in addition to RFC 8624 ?

You want to see a Status column at the IANA registry for marking
something "NOT RECOMMENDED" / "DEPRECATED" etc ?

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Jan 2021 16:20:11 +0000

Hiya,

On 04/01/2021 16:05, Paul Wouters wrote:
> 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.

Cheers,
S.

PS: note that I'm neither supporting, nor objecting to,
Paul's draft in the above.

---

From: Jim Reid <[email-masked]>
Date: Mon, 4 Jan 2021 16:33:12 +0000

> On 4 Jan 2021, at 16:18, Paul Wouters <[email-masked]> wrote:
> 

Yes!

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Jan 2021 18:04:02 +0000

>> something "NOT RECOMMENDED" / "DEPRECATED" etc ?

If the WG adopts the draft, it sounds like the WG might want the draft to expand to update RFC 8624 as well to have more states that are relevant to signature algorithms that have code points but that are not on standards track. That seems fine too.

--Paul Hoffman

---

From: Василий Долматов <[email-masked]>
Date: Tue, 5 Jan 2021 11:23:54 +0300

> 4 янв. 2021 г., в 19:20, Stephen Farrell <[email-masked]> написал(а):
> 
> 
> Hiya,
> 
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@
 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 5 Jan 2021 22:45:14 -0500

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.

On Tue, Jan 5, 2021 at 3:24 AM Василий Долматов <[email-masked]> wrote:

>  - «running code» was created for new standards in open-source software
> (implementing it in OpenSSL for instance)
> 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.
>
> 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
> 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.
> >

---

From: Василий Долматов <[email-masked]>
Date: Wed, 6 Jan 2021 15:42:40 +0300

> 6 янв. 2021 г., в 06:45, Ben Schwartz <[email-masked]> написал(а):
> 
> 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?

I think it is a different problem which should be addressed separately.

As I have already mentioned the checks performed made clear that current DNSSEC design has no issues with algorithms switch along validation path. So, there is no need to place several different signatures in one record.
Nevertheless, the possibility of doing that exists and someone could do it.
In that case the problem you mentioned arises and should be considered, I reiterate outside of the scope of current document discussion. Maybe it is worth to submit I-D with proposals how to handle this very special case.

dol@
> 
> 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.
> 
> On Tue, Jan 5, 2021 at 3:24 AM Василий Долматов <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > 4 янв. 2021 г., в 19:20, Stephen Farrell <[email-masked] <mailto:[email-masked]>> написал(а):
> > 
> > 
> > Hiya,
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jan 2021 09:57:33 -0500 (EST)

On Tue, 5 Jan 2021, Ben Schwartz wrote:

> 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

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

>       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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 6 Jan 2021 14:44:53 -0500

On Wed, Jan 6, 2021 at 9:57 AM Paul Wouters <[email-masked]> wrote:

> 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
> their domain, by using DS records of the type they want.

That model works well when (a) all validators implement an algorithm you
like OR (b) you view each algorithm as either "definitely strong" or
"worthless" (no middle ground).  Otherwise, the zone owner has a dilemma.
Should I protect fewer users with higher confidence, or more users with
lower confidence?  I think that is the sticking point in this conversation.

Telling validators to "insist" that all signatures are valid would resolve
this dilemma.  Zone owners could add algorithms without weakening anything.

Why should a
> prefer a NIST ECC curve over a GOST ECC curve or not?

TLS implementations always have a preference order, so I think this is
doable.  Literally any preference order would be more secure than the
behavior recommended in RFC 6840.

> of determining which crypto algorithm is preferred.

FWIW, a validate-all behavior would still be consistent with this rule.

Paul
> >       smooth interoperability, if different algorithms were used in
> DNSSEC validation chain, with even several
> >        - reference implementations of it were created  by different
> software teams with interoperability checks
> >        - «running code» was created for new standards in open-source
> software (implementing it in OpenSSL for instance)
> >       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

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Jan 2021 15:37:38 -0500

On Jan 6, 2021, at 14:45, Ben Schwartz <bemasc=[email-masked]> wrote:

> That model works well when (a) all validators implement an algorithm you like OR (b) you view each algorithm as either "definitely strong" or "worthless" (no middle ground). 

We are in scenario (b).

When you sign a zone you choose one or more algorithms that are individually sufficient. Their relative strength is not important.

> Otherwise, the zone owner has a dilemma.  Should I protect fewer users with higher confidence, or more users with lower confidence?  I think that is the sticking point in this conversation.

I think zone owners are not protecting anybody; they are including a means to gauge authenticity in their responses so that validators can protect users.

There's nothing practically preventing validators from applying local policy in the way they determine whether a response is authentic. Whether or not that's a good idea is an interesting question, but I think it's orthogonal to how individual RRSets are signed. 

> Telling validators to "insist" that all signatures are valid would resolve this dilemma.  Zone owners could add algorithms without weakening anything.

How do you deploy a new signing algorithm alongside an established one without going dark to users using validators that don't support it, in that case?

Joe

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 6 Jan 2021 15:48:41 -0500

On Wed, Jan 6, 2021 at 3:37 PM Joe Abley <[email-masked]> wrote:

> "worthless" (no middle ground).
>
> We are in scenario (b).
>

I think the long half-life of RSA-1024 is an example of a violation of
(b).  I bet there are many operators who view it as neither strong nor
worthless.  SHA-1 post-SHAtter is another possible concern.

> When you sign a zone you choose one or more algorithms that are
> individually sufficient. Their relative strength is not important.
>

I agree, that's what the RFCs effectively require, but it's not the only
possible arrangement.

...

> There's nothing practically preventing validators from applying local
> policy in the way they determine whether a response is authentic. Whether
> or not that's a good idea is an interesting question, but I think it's
> orthogonal to how individual RRSets are signed.
>

I don't think it is orthogonal.  The prevalent local validator policies
change the effect that zone owner choices will have, so zone owners need to
know what those policies are.

> Telling validators to "insist" that all signatures are valid would
> resolve this dilemma.  Zone owners could add algorithms without weakening
> anything.
>
> How do you deploy a new signing algorithm alongside an established one
> without going dark to users using validators that don't support it, in that
> case?
>

To clarify, I meant "all signatures under algorithms that are implemented
by the validator", i.e. "check everything you can".

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Jan 2021 16:09:49 -0500

On 6 Jan 2021, at 15:48, Ben Schwartz <[email-masked]> wrote:

> On Wed, Jan 6, 2021 at 3:37 PM Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
> On Jan 6, 2021, at 14:45, Ben Schwartz <bemasc=[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think the long half-life of RSA-1024 is an example of a violation of (b).

Can you explain that in more detail?

A zone administrator today might decide that RSA with 1024 bit keys is sufficient, or that SHA-1 is reasonable.

A validator administrator might decide otherwise, and decline to gauge authenticity using those signatures.

These are both reasonable local policies. It's ok that they disagree.

> I don't think it is orthogonal.  The prevalent local validator policies change the effect that zone owner choices will have, so zone owners need to know what those policies are.

I agree it's useful to encourage local policies to be sane. I'm not sure why making the kind of change you are talking about achieves that.

It seems clear to me that changing the behaviour in validators would break some things; it's less clear that a change of the kind you suggest would make anything better. I am definitely not yet firing on all cylinders though, this year, so I am fully prepared to discover that I am missing something. :-)

Joe

---

From: Jim Reid <[email-masked]>
Date: Wed, 6 Jan 2021 21:12:54 +0000

> On 6 Jan 2021, at 20:48, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> To clarify, I meant "all signatures under algorithms that are implemented by the validator", i.e. "check everything you can".

??? Are you saying validators should check every RRSIG for each algorithm that they support even after they’ve found one of these RRSIGs that validated?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jan 2021 16:19:56 -0500 (EST)

On Wed, 6 Jan 2021, Ben Schwartz wrote:

> TLS implementations always have a preference order, so I think this is doable.

To be fair, they kicked out everything except AES_GCM and CHACHA20POLY1305, and
I think any preference there is based on speed and not level of security :P

Remember also that TLS ciphers are negotiated. There is no negotiation
in DNSSEC. You get what is published and have to decide whether or not
to use it. So TLS clients have other options to avoid using ciphers they
don't like.

>  Literally any preference order
> would be more secure than the behavior recommended in RFC 6840.

Is it? Are you referring here to treating unknown (eg refused)
algorithms as insecure? The reason for that is to signal to the DNS
client that this answer had no "acceptable DNSSEC protection". This
is better than setting the AD bit on ciphers that you know and no longer
trust. Since that would signal to the application the answer was secured
by DNSSEC, but really it was not if you deemed the algorithm not
acceptable.

If you refer to what to do if one DNSKEY algorithm type is not working
and another algorithm type is, and what to do in such cases, then I
guess that behaviour is somewhat up to the client. unbound has an option
for this:

       harden-algo-downgrade: <yes or no>
               Harden against algorithm downgrade when multiple algorithms  are
               advertised  in  the  DS record.  If no, allows the weakest algo‐
               rithm to validate the zone.  Default is no.  Zone  signers  must
               produce  zones  that  allow  this feature to work, but sometimes
               they do not, and turning this option off avoids that  validation
               failure.

I guess that makes this discussion a variant of the Postel Principle is
good or bad discusion.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jan 2021 21:30:17 +0000

On Jan 6, 2021, at 1:19 PM, Paul Wouters <[email-masked]> wrote:
> Remember also that TLS ciphers are negotiated.

A better analogy might be "although TLS key exchange and encryption ciphers are negotiated, the signing algorithm on the server's certificate is not negotiated". DNSSEC signing is much more akin to the latter, I think.

> There is no negotiation
> in DNSSEC.

Quite right, just as there is no negotiation for the authentication in TLS.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 6 Jan 2021 16:59:29 -0500

Paul Wouters is correct, the "validate all" behavior I'm describing is
basically Unbound's "harden-algo-downgrade".  (I don't know if it does
"validate all" or a priority list.)

My claim is that, if this were the default validator behavior, the original
debate here would largely go away.  Adding algorithms to a zone, even
algorithms that you don't really trust, would be safe, and the registry
would be less controversial.

If we applied similar logic to DNSKEY, that would solve the RSA-1024
problem.  Currently, zone owners can either publish RSA-1024 DNSKEYs (and
be vulnerable if RSA-1024 is broken, which appears imminent), or they can
_not_ publish them, and cause users who don't support their other key type
(e.g. ECDSA) to lose DNSSEC entirely.  RSA-1024 is neither sufficiently
secure for general use nor so worthless that we lose nothing if, by
dropping it, we deny DNSSEC to those users ... but those are the only
options we offer.

> algorithms as insecure?

No, I'm referring to marking the result as Bogus when one RRSIG tells you
so, instead of continuing down the list of RRSIGs looking for one that
validates (RFC 6840's "any single valid path").

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Jan 2021 14:00:48 -0800

On Wed, Jan 6, 2021 at 1:30 PM Paul Hoffman <[email-masked]> wrote:

> A better analogy might be "although TLS key exchange and encryption
> ciphers are negotiated, the signing algorithm on the server's certificate
> is not negotiated". DNSSEC signing is much more akin to the latter, I think.
>
> > There is no negotiation
> > in DNSSEC.
>

This is not strictly correct: TLS allows both the client and the server to
advertise their supported signature algorithms, which can be used by the
peer to guide certificate selection.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jan 2021 22:09:43 +0000

On Jan 6, 2021, at 2:00 PM, Eric Rescorla <[email-masked]> wrote:
> This is not strictly correct: TLS allows both the client and the server to advertise their supported signature algorithms, which can be used by the peer to guide certificate selection.

Fair point. However, if the TLS client says "I support only $x and $y", that does not change how the TLS server chose the algorithm in its certificate in the past, only what to do if it happens to have multiple certificates with different algorithms, which seems rare. Ben's proposal leans way over towards everyone having to agree ahead of time. 

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jan 2021 17:11:25 -0500

> Quite right, just as there is no negotiation for the authentication in TLS.

I stand corrected. You are right.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jan 2021 17:15:44 -0500

> This is not strictly correct: TLS allows both the client and the server to advertise their supported signature algorithms, which can be used by the peer to guide certificate selection.

How common is it for TLS servers to have multiple signature algorithm / certificates configured to support this?

For you IPsec, which has a similar issue, I have never seen a server configured with two certificates, eg to use RSA or ECDSA, or seen opensource software supporting this.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Jan 2021 14:33:10 -0800

On Wed, Jan 6, 2021 at 2:15 PM Paul Wouters <[email-masked]> wrote:

> > This is not strictly correct: TLS allows both the client and the server
> to advertise their supported signature algorithms, which can be used by the

I don't have measurements for this offhand. It typically happens during
periods of transition, for instance between SHA-1 and SHA-256. I believe we
also saw it when servers had certificates with both RSA and EC keys.

-Ekr