Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Wouters]

On Sun, 19 Jul 2020, Paul Vixie wrote:


On Sunday, 19 July 2020 07:52:39 UTC Ondřej Surý wrote:

I just want to point out, that I am certainly not overthinking this with my
implementors hat. The RFC and code-point puts pressure on the DNS vendors
to actually implement this „because there’s RFC“. ...


If we are talking about Nation State ciphers, the pressure is on them to
submit code to get it supported. Whether it is in openssl or bind or
what not.

i'm going to want to be able to validate signatures generated in russia by 
russians of russian dns zones. so my pressure on my implementors will not be 
because there's an RFC, but rather, because there are keys and signatures.



the thing we live on is round.


Indeed. As much as I also want to limit the number of algorithms because
most Nation States ones will never see real deployment, we cannot really
prevent them from trying to get a real deployment.

If someone from Europe or North America would come up with another
algorithm, I'd be more tempted to say no than if Russia or China
would come to ask for one.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Vixie]

On Sunday, 19 July 2020 07:52:39 UTC Ondřej Surý wrote:
> I just want to point out, that I am certainly not overthinking this with my
> implementors hat. The RFC and code-point puts pressure on the DNS vendors
> to actually implement this „because there’s RFC“. ...

i'm going to want to be able to validate signatures generated in russia by 
russians of russian dns zones. so my pressure on my implementors will not be 
because there's an RFC, but rather, because there are keys and signatures.

(i've dropped my .su domain, but i may get another some day, so it's possible 
i will want to be able to generate signatures using russian crypto, also.)

in other words i'm agreeing with ondrej on this -- it's a standard not just a 
code point reservation.

the thing we live on is round.

-- 
Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[John Levine]

In article <32cec795-45f3-48c7-bd42-dccfe0454...@isc.org> you write:
>„because there’s RFC“. The whole reason for standardization is that there’s 
>interoperatibility
>between the implementations - and just giving the code points without 
>implementing this
>hardly fulfills that requirement.

I thought that in situations like this, the reason to assign the code
point is so that other people don't use it for something else.

ECC-GOST has been number 12 for a decade. I don't get the impression
it's widely implemented, but has it caused any problems?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Ondřej Surý]

I just want to point out, that I am certainly not overthinking this with my 
implementors hat.
The RFC and code-point puts pressure on the DNS vendors to actually implement 
this
„because there’s RFC“. The whole reason for standardization is that there’s 
interoperatibility
between the implementations - and just giving the code points without 
implementing this
hardly fulfills that requirement.

Sure, I can ignore the new GOST code point in BIND 9, but that becomes harder 
when
either one of the other open source implementations or one of the big DNS silos 
will actually
do the implementation.

So, it’s definitively not „just giving the code point“, it has implications for 
some of us.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 18 Jun 2020, at 17:36, Jim Reid  wrote:
> 
> I think we’re over-thinking this. Just issue new code point(s) for the new 
> algorithm(s) and be done with it.
> 
> IMO there’s no need for the WG or the IETF to make any statements about the 
> suitability of the underlying crypto used for optional signing and 
> validation. That’s largely a matter for those who use these algorithms. 
> Higher-level concerns about the crypto’s suitability should only come into 
> play whenever an algorithm is a MUST/SHOULD recommendation in a 
> standards-track RFC.
> 
> Maybe we need an RFC6895-like process for maintaining this IANA registry, 
> like we have for RRtype codes?
> 



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jul 7, 2020, at 4:37 AM, Töma Gavrichenkov  wrote:
> 
> Peace,
> 
> On Tue, Jul 7, 2020, 5:17 AM Paul Hoffman  wrote:
> On Jul 6, 2020, at 6:07 PM, Tim Wicinski  wrote:
>> > To not adopt this means, the implementers could easily pick their own 
>> 
>> This seems unlikely. If they step on unallocated code points, few 
>> implementers will go along with that because implementers generally respect 
>> the IETF and IANA more than they respect a country's crypto regime.
> 
> That's only correct when said implementers have a choice.  With no allocated 
> points going to be available in the future, a hijack would be the only viable 
> option.
> 
> Also, we have stepped on that rake before.  You don't need a lot of 
> implementers going nuts to destroy interoperability.  You only need *one* who 
> would be successful in that s/he is doing.
> 
> Let's face it, there's not gonna be hundreds of DNSSEC GOST implementations 
> anyway, I think maybe 3 or 4 would finally be born, and one of those would 
> likely win the competition and become a standard de-facto.  See, without the 
> code point allocation it's a pure gamble on whether we'll get interop issues 
> in the future or not.

