Subject: Re: [CFRG] eddsa (un)suited for mandatory to implement ciphersuite?

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Feb 2022 17:25:18 +0000

Hiya,

Thanks for all the discussion on this.

For me, one conclusion so far is that CFRG ought
try address issues relevant for use of our crypto
mechanisms for cases of small-devices that are
likely to be in the hands of an adversary. That
could be based on John's draft or otherwise but I
think it should be done.

Can we add something on that as an agenda item
for IETF103? If so, I'm happy if someone else leads
that or, if needed, I can do up a slide posing the
question from the LAKE WG. It could also be good
if someone who has experience mounting this kind
of attack made a pressie about that too.

My 2nd, more tentative, conclusion is that ECDSA
isn't really any better here than EdDSA. That's based
on reading [1,2] but if I've missed some significant
difference (e.g. compared to [3]) it'd be great to
know. The attacks in [2] and [3] are not the same,
but ISTM their effects on what we recommend for IETF
protocols like EDHOC aren't much different.

Cheers,
S.

PS: I found [1] really helped me grok these injection
attacks, so I'd recommend it to others who start off
from a similarly ignorant place as I did:-)

[1] https://eprint.iacr.org/2010/130.pdf
[2] 
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1091.528&rep=rep1&type=pdf
[3] https://eprint.iacr.org/2017/985.pdf

---

From: John Mattsson <[email-masked]>
Date: Tue, 8 Feb 2022 18:27:12 +0000

+1 for discussing this at IETF113

From: CFRG <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Date: Tuesday, 8 February 2022 at 18:26
To: [email-masked] <[email-masked]>
Subject: Re: [CFRG] eddsa (un)suited for mandatory to implement ciphersuite?

Hiya,

Cheers,
S.

[1] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-d2f8ceb5516ec912&q=1&e=997f513b-dca2-4600-91df-7a0851cccd5e&u=https%3A%2F%2Feprint.iacr.org%2F2010%2F130.pdf
[2]
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1091.528&rep=rep1&type=pdf
[3] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-d277a0eadd2234f6&q=1&e=997f513b-dca2-4600-91df-7a0851cccd5e&u=https%3A%2F%2Feprint.iacr.org%2F2017%2F985.pdf

---

From: Rene Struik <[email-masked]>
Date: Tue, 8 Feb 2022 13:44:20 -0500

Hi Steve:

It is amazing that you could draw up your 2nd conclusion while throwing 
some random references, without analysis, in the air to "support" your 
assertion and then (sic!) finishing off "so I'd recommend it to others 
who start off  from a similarly ignorant place as I did:-)"

Wouldn't it serve us all well (remember: CFRG is supposed to be a 
research group) if you would try and be a little bit less biased here?

Just out of curiosity, I did some investigating on how RFC 7748 and RFC 
8032 came to be:

It looks like both RFC 7748 and RFC 8032 were produced at break-neck 
speed (see [1], [2]), with hardly any record of due diligence, where the 
datatracker on RFC 8032 only shows an IESG conflict review, and no IRSG 
or IESG review, and where the history shows that IESG review took 11 
days only (a record), with ballot position on rev00 (sic!) with zero 
content [3] and where the narrative minutes of the IESG telechat of Oct 
13, 2016 [4] only shows that "Steve [Stephen Farrell, the Security AD at 
the time] did the review, no discusses, approved to go back to IRTF". 
This shines a somewhat embarrassing light on how this seemed to have 
been "rammed through"; hence, my earlier (unanswered) process question 
on May 13, 2020 [5].

Two questions to you:
a) could you forward us the record of the alleged review of 
rfc8032-to-be that you suggested in your official capacity at IESG at 
the time, or -- is it simply not there?
b) did you consider SCA and other implementation attacks, when you did 
report on your review?

Rene

Ref:
[1] https://datatracker.ietf.org/doc/rfc8032/history/
[2] https://datatracker.ietf.org/doc/rfc7748/history/
[3] https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-eddsa/ballot/
[4] 
https://www6.ietf.org/iesg/minutes/2016/narrative-minutes-2016-10-13.html
[5] https://mailarchive.ietf.org/arch/msg/cfrg/MOSFCwf5djn7FzjBjEbak1LwCiY/

On 2022-02-08 12:25 p.m., Stephen Farrell wrote:
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Feb 2022 19:37:10 +0000

Rene,

I have to say I've no idea why you're being so antagonistic
and accusatory towards anyone who doesn't seem to share your
position on this topic. In my experience, that's always been
counterproductive.

And for the record, I reject your unfounded accusations
below of bias or of process problems in the past - you're
just wrong about those, but luckily (for me) that doesn't
bother me even a teeny bit:-)

On 08/02/2022 18:44, Rene Struik wrote:
> some random references, 

Those weren't random. For me, an important question in all
this is whether or not any of our signature schemes are
significantly better or worse than one another when the
device is under the adversary's control. Hence [2].

Are you claiming the results in [2] are wrong? If so, I'd
be interested in that and the your reasoning for that
position.

> without analysis, in the air to "support" your 
> speed 

You are incorrect. I suspect that's because of a lack of
knowledge of the RFC5742 conflict review process.

Cheers,
S.

> (see [1], [2]), with hardly any record of due diligence, where the 
> [3] 
> https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-eddsa/ballot/
> [4]

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 8 Feb 2022 22:24:34 +0000

It would be nice if the discussion tone cooled down a bit. I know - I'm the one to talk about discussion tone, but still...

IMHO, (a) Rene's two questions (follow) deserve an explicit answer, and (b) I rather disagree with your "conclusion is that ECDSA isn't really any better here than EdDSA" - it depends greatly on what kind of attacks you consider.

> Two questions to you:
> a) could you forward us the record of the  .  .  .  review of 
>    rfc8032-to-be?

I'd like to hear explicit details, please. I'm pretty sure others would like that too.
--
Regards,
Uri
 
There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

On 2/8/22, 14:38, "CFRG on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Rene,

    Cheers,
    S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Feb 2022 22:42:18 +0000

Hiya,

On 08/02/2022 22:24, Blumenthal, Uri - 0553 - MITLL wrote:
> It would be nice if the discussion tone cooled down a bit. 

I agree.

> I know -
> I'm the one to talk about discussion tone, but still...
> 
> IMHO, (a) Rene's two questions (follow) deserve an explicit answer,
> and (b) I rather disagree with your "conclusion is that ECDSA isn't
> really any better here than EdDSA" - it depends greatly on what kind
> of attacks you consider.

Hmm. But if the adversary controls a commercial-grade
device, then they can choose pretty freely which attacks
to attempt.

So if (as seems to be the case) all signature schemes
have some bad attack in that scenario, then there is no
"clearly best" one to pick for a broad range of cases,
so we end up back where we started, in terms of picking
an MTI algorithm. (I'd still like CFRG to improve schemes
where possible of course.)

WRT the history, you need to read RFC5742. The part of
the history Rene referred to was a conflict-review not
a detailed technical review. The latter happened over
extended periods in the CFRG/IRTF and not during the
conflict-review, which is almost always only a couple
of weeks duration and is lead by (someone on) the IESG.
Bringing in process-history nit-picking in this thread
is a nonsense really.

S.

