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
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
>
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,
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
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.
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:
> >
> >
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
>
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
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.
>
>
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
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
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
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
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,
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
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.
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
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
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
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.
>
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
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.
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
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
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:
25 matches
Mail list logo