Fair points. Still, a crypto developer who only had to go through the ISE 
instead of the WG->IETF process should still be happier because they get their 
point faster.

And, as Ekr pointed out early, making all of these registries be just "Expert 
review" would be even faster.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Töma Gavrichenkov]

Peace,

On Tue, Jul 7, 2020, 5:17 AM Paul Hoffman  wrote:

> On Jul 6, 2020, at 6:07 PM, Tim Wicinski  wrote:
> > To not adopt this means, the implementers could easily pick their own
>
> This seems unlikely. If they step on unallocated code points, few
> implementers will go along with that because implementers generally respect
> the IETF and IANA more than they respect a country's crypto regime.
>

That's only correct when said implementers have a choice.  With no
allocated points going to be available in the future, a hijack would be the
only viable option.

Also, we have stepped on that rake before.  You don't need a lot of
implementers going nuts to destroy interoperability.  You only need *one*
who would be successful in that s/he is doing.

Let's face it, there's not gonna be hundreds of DNSSEC GOST implementations
anyway, I think maybe 3 or 4 would finally be born, and one of those would
likely win the competition and become a standard de-facto.  See, without
the code point allocation it's a pure gamble on whether we'll get interop
issues in the future or not.

--
Töma

>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jul 6, 2020, at 6:07 PM, Tim Wicinski  wrote:
> 
> 
> All
> 
> I've been going over the CfA comments, and discussing this with my chairs and 
> Warren, and 
> perhaps the best way to walk through the logic in our decision is to work 
> backwards.
> 
> 
> The authors are requesting a code point for their algorithm in this IANA 
> registry:
> 
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
> 
> To receive such a code point a "Standards Action", which is defined as:
> 
> For the Standards Action policy, values are assigned only through
> Standards Track or Best Current Practice RFCs in the IETF Stream.
> 
> Which means that 1) Informational will not work; and 2) Independent Stream 
> will not work.
> 
> In the excellent discussion on this, what seems to be the underlying 
> consensus is 
> the need to publish the document to establish the code point, and document it 
> as such.

So far, so good.

> 
> To not adopt this means, the implementers could easily pick their own 

This seems unlikely. If they step on unallocated code points, few implementers 
will go along with that because implementers generally respect the IETF and 
IANA more than they respect a country's crypto regime.

If we fix the registries in question to not require standards-track RFCs, then 
we don't need to adopt this document: the authors could publish them through 
the ISE.

> There was also discussion on updating the table in 
> https://tools.ietf.org/html/rfc8624#page-5 [tools.ietf.org]
> (implementation recommendations for DNSKEY algorithms), and here seemed to be 
> some consensus around MAY

Yes, great.

> There was also an orthogonal discussion around changing the registry from 
> "Standards Action"
> to "RFC Required".  

That was not orthogonal at all. It was directly intended to allow the WG to not 
adopt this document and yet allow the authors to get what they want, which are 
IANA code point allocations that implementers can then find the relevant 
documents for.

It feels weird for the DNSOP WG to recommend to the IETF that it publish a 
standards-track document that virtually no one in the WG understands. The DNSOP 
WG could use the same pattern as other IETF WGs (TLS, SMIME, IPsec, ...) for 
the past 25+ years.