> 
>> Two questions to you: a) could you forward us the record of the  .
>> .  .  review of rfc8032-to-be? b) did you consider SCA and other
>> implementation attacks, when you did report on your review?
> 
> I'd like to hear explicit details, please. I'm pretty sure others
> would like that too. -- Regards, Uri
> 
> There are two ways to design a system. One is to make it so simple
> there are obviously no deficiencies. The other is to make it so
> complex there are no obvious deficiencies. -  C. A. R. Hoare
> 
> 
> On 2/8/22, 14:38, "CFRG on behalf of Stephen Farrell"
> <[email-masked] on behalf of [email-masked]>
> wrote:
> 
> 
> Rene,
> 
> I have to say I've no idea why you're being so antagonistic and
> accusatory towards anyone who doesn't seem to share your position on
> this topic. In my experience, that's always been counterproductive.
> 
> And for the record, I reject your unfounded accusations below of bias
> or of process problems in the past - you're just wrong about those,
> but luckily (for me) that doesn't bother me even a teeny bit:-)
> 
>> It is amazing that you could draw up your 2nd conclusion while
>> throwing some random references,
> 
> Those weren't random. For me, an important question in all this is
> whether or not any of our signature schemes are significantly better
> or worse than one another when the device is under the adversary's
> control. Hence [2].
> 
> Are you claiming the results in [2] are wrong? If so, I'd be
> interested in that and the your reasoning for that position.
> 
>> without analysis, in the air to "support" your assertion and then
>> (sic!) finishing off "so I'd recommend it to others who start off
>> from a similarly ignorant place as I did:-)"
>> 
>> Just out of curiosity, I did some investigating on how RFC 7748 and
>> RFC 8032 came to be:
>> 
>> It looks like both RFC 7748 and RFC 8032 were produced at
>> break-neck speed
> 
> You are incorrect. I suspect that's because of a lack of knowledge of
> the RFC5742 conflict review process.
> 
> Cheers, S.
> 
> 
>> datatracker on RFC 8032 only shows an IESG conflict review, and no
>> IRSG or IESG review, and where the history shows that IESG review
>> took 11 days only (a record), with ballot position on rev00 (sic!)
>> with zero content [3] and where the narrative minutes of the IESG
>> telechat of Oct 13, 2016 [4] only shows that "Steve [Stephen
>> Farrell, the Security AD at the time] did the review, no discusses,
>> approved to go back to IRTF". This shines a somewhat embarrassing
>> light on how this seemed to have been "rammed through"; hence, my
>> earlier (unanswered) process question on May 13, 2020 [5].
>> 
>> Two questions to you: a) could you forward us the record of the
>> alleged review of rfc8032-to-be that you suggested in your official
>> capacity at IESG at the time, or -- is it simply not there? b) did
>> you consider SCA and other implementation attacks, when you did 
>> report on your review?
>> 
>> Rene
>> 
>> Ref: [1] https://datatracker.ietf.org/doc/rfc8032/history/ [2]
>> https://datatracker.ietf.org/doc/rfc7748/history/ [3] 
> [5]
> https://mailarchive.ietf.org/arch/msg/cfrg/MOSFCwf5djn7FzjBjEbak1LwCiY/
>
> 
> 
>> 
>> 
>>> For me, one conclusion so far is that CFRG ought try address
>>> issues relevant for use of our crypto mechanisms for cases of
>>> small-devices that are likely to be in the hands of an adversary.
>>> That could be based on John's draft or otherwise but I think it
>>> should be done.
>>> 
>>> Can we add something on that as an agenda item for IETF103? If
>>> so, I'm happy if someone else leads that or, if needed, I can do
>>> up a slide posing the question from the LAKE WG. It could also be
>>> good if someone who has experience mounting this kind of attack
>>> made a pressie about that too.
>>> 
>>> My 2nd, more tentative, conclusion is that ECDSA isn't really any
>>> better here than EdDSA. That's based on reading [1,2] but if I've
>>> missed some significant difference (e.g. compared to [3]) it'd be
>>> great to know. The attacks in [2] and [3] are not the same, but
>>> ISTM their effects on what we recommend for IETF protocols like
>>> EDHOC aren't much different.
>>> 
>>> Cheers, S.
>>> 
>>> PS: I found [1] really helped me grok these injection attacks, so
>>> I'd recommend it to others who start off from a similarly
>>> ignorant place as I did:-)
>>> 
>>> [1] https://eprint.iacr.org/2010/130.pdf [2] 
>>> _______________________________________________ CFRG mailing
>>> list [email-masked] https://www.irtf.org/mailman/listinfo/cfrg
>> 
>>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 9 Feb 2022 00:12:52 +0000

> device, then they can choose pretty freely which attacks

First, not quite (unless by "adversary" you mean a well-funded nation-state or something like Cartel). Different attacks carry different costs and may require different level of skills, etc. So, not every attacker can mount every kind of attack. (And all of that argument better be explicit.)

Second, who said that my interest is limited to commercial-grade devices? ;-)

> an MTI algorithm. 

Not quite. I'm pretty tired, so I may misunderstand - but the above sounds to me like "there always will be an attack that breaks the given scheme, so all the schemes are equally good in that sense". Needless to say, I disagree.

> (I'd still like CFRG to improve schemes

Oh, me too.

> WRT the history, you need to read RFC5742.

Frankly, I don't care about history. But would like to see the actual technical review, and read what it said about algorithm strength against attacks. In particular - what attacks were considered, and what attacks were explicitly ruled outside the scope.
 
TNX

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Feb 2022 00:38:26 +0000

Hiya,

On 09/02/2022 00:12, Blumenthal, Uri - 0553 - MITLL wrote:
>>> IMHO, (a) Rene's two questions (follow) deserve an explicit
>>> answer, and (b) I rather disagree with your "conclusion is that
>>> ECDSA isn't really any better here than EdDSA" - it depends
>>> greatly on what kind of attacks you consider.
>> 
>> Hmm. But if the adversary controls a commercial-grade device, then
>> they can choose pretty freely which attacks to attempt.
> 
> First, not quite (unless by "adversary" you mean a well-funded
> nation-state or something like Cartel). Different attacks carry
> different costs and may require different level of skills, etc. So,
> not every attacker can mount every kind of attack. (And all of that
> argument better be explicit.)

Generally, I'd consider that if an attack proves profitable,
the per-run costs to replicate that attack will fall quickly.
Also, pulling a private key from one device could enable
many clones to be made etc so the extraction cost isn't the
only factor.

But sure, if an attack requires >>€1M and there's no way to
see how that cost could produce a profit, that's likely a
less interesting attack. Some of the relevant attacks are
pretty cheap though esp lowering voltage, and attacks do only
get better etc.

I also don't think there's any signature scheme for which
*only* hugely expensive attacks are known (for this context)
but if that were the case, it'd for sure be good to know.

The costs of the devices themselves are also likely in many
cases to be decreasing, and probably in a bunch of cases,
being more easily attacked as a result.

> Second, who said that my interest is limited to commercial-grade

Sure. I'd assume higher-grade devices would have to meet
additional requirements profiled elsewhere.

> 
>> So if (as seems to be the case) all signature schemes have some bad
>> attack in that scenario, then there is no "clearly best" one to
>> pick for a broad range of cases, so we end up back where we
>> started, in terms of picking an MTI algorithm.
> 
> Not quite. I'm pretty tired, so I may misunderstand - but the above
> sounds to me like "there always will be an attack that breaks the
> given scheme, so all the schemes are equally good in that sense".
> Needless to say, I disagree.

I'd also disagree with that phrasing, same as you:-)

What seems to be the case is:

- (in the given context) private key extraction attacks
are known for (IIUC) all viable signature schemes
- therefore there is no one "clearly best" scheme,
- and there's also no "clearly way worse" scheme (that
is viable in the more typical Internet threat model
context)

So I think we end up where we started basically, albeit
with a better understanding of the specific attacks (in
my case anyway).

That doesn't mean all schemes are equal, just that (I think)
there are no stand-out winners or losers when it comes to
picking an MTI for a protocol in that context.

> 
>> (I'd still like CFRG to improve schemes where possible of course.)
> 
> Oh, me too.
> 
> Frankly, I don't care about history. But would like to see the actual
> technical review, 

The CFRG list archives and meeting minutes are what you'd
review then, and (perhaps more) pointers from those to the
technical literature. But maybe someone more involved in that
discussion can provide better pointers (I was more of a
bystander myself at the time:-)

Cheers,
S.

> and read what it said about algorithm strength
> against attacks. In particular - what attacks were considered, and
> what attacks were explicitly ruled outside the scope.
> 
> TNX

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Feb 2022 09:46:11 +0000

Rene,

To clarify the process: the IESG has no role in approving or conducting technical review of IRTF drafts. The purpose of the IESG review is solely to check there are no conflicts between an IRTF draft and the standards work the IETF is doing. The time taken, and the level of detail provided, in the IESG reviews of the drafts that became RFC 7748 and RFC 8032 is normal.

To compare, the IESG review for SPAKE2, that just concluded, was initiated on 25 January 2022 and concluded on 7 February, and is similarly brief (details at https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-spake2/ballot/ <https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-spake2/ballot/>).

Colin

> On 8 Feb 2022, at 18:44, Rene Struik <[email-masked]> wrote:
> 
> Hi Steve:
> 
> It is amazing that you could draw up your 2nd conclusion while throwing some random references, without analysis, in the air to "support" your assertion and then (sic!) finishing off "so I'd recommend it to others who start off  from a similarly ignorant place as I did:-)"
> 
> Wouldn't it serve us all well (remember: CFRG is supposed to be a research group) if you would try and be a little bit less biased here?
> 
> Just out of curiosity, I did some investigating on how RFC 7748 and RFC 8032 came to be:
> 
> It looks like both RFC 7748 and RFC 8032 were produced at break-neck speed (see [1], [2]), with hardly any record of due diligence, where the datatracker on RFC 8032 only shows an IESG conflict review, and no IRSG or IESG review, and where the history shows that IESG review took 11 days only (a record), with ballot position on rev00 (sic!) with zero content [3] and where the narrative minutes of the IESG telechat of Oct 13, 2016 [4] only shows that "Steve [Stephen Farrell, the Security AD at the time] did the review, no discusses, approved to go back to IRTF". This shines a somewhat embarrassing light on how this seemed to have been "rammed through"; hence, my earlier (unanswered) process question on May 13, 2020 [5].
> 
> Two questions to you:
> a) could you forward us the record of the alleged review of rfc8032-to-be that you suggested in your official capacity at IESG at the time, or -- is it simply not there?
> b) did you consider SCA and other implementation attacks, when you did report on your review?
> 
> Rene
> 
> Ref:
> [4] https://www6.ietf.org/iesg/minutes/2016/narrative-minutes-2016-10-13.html
>> [2] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1091.528&rep=rep1&type=pdf

-- 
Colin Perkins
https://csperkins.org/

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 10 Feb 2022 09:46:08 +0000

Colin Perkins <[email-masked]> writes:

>To compare, the IESG review for SPAKE2, that just concluded, was initiated on
>25 January 2022 and concluded on 7 February, and is similarly brief (details
>at https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-spake2/ballot/).

And at the other end of the scale, the IESG review for e.g. RFC 8894 took just
over two years ("IESG state changed to In Last Call" to "IESG state changed to
Approved-announcement sent"), and was not brief.  So it can go either way.

Peter.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Feb 2022 11:36:19 +0000

> On 10 Feb 2022, at 09:46, Peter Gutmann <[email-masked]> wrote:
> 

RFC 8894 is on the IETF stream; the IESG were supposed to do a detailed technical review in that case. CFRG drafts are on the IRTF stream, where the IESG does not perform such a review (the CFRG and IRSG do the review instead).

Colin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Feb 2022 11:48:04 +0000

On 10/02/2022 11:36, Colin Perkins wrote:
>> And at the other end of the scale, the IESG review for e.g. RFC
>> 8894 took just over two years ("IESG state changed to In Last Call"
>> to "IESG state changed to Approved-announcement sent"), and was not
>> brief.  So it can go either way.
> 
> RFC 8894 is on the IETF stream; the IESG were supposed to do a
> detailed technical review in that case. CFRG drafts are on the IRTF
> stream, where the IESG does not perform such a review (the CFRG and
> IRSG do the review instead).
What Colin said.

But RFC8894 was also a very special case in IETF land,
having wallowed around for 18 years before it got to
the IESG;-)

S.