Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]

["Paterson, Kenny" <[e-mail]>]

Hi Tanja,

On 23/12/2014 01:54, "Tanja Lange" <[e-mail]> wrote:

>Dear Kenny,
>This is a late reply to your reply to Watson.

And this is a slightly less late reply to your message, which arrived
shortly after my Christmas break had begun.

>> 
>To me this sounds like an ideal moment to follow through on the plans
>made earlier. Is there a final requirements list?

No. I believe we reached agreement on all but a couple of the criteria,
but the chairs' attempts to bring about a meaningful discussion about
quantifying degrees of rigidity/wiggle room were unsuccessful at that time
(mid-October). We did not also reach agreement on requirements for
hardware. See my messages:

https://www.ietf.org/mail-archive/web/cfrg/current/msg05286.html


https://www.ietf.org/mail-archive/web/cfrg/current/msg05610.html



>Is there a date when
>the list of curves to evaluate will be stable?
>What will be the deadline
>for comparing performance of arithmetic in different prime fields and
>comparing performance of arithmetic on different curve shapes? What
>will be the deadline for quantifying wiggle room in generation
>procedures?

It doesn't seem to be working in that mechanistic way, I'm afraid, even
though it would have been my preferred approach. Rather, we tried a
structured, requirements-driven approach, and I think it's fair to say
that, while we made progress and found some common ground, we did not
reach complete agreement on a set of requirements (more succinctly: we
failed). The chairs (actually, me) called for a discussion of the
remaining points of contention around requirements, namely hardware
requirements and quantifying wiggle room.

We had a long thread on the former, which degenerated into a discussion
about special primes versus random primes, belatedly resulting in my
message (https://www.ietf.org/mail-archive/web/cfrg/current/msg05610.html)
in which I wrote that:

"I think that we should focus in the immediate future on selecting curves
for special primes for recommendation to the TLS".

No-one objected to this message, as far as I recall from the subsequent
discussions, so I consider that issue settled for the purposes of our
current task. I consider it to be a corollary of this that are no
particular hardware considerations for us to take into account, beyond the
obvious ones with which we started.

Concerning the latter ("quantifying wiggle room"): there was no on-list
discussion that I saw after my message. I understand that it's a delicate
task and that everyone may have had many other things to work on with
higher priority (indeed we are all part-timers here, despite the volume of
messages that may suggest the contrary).

Meanwhile, events have moved on, and, from late November, we (the CFRG
chairs) started to receive messages from our superiors in IRTF and IETF,
namely the IRTF chair (Lars Eggert) and one of the IETF Security Area
Directors (Stephen Farrell) asking us to try to move things more rapidly
towards a conclusion.

When the MGN proposal was put forward, it seemed to the chairs that it
represented a reasonable basis for discussion that, with fine tuning as ,
could meet with the approval of the group.

>We will not get optimal results by tweaking one meta proposal when
>creating a meta proposal was not the original mission and there has
>been very little discussion about requirements for meta proposals
>while we discussed requirements for curves.

Point taken. But when the original mission fails and the external clock is
ticking, it is surely time to try something else. And the particular
curves that are produced by the (tweaked) meta proposal that is currently
on the table seem to meet all of our agreed security requirements and have
reasonable-to-execllent performance to boot.

> We will not receive
>transparency by engaging in horse trading.
>
>'Compromise' is a word that should be banned from this discussion; we
>already have (potentially) compromised curves!

That's indeed an unfortunate collision! However, I think we know what we
mean when we say "compromise" here.

>> I'd be grateful if the folks from the MGN team could say more on the
>>list
>> why they chose this particular prime, and give some insight into the
>> performance impact of choosing it over near neighbours such as 2^389-21.
>> 
>> Others should chime in too - for example, people should feel free to
>> repeat performance numbers from earlier in our discussions (they are out
>> there in the archive somewhere!).
>> 
>> Please let's collaborate and see if we can swiftly resolve whether there
>> is a significant performance impact or not.
>> 
>I think a competition has more to offer than a 'collaboration' where
>parties get more influence by having more people send emails to the list.

1. This process has never been a competition, in the AES or SHA-3 sense.
It was not set up that way, and it was not intended to run as such. Maybe
people really are under that misapprehension - it would certainly explain
some of the behaviour and petty point scoring that I've seen on the list.

2. If you want to make an accusation that specific parties have been
"DoSing the list" then I think you need to be more specific than this. You
can direct your comments to the chairs or to Lars Eggert off list if you
wish.

>What should count are the merits of papers, implementations, and internet
>drafts so that proposals get more influence by being objectively better.

I could not agree more. But what what you have to remember, I think, is
that no single party or group has a monopoly on papers or implementations
in this area. While no-one doubts the high value of the contributions that
you and your co-authors have made over a period of many years to the
development of "modern ECC", there are now plenty of other people who have
learned from and built upon your work.

>
>So, I would very much like to support what Kenny said:
>> Let's get past instinct to hard numbers.
>> 
>... but I think this needs clear requirements, deadlines etc.

And I'll repeat what I wrote above, in short form: we tried to extract
requirements, and while we made progress, we did not complete even this
initial task satisfactorily. I am not apportioning blame for that, and I
will happily take my share of it (and, believe me, some people have been
quick to e-mail me off-list to tell me exactly what my due share of it
is!).

More to follow in the coming days on deadlines and process.

Cheers

Kenny