And, before anyone says "but we'll run out of code points!", please take a look 
at how small the registries are for those other crypto protocols. There are a 
handful of countries with their own crypto, but the number is surprisingly low.

> While this seems to be a simple procedural move, I fear that doing
> so haphazardly without understanding the operational considerations is 
> completely 
> wrong (Remember, We are DNS OPerations)

I'm not seeing how following what the other WGs have been doing for decades as 
"haphazard".

> Mr. Wouters made the very correct comment that "no one outside the IETF 
> really knows the difference for RFCs anyway."
> This was something I was reminded of all too well during the DNS RPZ 
> discussions. 

This document is not for people outside the IETF: it's for implementers. They 
do indeed consider standards-track RFCs different than informational RFCs. That 
is why we had to create RFC 8624.

> Summary:  Adopt as Standards Track because we have to add text to the state 
> as such.  We will not spend a lot
> of WG time on this document, and Warren and I will end up doing the heavy 
> lifting on all the process portions.

That feels exactly wrong. "We didn't really read this draft, but we want you to 
make it an IETF standard". My counter-proposal was "we made it easier for folks 
with national algorithms to get their code points without having to deal with 
the WG process".

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Tim Wicinski]

All

I've been going over the CfA comments, and discussing this with my chairs
and Warren, and
perhaps the best way to walk through the logic in our decision is to work
backwards.


The authors are requesting a code point for their algorithm in this IANA
registry:

https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1

To receive such a code point a "Standards Action", which is defined as:

For the Standards Action policy, values are assigned only through
Standards Track or Best Current Practice RFCs in the IETF Stream.

Which means that 1) Informational will not work; and 2) Independent Stream
will not work.

In the excellent discussion on this, what seems to be the underlying
consensus is
the need to publish the document to establish the code point, and document
it as such.

To not adopt this means, the implementers could easily pick their own
There was also discussion on updating the table in
https://tools.ietf.org/html/rfc8624#page-5
(implementation recommendations for DNSKEY algorithms), and here seemed to
be some consensus around MAY


There was also an orthogonal discussion around changing the registry from
"Standards Action"
to "RFC Required".  While this seems to be a simple procedural move, I fear
that doing
so haphazardly without understanding the operational considerations is
completely
wrong (Remember, We are DNS OPerations)

Mr. Wouters made the very correct comment that "no one outside the IETF
really knows the difference for RFCs anyway."
This was something I was reminded of all too well during the DNS RPZ
discussions.

Summary:  Adopt as Standards Track because we have to add text to the state
as such.  We will not spend a lot
of WG time on this document, and Warren and I will end up doing the heavy
lifting on all the process portions.

thanks
tim

On Wed, Jun 24, 2020 at 6:42 PM Wes Hardaker  wrote:

> Paul Hoffman  writes:
>
> > If the WG wants, this short draft could be a WG document.
>
> Yes please.
> --
> Wes Hardaker
> USC/ISI
>
> ___
> 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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Wes Hardaker]

Paul Hoffman  writes:

> If the WG wants, this short draft could be a WG document.

Yes please.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Töma Gavrichenkov]

Peace,

On Fri, Jun 19, 2020 at 8:31 PM Eric Rescorla  wrote:
> My reasoning is that (as above) these algorithms are generally of
> low interest and that requiring community review for code point
> registration has the result of consuming quite scarce resources
> in the service of making the algorithms which are being registered
> marginally clearer.

I sort of agree but I can't help wondering if the IETF would then
manage to process the flow of technical erratas, corrections and -bis
documents, which the current community review process is aiming to
avoid.

--
Töma

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

As I mentioned earlier, in response to "we need this on standards track" I have 
produced a very short draft that would remove that requirement:
   https://www.ietf.org/id/draft-hoffman-dnssec-iana-cons-00.txt
It covers both DS records and NSEC3 records, which have similar issues with 
hash algorithms. It also has an appendix that reflects Ekr's thoughts that 
maybe this all should be "specification required".

If the WG wants, this short draft could be a WG document.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Василий Долматов]

> 19 июня 2020 г., в 21:17, Dick Franks  написал(а):
> 
> On Fri, 19 Jun 2020 at 18:12, Paul Hoffman  > wrote:
> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  > wrote:
> > What's your reasoning for why there needs to be community review before 
> > there is a code point assigned?
> 
> Historically, the quality of algorithm descriptions in early drafts has been 
> variable. What the author considers sufficient and obvious, another might 
> not. Also, review gives folks a chance to say things like "your test vectors 
> appear wrong", "having test vectors would be really useful", and so on. 
> 
> How does any of that apply?
> The algorithm in this case is specified by another standards organisation and 
> is what it is.
> Community review did not find the incorrect test parameters in RFC5832 / GOST 
> R34.10-2001.

In the given case it is worth referring to RFC7091/GOST R34-10.2012
but the statement remains the same.



dol@


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Wouters]

On Fri, 19 Jun 2020, Olafur Gudmundsson wrote:


It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the 
DS registry "RFC required", like the other DNSSEC-related registries.

You are proposing a bureaucratic solution without thinking about the 
operational implications of it.
The hardest part to update in DNS tree right now is uploading DS records to the 
parents, keeping the list of algorithms down helps avoid operational problems



On the contrary, lets make that list change every month, so registrars
and registries stop doing weird requirements on DS.

Or advocate for ICANN contractual updates for mandatory CDS support :P

Anyway, nothing of this is related to new algortihms and should not be
conflated with it.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Olafur Gudmundsson]

> On Jun 18, 2020, at 11:30 AM, Paul Hoffman  wrote:
> 
> On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:
>> The 2nd registry
>> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
>> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
>>  
>> )
>> has the "Standards Action" update policy
> 
> I had forgotten that the DS registry is "standards action". This document 
> shows why that was a bad idea.

Why ? 

> 
> It might be better, and faster, for this WG to adopt a one-paragraph draft 
> that makes the DS registry "RFC required", like the other DNSSEC-related 
> registries.
You are proposing a bureaucratic solution without thinking about the 
operational implications of it. 
The hardest part to update in DNS tree right now is uploading DS records to the 
parents, keeping the list of algorithms down helps avoid operational problems 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Fri, Jun 19, 2020 at 11:39 AM John Levine  wrote:

> In article  01gd...@mail.gmail.com> you write:
> >> Yes. Leveraging the fact that the IETF community is in fact a community
> >> seems worth the effort to have the references in registries be useful
> to a
> >> new developer a decade in the future.
> >
> >OK. In that case you and I disagree.
> >
> >My reasoning is that (as above) these algorithms are generally of low
> >interest and that requiring community review for code point registration
> >has the result of consuming quite scarce resources in the service of
> making
> >the algorithms which are being registered marginally clearer. ...
>
> Sounds like expert review would be more appropriate, so only one
> person has to spend cycles deciding whether the spec looks plausible.
>

As I said, even that turns out to be quite a bit of work, depending on what
you think "plausible" means. If you review for "there appears to be
something vaguely formatted like a spec at this location", then sure. If
you mean "is this implementable", let alone secure, then it's pretty far
from easy.

-Ekr

>
> R's,
> John
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[John Levine]

In article  
you write:
>> Yes. Leveraging the fact that the IETF community is in fact a community
>> seems worth the effort to have the references in registries be useful to a
>> new developer a decade in the future.
>
>OK. In that case you and I disagree.
>
>My reasoning is that (as above) these algorithms are generally of low
>interest and that requiring community review for code point registration
>has the result of consuming quite scarce resources in the service of making
>the algorithms which are being registered marginally clearer. ...

Sounds like expert review would be more appropriate, so only one
person has to spend cycles deciding whether the spec looks plausible.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Dick Franks]

On Fri, 19 Jun 2020 at 18:12, Paul Hoffman  wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> > What's your reasoning for why there needs to be community review before
> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>

How does any of that apply?
The algorithm in this case is specified by another standards organisation
and is what it is.
Community review did not find the incorrect test parameters in RFC5832 /
GOST R34.10-2001.

--Dick Franks



> ___
> 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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman 
wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> > What's your reasoning for why there needs to be community review before
> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>
> > Would that still apply if the space were larger?
>
> Yes. Leveraging the fact that the IETF community is in fact a community
> seems worth the effort to have the references in registries be useful to a
> new developer a decade in the future.
>

OK. In that case you and I disagree.

My reasoning is that (as above) these algorithms are generally of low
interest and that requiring community review for code point registration
has the result of consuming quite scarce resources in the service of making
the algorithms which are being registered marginally clearer. This opinion
is based on my extensive experience in reviewing code point assignments for
TLS (largely for things like exporters) where one was presented with a long
specification which was embedded in the context of some other protocol and
then one had to make sense of it and determine whether it was
implementable. And because you were actually holding up other people's work
based on that review, there was pressure to complete it. This kind of
experience is why we changed to the current system.

More generally, it seems like there are two primary purposes for code point
registration here:

1. To promote interoperability of the code points
2. To avoid code point collisions

My perspective here is that while interoperability is good, the primary
value here is to avoid collisions. People who wish to have interoperability
will still have the IETF process available to them, but given the large
number of uses of our protocols, I do not believe that it is productive to
make it harder for people to extend them in order to require
interoperability for those who do not believe they need it (or at least do
not believe they need the IETF enforcing it).

-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> What's your reasoning for why there needs to be community review before there 
> is a code point assigned?

Historically, the quality of algorithm descriptions in early drafts has been 
variable. What the author considers sufficient and obvious, another might not. 
Also, review gives folks a chance to say things like "your test vectors appear 
wrong", "having test vectors would be really useful", and so on. 

> Would that still apply if the space were larger?

Yes. Leveraging the fact that the IETF community is in fact a community seems 
worth the effort to have the references in registries be useful to a new 
developer a decade in the future.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Fri, Jun 19, 2020 at 8:38 AM Paul Hoffman  wrote:

> On Jun 18, 2020, at 9:20 PM, Martin Thomson  wrote:
> >
> > On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
> >> It might be better, and faster, for this WG to adopt a one-paragraph
> >> draft that makes the DS registry "RFC required", like the other
> >> DNSSEC-related registries.
> >
> > I think you mean "Specification Required".
>
> I do not.
>
> >  RFC required has the same net effect, but the side effect being that
> you burden the ISE with these requests.
>
> "RFC required" forces the specification to be stable enough for the ISE
> (or the IESG, for individual submissions) to approve publication. Using
> "specification required" means that someone can write an Internet Draft,
> get the code point, then realize that their draft was wrong due to lack of
> community review. The result is either:
> - Two code points for similarly-named algorithms
>

Sure. This seems not that desirable, but given that these algorithms are
more or less by definition ones in which there is not that wide interest,
not that big a deal.


- A code point whose definition is a moving target
>

I agree that this is undesirable. The registrations should be tied to a
single fixed draft version.



> Using "RFC required" is not perfect (due to errata and RFC updates), but
> it does mean that there is at least some community review before the code
> point is allocated.
>

What's your reasoning for why there needs to be community review before
there is a code point assigned? Would that still apply if the space were
larger?


-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jun 18, 2020, at 9:20 PM, Martin Thomson  wrote:
> 
> On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
>> It might be better, and faster, for this WG to adopt a one-paragraph 
>> draft that makes the DS registry "RFC required", like the other 
>> DNSSEC-related registries.
> 
> I think you mean "Specification Required".

I do not.

