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

[Paul Vixie]

On Thursday, 18 June 2020 16:13:23 UTC Paul Wouters wrote:
> ...
> It would be very strange to introduce a new algorithm as NOT RECOMMENDED.
> The weakest I think we should introduce something is as MAY.

+1.

-- 
Paul


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

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

[Töma Gavrichenkov]

Peace,

On Thu, Jun 18, 2020, 8:39 PM Daniel Migault  wrote:

> To my perspective, holding code point allocation is likely to result in
> non allocated code points being used which represents a higher threat to
> interoperability than adding an algorithm.
>

+1

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

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

[Daniel Migault]

I support adoption of the document. To my perspective, holding code point
allocation is likely to result in non allocated code points being used
which represents a higher threat to interoperability than adding an
algorithm.
Standard track and MAY/OPTIONAL status seem reasonable to me

Yours,
Daniel

On Thu, Jun 18, 2020 at 12:58 PM Eric Rescorla  wrote:

>
>
> On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters  wrote:
>
>> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>>
>> > The way that TLS has handled this is to have the registries have a
>> column called Recommended and we just mark things Y or N. This is slightly
>> > different from RFC 2119 language.
>> >
>> > It's not that uncommon to have new stuff introduced with Recommended =
>> N. In fact this is the likely outcome for the GOST cipher suites:
>> > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/
>>
>> I don't see anything like that mentioned in the IANA Considerations
>> section?
>> https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7
>>
>
> The relevant text is in 8447:
> https://tools.ietf.org/html/rfc8447#section-5
>
>Per this document, a "Recommended" column has been added to many of
>the TLS registries to indicate parameters that are generally
>recommended for implementations to support.  Adding a "Recommended"
>parameter (i.e., "Y") to a registry or updating a parameter to
>"Recommended" status requires Standards Action.  Not all parameters
>defined in Standards Track documents need to be marked as
>"Recommended".
>
> As the GOST draft has an informational header and is not a TLS WG item, I 
> would expect any registration to have Recommended = N.
>
>
>
> In fact, the table is specifically missing the Recommended column
>> required by the IANA Registry.
>>
>
> That seems like an omission but given the above, I expect IANA can handle
> it.
>
>
>
>> As a side not, in those Security Considerations I see:
>>
>> 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
>> reasons for this restriction are that the 0-RTT data is not forward
>> secret and is not resistant to replay attacks
>>
>> It seems that the SHOULD NOT is really a very hard MUST NOT.
>>
>
> It's not clear to me if GOST is any different than the existing TLS cipher
> suites in this respect, but if not, then I'm not quite sure what the
> rationale is here.
>
> -Ekr
>
>
>> As another side note, would be nice to have a link to the IANA sections
>> updated in the IANA Considerations Section.
>>
>>
>> Paul
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


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

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

[Eric Rescorla]

On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters  wrote:

> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>
> > The way that TLS has handled this is to have the registries have a
> column called Recommended and we just mark things Y or N. This is slightly
> > different from RFC 2119 language.
> >
> > It's not that uncommon to have new stuff introduced with Recommended =
> N. In fact this is the likely outcome for the GOST cipher suites:
> > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/
>
> I don't see anything like that mentioned in the IANA Considerations
> section?
> https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7
>

The relevant text is in 8447: https://tools.ietf.org/html/rfc8447#section-5

   Per this document, a "Recommended" column has been added to many of
   the TLS registries to indicate parameters that are generally
   recommended for implementations to support.  Adding a "Recommended"
   parameter (i.e., "Y") to a registry or updating a parameter to
   "Recommended" status requires Standards Action.  Not all parameters
   defined in Standards Track documents need to be marked as
   "Recommended".

As the GOST draft has an informational header and is not a TLS WG
item, I would expect any registration to have Recommended = N.



In fact, the table is specifically missing the Recommended column
> required by the IANA Registry.
>

That seems like an omission but given the above, I expect IANA can handle
it.



> As a side not, in those Security Considerations I see:
>
> 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
> reasons for this restriction are that the 0-RTT data is not forward
> secret and is not resistant to replay attacks
>
> It seems that the SHOULD NOT is really a very hard MUST NOT.
>

It's not clear to me if GOST is any different than the existing TLS cipher
suites in this respect, but if not, then I'm not quite sure what the
rationale is here.

-Ekr


> As another side note, would be nice to have a link to the IANA sections
> updated in the IANA Considerations Section.
>
>
> Paul
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Thu, 18 Jun 2020, Eric Rescorla wrote:


The way that TLS has handled this is to have the registries have a column 
called Recommended and we just mark things Y or N. This is slightly
different from RFC 2119 language.

It's not that uncommon to have new stuff introduced with Recommended = N. In 
fact this is the likely outcome for the GOST cipher suites:
https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/


I don't see anything like that mentioned in the IANA Considerations
section? 
https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7

In fact, the table is specifically missing the Recommended column
required by the IANA Registry.

If we make a consistent decision regarding algorithm recommendations
IETF-wide, than I could agree with your approach. But I would like to avoid
different WGs doing slightly different things. I don't think DNSOP
(or TLS) should decide these things separately.

Perhaps SAAG could publish a generic guidance document on nation state
algorithms and their recommendations?

As a side not, in those Security Considerations I see:

   2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
   reasons for this restriction are that the 0-RTT data is not forward
   secret and is not resistant to replay attacks

It seems that the SHOULD NOT is really a very hard MUST NOT.

As another side note, would be nice to have a link to the IANA sections
updated in the IANA Considerations Section.


Paul

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

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

[Eric Rescorla]

On Thu, Jun 18, 2020 at 9:13 AM Paul Wouters  wrote:

> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>
> > On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski  wrote:
> >   Eric
> >
> > One of the reasons we've published 8624 was to offer usage
> recommendations,
> > and especially this table:
> >
> > https://tools.ietf.org/html/rfc8624#page-5
> >
> > I believe I saw that one of the authors mentioned earlier they are
> looking to
> > do a -bis update, to update this table.
> >
> >
> > Thanks for the pointer. And I suppose I could live with an Informational
> RFC with a  NOT RECOMMENDED entry in this table.
>
> It would be very strange to introduce a new algorithm as NOT RECOMMENDED.
> The weakest I think we should introduce something is as MAY.
>

The way that TLS has handled this is to have the registries have a column
called Recommended and we just mark things Y or N. This is slightly
different from RFC 2119 language.

It's not that uncommon to have new stuff introduced with Recommended = N.
In fact this is the likely outcome for the GOST cipher suites:
https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/

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

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

[Eric Rescorla]

On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski  wrote:

> Eric
>
> One of the reasons we've published 8624 was to offer usage recommendations,
> and especially this table:
>
> https://tools.ietf.org/html/rfc8624#page-5
>
> I believe I saw that one of the authors mentioned earlier they are looking
> to
> do a -bis update, to update this table.
>

Thanks for the pointer. And I suppose I could live with an Informational
RFC with a  NOT RECOMMENDED entry in this table.

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

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

[Tim Wicinski]

Eric

One of the reasons we've published 8624 was to offer usage recommendations,
and especially this table:

https://tools.ietf.org/html/rfc8624#page-5

I believe I saw that one of the authors mentioned earlier they are looking
to
do a -bis update, to update this table.

(But hear the rest of the message clearly)

tim



On Thu, Jun 18, 2020 at 9:42 AM Eric Rescorla  wrote:

>
>
> On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson  wrote:
>
>> I agree with Olafur on this.  The reason we standardize is so that we can
>> have a single - ideally very small - set of algorithms that are widely
>> implemented.  Because you want every one of those algorithms in every
>> implementation.
>>
>> In a system like the DNS, you can't really limit the people who might
>> need to consume your signature, so the set of acceptable signing algorithms
>> needs to be small.  Ideally you have just two: one that is established, and
>> one that is new; or one using one technique and a backup using a different
>> technique.
>>
>> TLS has mostly gotten this part right.  We're much closer to the point of
>> having just two in TLS 1.3.  There are a few algorithms that exist to
>> address narrow application domains (IoT, *cough*), but at least you can
>> make a case for TLS deployments in a closed environment.  For that case,
>> TLS allows for codepoint allocation, but avoids an IETF recommendation for
>> those algorithms.  I don't think that DNS needs that same capability;
>> deciding based on whether algorithms are good for global system is the only
>> relevant criterion.
>>
>> If we all agree that GOST is superior to RSA (it probably is) and EdDSA
>> (I doubt it, but I don't have an opinion), then adoption to replace an
>> existing algorithm would be fine.  That didn't happen last time, so that
>> suggests it would be better for RFC 5933 to be deprecated entirely.
>>
>
> largely concur with MT and Olafur.
>
> At a high level, additional algorithms create additional complexity
> and interoperability issues. In some cases there are good reasons for
> that (for instance, one algorithm is much faster than another),
> however that does not appear to be the case here. In the past we were
> often quite liberal about standardizing national algorithms but I
> believe this was a mistake which created confusion about what
> algorithms the IETF actually was encouraging people to use. In
> addition to the factors that Martin notes, it created pressure on
> implementations to add those algorithms.
>
> I don't see any good argument for the IETF recommending that people
> adopt this algorithm, which does not seem to be in any way clearly
> superior to EdDSA and which would open the door to us recommending a
> proliferation of other national algorithms which also don't seem to
> have any real technical advantages. As MT says, the argument for
> assigning a code point while not recommending the algorithm seems
> weaker here because you want DNSSEC signed data to be universally
> verifiable.
>
> My preference would be to not publish this at all, but if it is to
> be published, do so in a way that makes clear that the IETF is just
> allocating the code point and does not recommend it.
>
> -Ekr
>
>>
>> ___
> 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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson  wrote:

> I agree with Olafur on this.  The reason we standardize is so that we can
> have a single - ideally very small - set of algorithms that are widely
> implemented.  Because you want every one of those algorithms in every
> implementation.
>
> In a system like the DNS, you can't really limit the people who might need
> to consume your signature, so the set of acceptable signing algorithms
> needs to be small.  Ideally you have just two: one that is established, and
> one that is new; or one using one technique and a backup using a different
> technique.
>
> TLS has mostly gotten this part right.  We're much closer to the point of
> having just two in TLS 1.3.  There are a few algorithms that exist to
> address narrow application domains (IoT, *cough*), but at least you can
> make a case for TLS deployments in a closed environment.  For that case,
> TLS allows for codepoint allocation, but avoids an IETF recommendation for
> those algorithms.  I don't think that DNS needs that same capability;
> deciding based on whether algorithms are good for global system is the only
> relevant criterion.
>
> If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I
> doubt it, but I don't have an opinion), then adoption to replace an
> existing algorithm would be fine.  That didn't happen last time, so that
> suggests it would be better for RFC 5933 to be deprecated entirely.
>

largely concur with MT and Olafur.

At a high level, additional algorithms create additional complexity
and interoperability issues. In some cases there are good reasons for
that (for instance, one algorithm is much faster than another),
however that does not appear to be the case here. In the past we were
often quite liberal about standardizing national algorithms but I
believe this was a mistake which created confusion about what
algorithms the IETF actually was encouraging people to use. In
addition to the factors that Martin notes, it created pressure on
implementations to add those algorithms.

I don't see any good argument for the IETF recommending that people
adopt this algorithm, which does not seem to be in any way clearly
superior to EdDSA and which would open the door to us recommending a
proliferation of other national algorithms which also don't seem to
have any real technical advantages. As MT says, the argument for
assigning a code point while not recommending the algorithm seems
weaker here because you want DNSSEC signed data to be universally
verifiable.

My preference would be to not publish this at all, but if it is to
be published, do so in a way that makes clear that the IETF is just
allocating the code point and does not recommend it.

-Ekr

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

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

[S Moonesamy]

Hello,
At 02:07 PM 03-06-2020, Tim Wicinski wrote:

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.
We are looking for *explicit* support for adoption.


This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis


There is the following in Section 1: "Familiarity with DNSSEC and 
with GOST signature and hash algorithms is assumed in this 
document."  I am not familiar with the cryptographic aspects [1] of 
the GOST R 34.11-2012 to perform an adequate review of that standard.


The current draft is well-written.  It probably needs some work 
before it is ready for a Last Call.  I suggest consideration what to 
do about RFC 5933 given that the intended status of the document.


Regards,
S. Moonesamy

1. The Security Area Directors will likely ask whether the document 
was reviewed by the relevant research group. 


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

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

[Paul Vixie]

ships are passing in the night on this topic. GOST is what the russian 
government has to use for its crypto. if GOST is not a standard, then the 
russian federation's government won't be using DNSSEC, or they'll do it with a 
pirated code point. neither of those is desirable and there's no third way.

IETF has not been ruled by good engineering for many years now. the rule for 
publication of a standards document now is, if you want to do "this thing", 
here is a way to do it interoperably.

even known-bad ideas get consensus sometimes. (including some of mine, fwiw.) 
there is nothing particularly bad about GOST. we cannot hold it back based on 
some long-dead ideal Internet System having minimum complexity.

i'm in favour of adoption, and will review.

vixie


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

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

[Martin Thomson]

On Wed, Jun 17, 2020, at 04:49, Dmitry Belyavsky wrote:
> I don't think there are good or bad time periods to adopt nation-wide 
> crypto profiles. For me, the difference between the GOST profile and 
> hypothetical Korean or German profile is close to zero, and if anybody 
> brings such a profile for standardization, I'd like to support it.

I agree with Olafur on this.  The reason we standardize is so that we can have 
a single - ideally very small - set of algorithms that are widely implemented.  
Because you want every one of those algorithms in every implementation.

In a system like the DNS, you can't really limit the people who might need to 
consume your signature, so the set of acceptable signing algorithms needs to be 
small.  Ideally you have just two: one that is established, and one that is 
new; or one using one technique and a backup using a different technique.

TLS has mostly gotten this part right.  We're much closer to the point of 
having just two in TLS 1.3.  There are a few algorithms that exist to address 
narrow application domains (IoT, *cough*), but at least you can make a case for 
TLS deployments in a closed environment.  For that case, TLS allows for 
codepoint allocation, but avoids an IETF recommendation for those algorithms.  
I don't think that DNS needs that same capability; deciding based on whether 
algorithms are good for global system is the only relevant criterion.

If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I 
doubt it, but I don't have an opinion), then adoption to replace an existing 
algorithm would be fine.  That didn't happen last time, so that suggests it 
would be better for RFC 5933 to be deprecated entirely.

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

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

[Dick Franks]

Strength - equivalent to ECDSA p256, assuming no fundamental weakness in
the curve parameters.
The Net::DNS::SEC implementation of algorithm 12 verification involves an
algebraic transformation of ECC-GOST into a mathematically equivalent ECDSA
verification. Unless I am missing something, the same approach appears to
be feasible for GOST R34.10-2012 (256 bit).

Apart from a brief flowering in Verisign DNSSEC Analyser
,
algorithm 12 achieved almost no traction.
Implementers may have been discouraged by the mistake
 in R34.10-2001 test parameters.

But there is also a timeliness issue here.  A GOST R34.10 revision appears
every 11 years or so, and is deprecated 5 years after adoption of its
successor.  Next revision ETA 2023.

The sunset date specified in GOST R34.10-2012 having already passed,
algorithm 12 should be marked N in the DNSSEC Algorithm Numbers
 registry.


Dick Franks



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

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

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

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

Hello Ondrej,

> 16 июня 2020 г., в 10:52, Ondřej Surý  написал(а):
> 
> 
> 
> I consider the previous GOST standardization for DNSSEC to be a fiasco.
I do not think that _standartization_ was a fiasco.
The implementation - definitely was one.

That has an explanation, when RFC5933 was published, soon it was announced that
these algorithms will be superseded by new ones.
So, all implementors prefer not to realize the algorithms which will be defunct 
in three years 
(as was stated, in reality this intermediate period was prolonged and was more 
than five years).

Now, the situation is stable and the implementors are waiting for the standard 
to refer to.
> 
> I would also ask the WG to require a implementation report before we send
> this to WGLC.
I agree that WGLC will require working reference implementation. And we will go 
for that.
> The support for GOST family of algorithms varies between
> the various crypto libraries.
That problem has been noted also some time ago, and for TLS and IPSEC 
implementations with
GOST algorithms there is now independent test service provided, which allows to 
 test implementations
by different vendors for compatibility with current standards (list of RFCs 
checked is provided there).

When DNSSEC implementation wil go forward it will be added to this independent 
testbed
to give vendors and developers possibility to check compatibility with the 
standards,

> 

dol@

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

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

[Dmitry Belyavsky]

Dear Ondřej,

As we have different statuses for the algorithm, I don't think the CFRG
adoption is required.

I don't think there are good or bad time periods to adopt nation-wide
crypto profiles. For me, the difference between the GOST profile and
hypothetical Korean or German profile is close to zero, and if anybody
brings such a profile for standardization, I'd like to support it.

As we have different statuses for the algorithms, I don't think the CFRG
adoption is required.

Speaking about the implementation, I'll have to put on the hat of the GOST
engine maintainer. The open-source implementation of the GOST crypto is
available in OpenSSL (as engine), LibreSSL (being the part of the core),
and GnuTLS.

The project activity of the gost-engine is limited by the coordination of
the life circles between the Russian Standard body and OpenSSL. The issue
you refer to is backdated almost two years ago, and I have some (rather
vague, though) plans to make a new release as some improvements worth
backporting appeared recently and some more are expected.

On Tue, Jun 16, 2020 at 10:53 AM Ondřej Surý  wrote:

> Hi,
>
> I do not hold as strong position as Olafur here, but I concur that the
> document
> needs much better rationale. There’s no rationale for adopting the new GOST
> algorithm at the moment and I would especially like to hear why GOST 2012
> should be standardized and EC-KCDSA (Korean) and ECGDSA (German)
> should not.
>
> I specifically think that we should only standardize algorithms recommended
> by cfrg such as RFC 7748 or RFC 8439 (just example, not applicable).
>
> I consider the previous GOST standardization for DNSSEC to be a fiasco.
>
> I would also ask the WG to require a implementation report before we send
> this to WGLC. The support for GOST family of algorithms varies between
> the various crypto libraries. I found it problematic for the DNS vendors
> that
> OpenSSL supports the algs only in form of OpenSSL engine, and that said
> engine had last release in 2018. The project activity looks fine, but
> issues
> like this[1] don’t exactly fill me with trust, but at least there’s an
> active maintainer
> for the project.
>
> As of the adoption - I am indifferent, the things I mentioned could be done
> with or without WG adopting the document, but I think that the document
> should not become a RFC (not even Informational) before the items I
> mentioned are cleared.
>
> 1. https://github.com/gost-engine/engine/issues/91
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 16 Jun 2020, at 04:42, Olafur Gudmundsson  wrote:
> >
> >
> > Thom
> > As I have before stated in the past, adding new DNSSEC algorithm is bad
> for interoperability,
> > I oppose the adoption of this document unless there are better reasons
> put forward why this algorithm is better than
> > the 4 ECC algorithms that have been standardized so far.
> > Better in this case could be stronger, faster, better post-quantum
> resistance etc
> >
> > Also I want to point out this last call did not specify track so my
> opposition is against all tracks, at this point.
> >
> > Olafur
> >
> >
> >
> >
> >> On Jun 3, 2020, at 5:07 PM, Tim Wicinski  wrote:
> >>
> >>
> >> All,
> >>
> >> As we stated in the meeting and in our chairs actions, we're going to
> run
> >> regular call for adoptions over next few months.
> >> We are looking for *explicit* support for adoption.
> >>
> >>
> >> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
> >>
> >> The draft is available here:
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/
> >>
> >> Please review this draft to see if you think it is suitable for adoption
> >> by DNSOP, and comments to the list, clearly stating your view.
> >>
> >> Please also indicate if you are willing to contribute text, review, etc.
> >>
> >> This call for adoption ends: 15 June 2020
> >>
> >> Thanks,
> >> tim wicinski
> >> DNSOP co-chair
> >>
> >>
> >>
> >> ___
> >> 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
>


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

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

[Tim Wicinski]

All

On Tue, Jun 16, 2020 at 3:52 AM Ondřej Surý  wrote:

> [...]



>
> I would also ask the WG to require a implementation report before we send
> this to WGLC.


As chair, this statement -  I can not stress this strongly enough -
determines
even the consideration of a Working Group Last Call.
(I would argue my position on this is stronger than Olafur's).

As chair, I'm very open to having the WG consider and possibly adopt,
technical
work such as this.  I have a *lower* bar for adopting than my co-chairs or
our
Area Director.

As chair, I purposely don't state the intended RFC track during the call
for adoption.
While I disagree with the authors in a percentage of adopted work, I feel
the
WG is very effective at providing guidance, and reasoning.  The chairs
listen
and consider these comments.

As chair, we have a very *high* bar for moving to WGLC.  Implementation
reports
are everything to myself (not speaking for my co-chairs, but I believe they
have
similar feelings).

I had been thinking about the outcome of this call for adoption, and was
going to
have a conversation with my co-chairs and Warren on my thoughts in the next
few
days.  Hearing these thoughts are very useful, and I can't thank you enough..

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

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

[Ondřej Surý]

Hi,

I do not hold as strong position as Olafur here, but I concur that the document
needs much better rationale. There’s no rationale for adopting the new GOST
algorithm at the moment and I would especially like to hear why GOST 2012
should be standardized and EC-KCDSA (Korean) and ECGDSA (German)
should not.

I specifically think that we should only standardize algorithms recommended
by cfrg such as RFC 7748 or RFC 8439 (just example, not applicable).

I consider the previous GOST standardization for DNSSEC to be a fiasco.

I would also ask the WG to require a implementation report before we send
this to WGLC. The support for GOST family of algorithms varies between
the various crypto libraries. I found it problematic for the DNS vendors that
OpenSSL supports the algs only in form of OpenSSL engine, and that said
engine had last release in 2018. The project activity looks fine, but issues
like this[1] don’t exactly fill me with trust, but at least there’s an active 
maintainer
for the project.

As of the adoption - I am indifferent, the things I mentioned could be done
with or without WG adopting the document, but I think that the document
should not become a RFC (not even Informational) before the items I
mentioned are cleared.

1. https://github.com/gost-engine/engine/issues/91

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 16 Jun 2020, at 04:42, Olafur Gudmundsson  wrote:
> 
> 
> Thom
> As I have before stated in the past, adding new DNSSEC algorithm is bad for 
> interoperability,
> I oppose the adoption of this document unless there are better reasons put 
> forward why this algorithm is better than
> the 4 ECC algorithms that have been standardized so far.
> Better in this case could be stronger, faster, better post-quantum resistance 
> etc
> 
> Also I want to point out this last call did not specify track so my 
> opposition is against all tracks, at this point.
> 
> Olafur
> 
> 
> 
> 
>> On Jun 3, 2020, at 5:07 PM, Tim Wicinski  wrote:
>> 
>> 
>> All,
>> 
>> As we stated in the meeting and in our chairs actions, we're going to run
>> regular call for adoptions over next few months.
>> We are looking for *explicit* support for adoption.
>> 
>> 
>> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
>> 
>> The draft is available here: 
>> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/
>> 
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.
>> 
>> Please also indicate if you are willing to contribute text, review, etc.
>> 
>> This call for adoption ends: 15 June 2020
>> 
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
>> 
>> 
>> 
>> ___
>> 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



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

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

[Olafur Gudmundsson]

Thom 
As I have before stated in the past, adding new DNSSEC algorithm is bad for 
interoperability, 
I oppose the adoption of this document unless there are better reasons put 
forward why this algorithm is better than
the 4 ECC algorithms that have been standardized so far. 
Better in this case could be stronger, faster, better post-quantum resistance 
etc 

Also I want to point out this last call did not specify track so my opposition 
is against all tracks, at this point. 

Olafur




> On Jun 3, 2020, at 5:07 PM, Tim Wicinski  wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.  
> We are looking for *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 15 June 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> 
> ___
> 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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Stanislav V. Smyshlyaev]

Dear all,


> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/


I support adoption and am willing to review.

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

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

[Dmitry Belyavsky]

Dear Paul,

On Thu, Jun 4, 2020 at 12:17 AM Paul Wouters  wrote:

> On Wed, 3 Jun 2020, Tim Wicinski wrote:
>
> > As we stated in the meeting and in our chairs actions, we're going to run
> > regular call for adoptions over next few months.
> > We are looking for *explicit* support for adoption.
> >
> > This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
>
> I support adoption, willing to review and contribute txt.
>
> Note, the DS in the example in section 4.1 seems to be using 5 as
> the assigned number, but this should probably be a TBA2 for now :)
>
> Unless, an early code point has already been assigned, and looking
> at the iana table the next available value is indeed 5 :)
>

Thanks for your support!

I had to define some values to provide relevant examples,
and 5 for digest is mentioned in the "IANA Considerations" section.

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

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

[Dmitry Belyavsky]

Hello,

On Thu, Jun 4, 2020 at 12:07 AM Tim Wicinski  wrote:

>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/
>

Being a co-author of this draft, I support adoption.

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

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

[Brian Dickson]

On Wed, Jun 3, 2020 at 2:07 PM Tim Wicinski  wrote:

>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
I support adoption, and am willing to review.

Brian


>
> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 15 June 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
>
> ___
> 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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Warren Kumari]

On Wed, Jun 3, 2020 at 5:07 PM Tim Wicinski  wrote:

>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>


I support adoption.


Some background:
The authors of this has asked me to AD sponsor it, but I felt it was much
better to have it progress through the normal IETF / DNSOP process, and so
I asked them to bring it here, but my support for adoption should be viewed
like any other...

W



>
>
> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 15 June 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Wed, 3 Jun 2020, Tim Wicinski wrote:


As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.  
We are looking for *explicit* support for adoption.

This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis


I support adoption, willing to review and contribute txt.

Note, the DS in the example in section 4.1 seems to be using 5 as
the assigned number, but this should probably be a TBA2 for now :)

Unless, an early code point has already been assigned, and looking
at the iana table the next available value is indeed 5 :)

Paul

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

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

[Tim Wicinski]

All,

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.
We are looking for *explicit* support for adoption.


This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 15 June 2020

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop