Subject: [Curdle] Adoption

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Feb 2016 22:06:28 +0000

Hi,

Does anyone object that we declare there is a consensus to adopt the following drafts? If so please let us know by Feb 26.

https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbjh21-2Dssh-2Ded25519-2D02&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=piKyKq4rloFMiXliLchx2moaHaTFLIlCfH4x4dV3Vgg&e=>

https://tools.ietf.org/html/draft-josefsson-ssh-curves-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Djosefsson-2Dssh-2Dcurves-2D00&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=aqmFcF3O5vkM2EiTsB9ICLBrzxfECpCkypRHb8IhOiE&e=>

https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsury-2Ddnskey-2Ded25519-2D03&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=AbYVfBTs53oaUg9Dgac3FjGLOi-xmIZp32eTvzBTyuU&e=>

https://tools.ietf.org/html/draft-sury-dnskey-ed448-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsury-2Ddnskey-2Ded448-2D00&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=1Cr0JIQD4ZNwqW4BVzJ3hPqNNqTlqT3n6EwZbA2QmtQ&e=>

https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Djosefsson-2Dpkix-2Dnewcurves-2D01&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=2v9OTM-p3Rfw9BjjUvORkrw1CtSoOGJ5__d0bjfO3T4&e=>

https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Djosefsson-2Dpkix-2Deddsa-2D04&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=91WgjOyYD2l3w2d4m56dNNW0wtby85O1U9IjobAfF8I&e=>
https://datatracker.ietf.org/doc/draft-ssh-ext-info<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dssh-2Dext-2Dinfo&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=8bYJbpVQhmWwUaDb2gcnYCcCMBhMCxMUIsJ3_AO1_g4&e=>

https://datatracker.ietf.org/doc/draft-rsa-dsa-sha2-256<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drsa-2Ddsa-2Dsha2-2D256&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=7JdsYjIKOeZEILu9PlHMU5xPo9PeMmHgqua1iMzN4-Q&e=>

https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbaushke-2Dssh-2Ddh-2Dgroup-2Dsha2&d=CwMFBA&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0oVzqfiGHLhUcbZeXunQy6jvtbC-eihfuv-KSbpd8kg&s=nyXjHSQSrbT-OOmylPHjgrchVTg-CSDHivfai_2nJcc&e=>

BR,

Rich and Daniel

[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]
www.ericsson.com

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 19 Feb 2016 14:56:17 -0800

Did you mean draft-ietf-curdle-dnskey-ed25519, not the personal draft 
draft-sury-dnskey-ed25519?

More importantly, you included the 448 algorithms in your list even 
though many people expressed hesitation about them in the earlier 
threads on this list. Personally, I would prefer that we just deal with 
25519 for now instead of confusing the user community with "strong 
enough for everyone" and "stonger enougher for even morethaneveryone".

If a small number of national security agencies want stronger than 
128-bit security, they can do their own standardization.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Feb 2016 18:42:53 -0500

On Fri, Feb 19, 2016 at 5:56 PM, Paul Hoffman <[email-masked]> wrote:
> More importantly, you included the 448 algorithms in your list even though
> many people expressed hesitation about them in the earlier threads on this
> list. Personally, I would prefer that we just deal with 25519 for now
> instead of confusing the user community with "strong enough for everyone"
> and "stonger enougher for even morethaneveryone".
>
> If a small number of national security agencies want stronger than 128-bit
> security, they can do their own standardization.

We are chartered to do Curve448. We should do curve 448.

I am opposed to watering down security to what people think is
adequate. There is an existing deployment on the old NIST Curve 384. I
want to replace that with the CFRG work. Only a stronger replacement
is going to be acceptable.

The cost in making the change does not change significantly with the
number of algorithms involved. So doing half the job now and half
later means double the work.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 19 Feb 2016 16:17:39 -0800

I have no problems with any of the drafts.

There is an open question if there is a need for curve448
to use SHA2-512 rather than SHA2-256.

The discussion has mostly occured on the [email-masked]
list and asks the question because of the suggestion of this
document:

   https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm

wherein SHA2-256 is not considered strong enough for Top Secret and
SHA2-384 or higher would seem to satisfy those requirements.

I leave the merits of such a selection to the cryptographers on this
list who likely have a better understanding of the security implications
of such a change.

	Thank you,
	-- Mark

---

From: Daniel Migault <[email-masked]>
Date: Sat, 20 Feb 2016 01:31:33 +0000

Hi,

The URLs were badly displayed on the previous mail. For clarification, I am re-sending the list of draft we think there is a consensus for adoption. If anyone object, please let us know by Feb 26.

draft-bjh21-ssh-ed25519-02
draft-josefsson-ssh-curves-00
draft-sury-dnskey-ed25519-03
draft-sury-dnskey-ed448-00
draft-josefsson-pkix-newcurves-01
draft-josefsson-pkix-eddsa-04
draft-ssh-ext-info
draft-rsa-dsa-sha2-256
draft-baushke-ssh-dh-group-sha2

BR,

Rich and Daniel

From: Curdle [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Friday, February 19, 2016 5:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Curdle] Adoption

Hi,

BR,

Rich and Daniel

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Feb 2016 20:47:54 -0500

> to use SHA2-512 rather than SHA2-256.

Doesn't the curve448 draft require SHA2-512?

It is always possible to insert another hash, but isn't the signature
function specified over an input consisting of an arbitrary length bit
string rather than over the output of a hash function?

> SHA2-384 or higher would seem to satisfy those requirements.

I don't agree that meeting the criteria for US Top Secret should be a
requirement, it is only just another national standard. But providing
an equivalent level of security should be. We want it to be possible
for NIST to adopt CFRG curves in place of their 15 year old curves.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 19 Feb 2016 18:38:28 -0800

> > More importantly, you included the 448 algorithms in your list even
though
> > If a small number of national security agencies want stronger than
128-bit
> is going to be acceptable.

What is the actual consequence of a quantum or classical break for
authentication? Answer: assuming that you've migrated by the time the break
happens, nothing. What about encryption? You lose all confidentiality even
for old messages.

There is no reason to use Curve448 in authentication. Using it is actively
harmful as it makes authentication slow and includes unnecessary
flexibility.

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 20 Feb 2016 14:24:55 +0000

Speaking as chair, Phil's right: 448 is in the charter.
Speaking as an individual: it would feel wrong for us not to pick up the CFRG work.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 20 Feb 2016 07:03:31 -0800

> Speaking as an individual: it would feel wrong for us not to pick up 

Historically, the CFRG, as an RG, does lots of work that is not yet 
meant for IETF adoption. The IETF gets to pick which of the outputs are 
appropriate for its protocols and operational guidance.

The fact that 448 is in the charter is irrelevant to the question of 
adoption. Lots of WGs take a wide charter and work on a narrower subset 
based on discussion about the actual value of the bits in the charter.

To date, no one has given any reason to need a signature mechanism with 
more than 255 bits of effective strength. People here, and in the CFRG, 
have expressed concern that a proliferation of signature mechanisms has 
a negative operational impact.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 20 Feb 2016 15:44:32 +0000

> Historically, the CFRG, as an RG, does lots of work that is not yet meant for
> IETF adoption. The IETF gets to pick which of the outputs are appropriate for
> its protocols and operational guidance.

Except that in this case, they were responding to TLS-WG requests.

I believe many folks want purely-open curves at 25519 and 448 strengths.  And if there are those that don't, they don't need to use the docs we prepare here.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 20 Feb 2016 08:14:41 -0800

On 20 Feb 2016, at 7:44, Salz, Rich wrote:

>> meant for

If the TLS WG still wants 448, great: this WG can adopt that. That 
doesn't affect a bunch of the other drafts, right?

> I believe many folks want purely-open curves at 25519 and 448 
> strengths.  And if there are those that don't, they don't need to use 
> the docs we prepare here.

Some folks believe that unneeded algorithm proliferation has had a 
negative effect on security operations. (Some people would claim that 
the TLS WG is a poster child for this problem...) The "D" in our WG name 
is there for a good reason. So, it's not a question of "just don't use 
it" if it is being promoted by the IETF.

Having said that, if CURDLE wants to standardize everything in the list, 
we'll all live with the user and operator confusion, just as we have 
before. It is still worth pointing out that starting with assumptions 
about curve strength that originate from a use case that essentially 
none of us have should affect our choices in what we adopt.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 20 Feb 2016 11:39:55 -0500

There is definitely industry demand for 448. If we had been satisfied
25519 is enough we would have done it.

We want a safety margin and so do our customers.

In this case I am mystified as to why an individual who does not sell
crypto to anyone would be so intent on watering down the security
those of us who do can offer.

While I do not trust the NSA on every issue, one thing I am willing to
trust them on is the notion of what is a sufficient work factor. Or at
least, I will take their recommendation as a minimum.

On Sat, Feb 20, 2016 at 10:03 AM, Paul Hoffman <[email-masked]> wrote:
> Historically, the CFRG, as an RG, does lots of work that is not yet meant
> for IETF adoption. The IETF gets to pick which of the outputs are
> To date, no one has given any reason to need a signature mechanism with more
> than 255 bits of effective strength. People here, and in the CFRG, have
> expressed concern that a proliferation of signature mechanisms has a
> negative operational impact.
>
>
> --Paul Hoffman
>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 20 Feb 2016 08:53:24 -0800

Am I actually reducing the security of what your customers have? No.

As I've repeatedly said and you've seemed to ignore authentication and
encryption have different properties. In the web context online
signatures need to be done with end-entity certs once per connection,
frequently. Therefore end-entity certs use P256 or maybe will end up
with 25519. It's much faster if the entire chain uses the same
algorithm, but because of this blather about "maximal security for
important keys" (ignoring the fact that authentication doesn't need to
last for longer than key lifetimes, while encryption does) we have a
much slower verification.

This directly impacts crypto adoption.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 20 Feb 2016 09:01:57 -0800

> 25519 is enough we would have done it.

If you can show where that industry demand is, that would be great. So 
far, I only see the interest from individuals.

> We want a safety margin and so do our customers.

Of course: that's why a work effort of 128 was chosen instead of 96.

> those of us who do can offer.

I "sell" crypto as much as, or more than, you do, Phill. We both also 
sell operational stability. Having fewer needless choices is the reason 
for my suggestion to the WG.

I assume from your personal attack above that you are indicating that 
you somehow represent the PKI industry. Even if that's the case, note 
that PKI is not used in all the proposals before this WG. (If you don't 
actually represent the PKI industry, this WG would be well-served if you 
were to bring to it a recommendation from a group that does.)

> least, I will take their recommendation as a minimum.

Great: their recommendation is 128 bits even for secret material that 
has could lead to widespread death and destruction. Their recommendation 
for 192 work factor is for top secret, something that only people who 
work for governments who don't care about IETF standards care about.

--Paul Hoffman

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sat, 20 Feb 2016 09:10:40 -0800

> Doesn't the curve448 draft require SHA2-512?

I am directing my comments to draft-josefsson-ssh-curves-03

   IANA is requested to add "curve25519-sha256" and "curve448-sha256" to
   the "Key Exchange Method Names" registry for SSH that was created in
   RFC 4250 section 4.10 [RFC4250].

The name curve448-sha256 may be the confusion here.

RFC5656 chapter 4 is referenced as to the structure of the exchange hash
and that references RFC5656 section 10 which does specify SHA-256.

Perhaps clarification of the draft-josefsson-ssh-curves-03 as to the
hash expected to be used by naming curve448 to include sha512 in the
name would cause less confusion?

> string rather than over the output of a hash function?

I-D.irtf-cfrg-curves and RFC5656 are both used as Normative References.

	-- Mark

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 20 Feb 2016 12:12:30 -0500

> Am I actually reducing the security of what your customers have? No.

Yes, they are already using Curve 384. End of story.

And what is more, they are exceptionally nervous about any suggestion that
specifications are being watered down at the request of the NSA BULLRUN
agents. And they are quite right to.

> encryption have different properties.

Yes, to first order, authentication matters and encryption does not. The WebPKI
is an authentication infrastructure, that is what it was designed to be.

If you have a root key worth an eight figure sum, you would want it to
have a work
factor that gives a sufficient margin in case of a weakness in the
algorithm. The most
likely form of significant attack being a meet in the middle type
attack that reduces
the work factor to the square root of the original.

> In the web context online
> with 25519.

Perhaps you should look at what is actually being sold today.

---

From: Peter Bowen <[email-masked]>
Date: Sat, 20 Feb 2016 10:50:40 -0800

> I believe many folks want purely-open curves at 25519 and 448 strengths.  And if there are those that don't, they don't need to use the docs we prepare here.

I am in favor of adopting drafts for both curves for at least PKIX and
TLS.  Both NIST P-256 an P-384 are widely deployed today with PKIX and
TLS.  As one of the primary arguments for doing this work is to have
"purely-open" curves, I think it would be a disservice to force users
to choose between strength and open-ness. Similarly, I think only
adopting 448 (although not suggested) would be a poor choice because
then users would be choosing between performance and open-ness.

I would also be remiss if I did not point out that, at least for PKIX
and possibly DNSSEC, any curve will not be widely deployed until there
is support in hardware-based security modules.  Therefore any it makes
more sense to adopt both curves now, to help ensure there is hardware
support.

Thanks,
Peter

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 21 Feb 2016 10:40:08 +0000

Paul Hoffman <[email-masked]> writes:

>We both also sell operational stability. Having fewer needless choices is the
>reason for my suggestion to the WG.

+1.  Look at the figures that Yoav Nir just quoted for the NIST curves, for
example:

  P-256 is use much more than P-384, and P-521 is practically unheard of
  (53748:12:1 according to [1])

That's a pretty clear indicator of what the industry has opted for.  People
can argue for P521 till they're blue in the face, but it doesn't help if the
odds against are 54K to one.  If you want to go where the industry demand is,
you do P256 and not P384 or P521.

(That's for the NIST curves obviously, since we have hard data for those.
Extending this to 25519 and 448 and 3.141 and 6.022e23 and the rest of the
menagerie are left as exercises for the reader).

Peter.

---

From: Peter Bowen <[email-masked]>
Date: Sun, 21 Feb 2016 05:24:21 -0800

>   (53748:12:1 according to [1])

Conversely, for PKIX trust anchors in the Mozilla trust store, the
ratio is 1:10:0.  One anchor uses P-256, 10 anchors use P-384, and
none use P-521.  In the Microsoft trust store the ratio is 2:18:0.

Both CAs that have P-256 anchors also have P-384 anchors.

At least for drafts relevant to long term signatures (including PKIX
and DNSSEC), I would suggest that both curves be adopted.

Thanks,
Peter

---

From: Watson Ladd <[email-masked]>
Date: Sun, 21 Feb 2016 05:30:56 -0800

> the work factor to the square root of the original.

Funny, you don't look like Claus Diem to me. Of course, an attacker with
that level of insight can already crack the P256 encryption and read
everything.
> Perhaps you should look at what is actually being sold today.

Mozilla Telemetry does not show P384 showing up with any frequency as the
curve protecting the communications. Strong authentication is irrelevant as
encryption is what needs to last. Maybe you shouldn't lie to your customers.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 22 Feb 2016 13:41:31 +0100 (CET)

Paul,

we spoke about the need or rather "no-need" for Ed448 in DNSSEC in person and while I am inclined in favor of no-need, I think that it doesn't really make sense to have a lengthy debate before the adoption.  Adopting an I-D into WG doesn't mean that the RFC has to be produced, right?

So to be more productive than just ping-ponging back the already said arguments, let's just adopt Ed448 for DNSSEC and ask people to contribute the reasoning for Ed448 directly into the draft, and we can have this mud fight^H^Hcivil argument after this has been done.  Things said in emails get lost, while they tend to last when written do in I-D.

Cheers,
Ondrej

----- Original Message -----
> From: "Paul Hoffman" <[email-masked]>
> To: "Salz, Rich" <[email-masked]>
> Cc: [email-masked]
> Sent: Saturday, February 20, 2016 4:03:31 PM
> Subject: Re: [Curdle] Adoption

> a negative operational impact.

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 22 Feb 2016 06:25:16 -0800

On 22 Feb 2016, at 4:41, Ondřej Surý wrote:

> we spoke about the need or rather "no-need" for Ed448 in DNSSEC in 
> person and while I am inclined in favor of no-need, I think that it 
> doesn't really make sense to have a lengthy debate before the 
> adoption.  Adopting an I-D into WG doesn't mean that the RFC has to be 
> produced, right?

Correct, it technically does not. However, all of us here have been in 
plenty of WGs where adopted drafts got moved forward "because why else 
would we have adopted them" and, as you already saw in this thread, 
"because it's in our charter".

> So to be more productive than just ping-ponging back the already said 
> arguments, let's just adopt Ed448 for DNSSEC and ask people to 
> contribute the reasoning for Ed448 directly into the draft, and we can 
> have this mud fight^H^Hcivil argument after this has been done.  
> Things said in emails get lost, while they tend to last when written 
> do in I-D.

Thank you, that's an excellent point. If the WG goes ahead with any of 
the Ed448 docs (which it seems likely to do at least for some), having 
those document explicitly state what their expected use will be given 
the coexistence of 25519 document would be quite valuable.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 22 Feb 2016 17:24:37 +0100 (CET)

----- Original Message -----
> To: "Ondřej Surý" <[email-masked]>
> Cc: "Salz, Rich" <[email-masked]>, [email-masked]
> Sent: Monday, February 22, 2016 3:25:16 PM

> "because it's in our charter".

Would adding a prominent (at the beginning, at the end) notice to the I-D that this draft was adopted to be thoroughly discussed in the WG, but it's not necessarily meant for ending as RFC, help to adopt this?  So we can move on?

Or just adding an empty "Justification section" somewhere with similar note that can be dropped when the Justification section has been beaten to the death in the WG. 

> the coexistence of 25519 document would be quite valuable.

Wholeheartedly agree.

As an author of DNSSEC-Ed448 I don't care that much whether the I-D gets adopted or not, I am fine both ways, that's for WG to decide as a group, I just don't want my beard to go white while reading the lengthy arguments running back and forth and waiting for a decision.

Cheers,

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Feb 2016 16:29:50 +0000

> Would adding a prominent (at the beginning, at the end) notice to the I-D
> that this draft was adopted to be thoroughly discussed in the WG, but it's not
> necessarily meant for ending as RFC, help to adopt this?  So we can move on?

Not needed.  That's what adoption means.  So far it seems that Paul is the only one opposed; do others agree with him, or is he "in the rough" in terms of consensus?