Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers

[Stephen Farrell <[e-mail]>]

Hiya,

On 07/07/16 07:24, Werner Koch wrote:
> On Thu,  7 Jul 2016 01:36, [e-mail] said:
>> Hi,
>>
>> Now that we've accepted the draft, I'd like to re-open this proposal to
>> reserve two public-key algorithm protocol numbers.  Note (again) that
> 
> I opened an issue to track this proposal:
>  https://gitlab.com/openpgp-wg/rfc4880bis/issues/1

I forget if this cfrg posting [1] on AE was made visible here
or not. Apologies if this is repetitive but that posting from
Kenny Paterson on 20151113 seems quite relevant as it says:

"
My colleague Simon Blackburn and his collaborators have just
published an attack on the Algebraic Eraser scheme, breaking the
scheme at the designers' claimed 128-bit security level. Their
attack recovers the shared key using 8 CPU hours and 64MB of
memory. Their paper is here:

   http://arxiv.org/abs/1511.03870
"

With no hats, I'd be against adding an algorithm, even as an
option, if there are current serious questions about it's real
security level. I do get the arguments for and against, but in
such cases am against adding codepoints where there is no way
to flag the codepoint as "likely dangerous" or some other
similarly negative/scary warning. And while it's good to go to
the effort to deprecate old codepoints that are now likely
dangerous, I don't see that it's a good idea to add new ones
"born" in that state.

But maybe there's an update on the state of cryptanalysis of
AE? If so, I guess posting to cfrg and then reflecting that
back here might be best, as the cfrg list has folks who're
better qualified to argue those merits. As far as I can see
there was no follow-up to [1] on the cfrg list, but I might
have missed it. There does seem to have been an update to
the paper on arxiv last month, but I didn't check to see what
changed - the abstract still claims the break anyway.

Putting my AD hat back on: if the WG do reach consensus to
add such codepoints, then when it comes time to publish, I'll
be looking back to the list to ensure that consensus was very
clear on the list. For the AE ones, that's clearly happening
via this thread which is fine process-wise, assuming more folks
opine and the chairs declare consensus. I'm just noting that
so we ensure the same clarify if there are other similarly
contentious codepoint requests in order to avoid having to
revisit stuff at publication time.

S.

[1] https://www.ietf.org/mail-archive/web/cfrg/current/msg07609.html

> 
> 
> Salam-Shalom,
> 
>    Werner
>