>  RFC required has the same net effect, but the side effect being that you 
> burden the ISE with these requests.

"RFC required" forces the specification to be stable enough for the ISE (or the 
IESG, for individual submissions) to approve publication. Using "specification 
required" means that someone can write an Internet Draft, get the code point, 
then realize that their draft was wrong due to lack of community review. The 
result is either:
- Two code points for similarly-named algorithms
- A code point whose definition is a moving target
Using "RFC required" is not perfect (due to errata and RFC updates), but it 
does mean that there is at least some community review before the code point is 
allocated.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Vladimír Čunát]

On 6/19/20 6:20 AM, Martin Thomson wrote:
> As long as the space of codepoints isn't too small (2^16 is fine), then I see 
> no reason not to allow external publications request a value as long as they 
> don't abuse the privilege.

The space for DNSKEY and DS algorithms is one octet, so each of the two
registries has remaining space for around 250 algorithms and thus we
can't be "too wasteful".  Still, I wouldn't expect too many to want a
code point, so perhaps it could be optimistically started and only
restricted if getting too much popularity.

Ref. e.g. https://tools.ietf.org/html/rfc4034#section-5.1

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Martin Thomson]

On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
> It might be better, and faster, for this WG to adopt a one-paragraph 
> draft that makes the DS registry "RFC required", like the other 
> DNSSEC-related registries.

I think you mean "Specification Required".  RFC required has the same net 
effect, but the side effect being that you burden the ISE with these requests.

As long as the space of codepoints isn't too small (2^16 is fine), then I see 
no reason not to allow external publications request a value as long as they 
don't abuse the privilege.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Wouters]

On Thu, 18 Jun 2020, Paul Hoffman wrote:


On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:

The 2nd registry
Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 
)
has the "Standards Action" update policy


I had forgotten that the DS registry is "standards action". This document shows 
why that was a bad idea.

It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the 
DS registry "RFC required", like the other DNSSEC-related registries.


I agree.

However, whether it is faster for the document, I don't know. The ISE
stream is currently very slow moving. Perhaps these documents could
flow faster than the two other ISE stream ones I am I'm tracking.

I'm fine with the RFCs being standard track.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Jim Reid]

> On 18 Jun 2020, at 16:01, Joe Abley  wrote:
> 
> On Jun 18, 2020, at 16:48, Paul Hoffman  wrote:
> 
>> Why is this WG considering making this document Standards Track instead of 
>> Informational? Also, why is the WG considering putting the document in our 
>> work stream at all? Can the WG can bring much value to the document itself? 
>> We do have lots of other things we are working on.
> 
> I think the question of the value the wg can bring is the important one.

I think we’re over-thinking this. Just issue new code point(s) for the new 
algorithm(s) and be done with it.

IMO there’s no need for the WG or the IETF to make any statements about the 
suitability of the underlying crypto used for optional signing and validation. 
That’s largely a matter for those who use these algorithms. Higher-level 
concerns about the crypto’s suitability should only come into play whenever an 
algorithm is a MUST/SHOULD recommendation in a standards-track RFC.

Maybe we need an RFC6895-like process for maintaining this IANA registry, like 
we have for RRtype codes?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Jim Reid]

> On 18 Jun 2020, at 16:30, Paul Hoffman  wrote:
> 
> It might be better, and faster, for this WG to adopt a one-paragraph draft 
> that makes the DS registry "RFC required", like the other DNSSEC-related 
> registries.

+1



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:
> The 2nd registry
> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 
> )
> has the "Standards Action" update policy

I had forgotten that the DS registry is "standards action". This document shows 
why that was a bad idea.

It might be better, and faster, for this WG to adopt a one-paragraph draft that 
makes the DS registry "RFC required", like the other DNSSEC-related registries.

--Paul Hoffman





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Joe Abley]

On Jun 18, 2020, at 16:48, Paul Hoffman  wrote:

> Why is this WG considering making this document Standards Track instead of 
> Informational? Also, why is the WG considering putting the document in our 
> work stream at all? Can the WG can bring much value to the document itself? 
> We do have lots of other things we are working on.

I think the question of the value the wg can bring is the important one.

In this case it seems unlikely that dnsop has the expertise to review this 
document to the depths of the crypto. The degree to which the advice for DNSSEC 
implementers is clear and unambiguous can surely be assessed without putting it 
through the working group machinery.

An individual submission will still require conflict review by the IESG and 
that will involve credible DNS people to express an opinion, so there will no 
doubt be some familiar faces from dnsop that are still involved in an 
individual capacity, but I think (as I think Paul infers above) that there is 
little benefit to adding this to the workload of the wg chairs and AD if we 
don't expect the document to benefit from corresponding levels of improvement.

For what it's worth if this was to proceed on the individual submission stream 
and if the authors needed independent reviewers to express an opinion as part 
of that process I'd happily put my hand up with a DNS perspective. I almost 
certainly can't help with the crypto.

The question of how dnsop tracks algorithms that exist and whether they are 
recommended or not is reasonably separate from whether this document should be 
published, I think.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Valery Smyslov]

Hi Paul,

> Why is this WG considering making this document Standards Track instead of 
> Informational? Also, why is the
> WG considering putting the document in our work stream at all? Can the WG can 
> bring much value to the
> document itself? We do have lots of other things we are working on.
> 
> There is no procedural need for this document to be part of the DNSOP working 
> group. In order for this
> algorithm to get an algorithm number from IANA, all that is needed is an RFC. 
> National crypto algorithms is
> one of the common use cases for the Independent Stream in the RFC Series. 
> Suggesting that the authors
> publish it there will take less time for all of us, will conceivably get it 
> published as an RFC sooner, and fulfills
> the requirement for them to get their assignment from IANA.

The draft is going to allocate a code point from the "Delegation Signer (DS) 
Resource Record (RR) Type Digest Algorithms" registry
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1). 
which has a "Standards Action" update policy.

It would be much easier if publication via ISE was possible.

Regards,
Valery Smyslov.

> --Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Dmitry Belyavsky]

Dear Paul,

On Thu, Jun 18, 2020 at 5:48 PM Paul Hoffman  wrote:

> Why is this WG considering making this document Standards Track instead of
> Informational? Also, why is the WG considering putting the document in our
> work stream at all? Can the WG can bring much value to the document itself?
> We do have lots of other things we are working on.
>
> There is no procedural need for this document to be part of the DNSOP
> working group. In order for this algorithm to get an algorithm number from
> IANA, all that is needed is an RFC. National crypto algorithms is one of
> the common use cases for the Independent Stream in the RFC Series.
> Suggesting that the authors publish it there will take less time for all of
> us, will conceivably get it published as an RFC sooner, and fulfills the
> requirement for them to get their assignment from IANA.
>

Unfortunately, Independent Stream is impossible for this document.

This document requires updates to 2 IANA registries:
Domain Name System Security (DNSSEC) Algorithm Numbers
(
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
)
has the "RFC Required" update policy

The 2nd registry
Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
(
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
)
has the "Standards Action" update policy

So it makes impossible to use the Independent Stream process.

-- 
SY, Dmitry Belyavsky
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Hoffman]

Why is this WG considering making this document Standards Track instead of 
Informational? Also, why is the WG considering putting the document in our work 
stream at all? Can the WG can bring much value to the document itself? We do 
have lots of other things we are working on.

There is no procedural need for this document to be part of the DNSOP working 
group. In order for this algorithm to get an algorithm number from IANA, all 
that is needed is an RFC. National crypto algorithms is one of the common use 
cases for the Independent Stream in the RFC Series. Suggesting that the authors 
publish it there will take less time for all of us, will conceivably get it 
published as an RFC sooner, and fulfills the requirement for them to get their 
assignment from IANA.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop