Subject: [Cfrg] draft-atkins-suit-cose-walnutdsa on the Independent Stream

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Sun, 19 Jan 2020 13:55:02 -0800

Hi CFRG,

Derek Atkins has presented draft-atkins-suit-cose-walnutdsa to me for
publication as an Independent Submission Informational RFC.

I think this is the sort of draft that would benefit from the CFRG's
wisdom and would appreciate any reviews or guidance that you're able to
give.

The latest version of the draft can be found at
https://datatracker.ietf.org/doc/draft-atkins-suit-cose-walnutdsa/

If you could cc me on any discussions (or send them off list) that would
be helpful.

Many thanks,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: "Paterson Kenneth" <[email-masked]>
Date: Sun, 19 Jan 2020 22:25:27 +0000

Hi Adrian,

I'm no longer a CFRG chair so I can say exactly what I think now :-)

I don't think CFRG should "bless" any draft concerning the WalnutDSA scheme. Notably, this algorithm did not pass to the second round in the NIST competition due to the significant cryptanalysis that it suffered from prior to and in the early stages of the competition. 

It may be that the proposers of this algorithm are able to avoid all currently known attacks by setting parameters carefully, and through extensive modifications to the scheme. But the scheme's history does not inspire confidence. Moreover, my strong sense is that serious cryptanalysts have stopped working on it simply because it did not pass to the second round (put another way, they successfully killed it in the first round).

Best wishes,

Kenny

-- 
Kenny Paterson
Applied Cryptography Group
 
ETH Zurich, Computer Science Dept.
Universitätstrasse 6, CNB E 104.2
CH-8092 Zurich
 
tel. +41 44 632 32 52
www.appliedcrypto.ethz.ch

-----Original Message-----
From: Cfrg <[email-masked]> on behalf of "RFC ISE (Adrian Farrel)" <[email-masked]>
Reply to: "[email-masked]" <[email-masked]>
Date: Sunday, 19 January 2020 at 22:55
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Adrian Farrel <[email-masked]>
Subject: [Cfrg] draft-atkins-suit-cose-walnutdsa on the Independent Stream

    Hi CFRG,

    

    Many thanks,
    Adrian
    -- 
    Adrian Farrel (ISE),
    [email-masked]
    
    _______________________________________________
    Cfrg mailing list
    [email-masked]
    https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 20 Jan 2020 15:28:02 +1100

As a matter of formality, publication on the Independent Submissions Stream wouldn't constitute a blessing by the CFRG, the IETF, or anyone aside.  The only blessing comes from from maybe the ISE within the bounds of that stream.

Let's say that this is "bad crypto" in the sense that it isn't demonstrably good.  It is the purpose of the Independent Submissions Stream to occasionally publish dissenting views where the ISE believes that there is sufficient benefit from doing so.  So the question we might ask is: is there any benefit to having this particular mechanism documented?

If this were widely-deployed not-good crypto, that might change the situation, but the potential for harm in terms of misunderstanding the status of the mechanism seems significant enough to argue for not publishing even then.  In my view.  But, as ISE, that is Adrian's choice and Adrian's choice alone.

I don't particularly like this situation, but that is the price the IETF community previously decided to pay in return for having an outlet for dissenting opinions on its proceedings and outputs.  It's also a very divisive issue where there is not universal agreement about either the value of the outlet or the constraints under which it operates.

On Mon, Jan 20, 2020, at 09:25, Paterson  Kenneth wrote:
> I don't think CFRG should "bless" any draft concerning the WalnutDSA 
> scheme. Notably, this algorithm did not pass to the second round in the 
> NIST competition due to the significant cryptanalysis that it suffered 
> from prior to and in the early stages of the competition. 
> 
> It may be that the proposers of this algorithm are able to avoid all 
> currently known attacks by setting parameters carefully, and through 
> extensive modifications to the scheme. But the scheme's history does 
> not inspire confidence. Moreover, my strong sense is that serious 
> cryptanalysts have stopped working on it simply because it did not pass 
> to the second round (put another way, they successfully killed it in 
> the first round).
> 
> Best wishes,
> 
> Kenny
> 
> 
> -- 
> Kenny Paterson
> Cc: "[email-masked]" 
> <[email-masked]>, Adrian Farrel 
> <[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2020 05:30:32 -0800

Thanks for the summary, Martin.

IMO it is harmful to the Internet for the ISE to publish RFCs containing
cryptographic algorithms that have not gathered widespread use or analysis.
It just creates confusion in an area where confusion is quite harmful.

-Ekr

On Sun, Jan 19, 2020 at 8:28 PM Martin Thomson <[email-masked]> wrote:

> As a matter of formality, publication on the Independent Submissions
> Stream wouldn't constitute a blessing by the CFRG, the IETF, or anyone
> aside.  The only blessing comes from from maybe the ISE within the bounds
> of that stream.
>
> Let's say that this is "bad crypto" in the sense that it isn't
> demonstrably good.  It is the purpose of the Independent Submissions Stream
> to occasionally publish dissenting views where the ISE believes that there
> is sufficient benefit from doing so.  So the question we might ask is: is
> there any benefit to having this particular mechanism documented?
>
> If this were widely-deployed not-good crypto, that might change the
> situation, but the potential for harm in terms of misunderstanding the
> status of the mechanism seems significant enough to argue for not
> publishing even then.  In my view.  But, as ISE, that is Adrian's choice
> and Adrian's choice alone.
>
> I don't particularly like this situation, but that is the price the IETF
> community previously decided to pay in return for having an outlet for
> dissenting opinions on its proceedings and outputs.  It's also a very
> divisive issue where there is not universal agreement about either the
> value of the outlet or the constraints under which it operates.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Jan 2020 13:37:34 +0000

Hiya,

On 20/01/2020 04:28, Martin Thomson wrote:
> situation, but the potential for harm in terms of misunderstanding
> the status of the mechanism seems significant enough to argue for not
> publishing even then.  In my view.  But, as ISE, that is Adrian's
> choice and Adrian's choice alone.

I agree that publishing this now would be detrimental. Once
the NIST PQ stuff reaches a conclusion (in a yearish maybe?)
then I'd expect we'll see a bunch of CFRG RFCs documenting
(some of) the set of algs that that process has produced as
"winners." I think it'd send a very confusing signal to
implementers if other RFCs describing crypto that aims to
be quantum resistant (or protocols using such) are emitted
ahead of those.

After those "winners" are known and sufficiently well
documented, then I'd not object to Derek's draft being
considered again, either by the ISE or CFRG, but having
pretty much any "post quantum" RFC published now seems
to me a bad plan, for any RFC stream.

Two other notes - if the ISE does decide to publish this
then I'd bet the ISE is likely to see more people doing
the same with other algorithms that are no longer in the
running in NISTland, which seems undesirable. (Were there
95 original entrants? I forget;-) Finally, if the ISE did
publish something like this, I'd really hope there'd be
content in the document that explains how this algorithm
got on in NISTland - I didn't see such text in the draft
(but only scanned it quickly) and am not even sure one
could craft good text now, while the NIST process is
still running.

So overall: "Dear ISE - please say no or put this one
on hold 'till the NIST thing is done."

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2020 07:20:28 -0800

On Mon, Jan 20, 2020 at 5:38 AM Stephen Farrell <[email-masked]>
wrote:

> 95 original entrants? I forget;-)

This seems like an important point and one that in general applies to
cryptographic algorithms. I would encourage the ISE to develop a policy
around "alternative" algorithm publications. I would note that the trend in
IETF (or at least in the HTTP-QUIC-TLS-verse) is away from requiring RFCs
in order to register code points, so at least that reason has less force.

-Ekr

Finally, if the ISE did

---

From: Derek Atkins <[email-masked]>
Date: Tue, 28 Jan 2020 21:49:29 -0500

Dear All,

I want to apologize for the delay in sending this response; I was traveling out of the country all of last week.

I want to reply to Kenny’s points by saying that section 5.2 of the draft deals specifically with all the analysis that occurred before, during, and since the NIST Round 1 process.  What Kenny is pointing out is old news, and it’s quite clear how to choose parameters today taking in to consideration everything that Kenny raises. Yes, the parameters chosen in 2017 were too small.  But the summary of https://eprint.iacr.org/2019/472 in section 5.2 shows that each attack is exponential in parameters N and q, and amusingly they are all exponential to approximately the same degree, O(q^((N-1)/2)).  So contrary to what Kenny has said, choosing parameters today is straightforward.  Please see that paper and section 5.2 for more details.

WalnutDSA was not accepted into Round 2 and after meeting with NIST, it was explained there were a host of reasons, many unrelated to the analysis in Round 1. NIST had to make cuts somewhere, and we know they will make more cuts going into Round 3 as many valid methods may not meet the additional criteria NIST may choose to apply.  Based on recent analysis of NewHope going into Round 3, would that change how you feel about it?

This draft is an informational draft, not a standard.  More specifically, it’s a document about how one would use WalnutDSA within COSE, and not about WalnutDSA specifically.  Moreso, it specifically says that WalnutDSA is “not recommended” in the IANA considerations section.  The goal of this draft is to ensure that implementers can write interoperable code that can at least parse the COSE objects in a consistent way.  It says nothing about whether you should trust it as a result of this process, let alone use it.

While I am not asking CFRG to bless WalnutDSA, I am asking it to allow the ISE to publish our request under the guidelines and mandate it has for addressing informational drafts – nothing more and nothing less.

-derek

PS: Apologies to those who get this twice; the CFRG list bounced back my original message sent from my work address.

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant