Re: [Cfrg] RGLC on draft-irtf-cfrg-xmss-hash-based-signatures-03.txt

[Stephen Farrell <[e-mail]>]

Hiya,

I had a quick read of the draft. I've no comments on the
algorithm itself, but do have a strong reservation about
the text.

I would be much happier if it included some CFRG-consensus
text as to the current desirability of implementing and
deploying and depending upon any scheme that aims/claims to
be post-quantum secure (or any similar phraseology).

While a quantum computer is definitely a threat about which
we ought worry, we must also worry about people implementing
the shiny new thing badly. And about a shiny new thing that
turns out less good than expected. Or if implementing the shiny
new thing acts as a distraction to the deployment of currently
good but non quantum-resistant security or privacy mechanisms.
There may also, over time, be many shiny new things, that are
not all equal, but so that implementers lack guidance as to
which to choose. I consider all of the above are real threats
and that CFRG ought provide guidance as to how the trade-offs
between those are currently seen.

So I would really like to see a paragraph or two that is aimed
at implementers and that gives current guidance on whether or
not this is ready for prime-time. I would hope the same paragraph
could be re-used in any similar drafts.

My starting point would be to insert something like the text
below at a prominent place in the introduction:

"All quantum-resistant algorithms documented by CFRG are today
considered ready for experimentation and further engineering
development (e.g. to establish the impact of performance and sizes
on IETF protocols) but CFRG has consensus that we are not yet
sufficiently confident to the point where we would want the security
or privacy of a significant part of the Internet to be dependent on
any set of those algorithms. In future, as things mature, CFRG
intends to publish updated guidance on this topic."

If CFRG's consensus is for something much more positive than the
above, so long as that guidance is clearly justified and clearly
safe for implementers then I'll be fine with that. IOW my conservative
text above might be too conservative, but ISTM that this is a case
where do-no-harm is a good principle to follow at first.

Note: This is independent of this (or any) specific algorithm
so I hope the authors/proponents don't take this as a comment
on their algorithm. (And yes, this is sort of related text in
section 8.3, but that is IMO insufficient.)

S.

PS: The above is my comment as an individual (barely qualified:-)
participant in CFRG. As one of the current security ADs, I would
however also have to consider if the lack of some such guidance
would be something for the IESG to consider during rfc5742 conflict
review. I'm not sure if the concern above would or would not be a
valid 5742 conflict but absent some such guidance I think I'd have
to raise the issue then, so be no harm if we can resolve it now.
Apologies if I missed one before, but I think this is the first
such document to reach this stage, so now's a good time to sort
this.

PPS: That the organisation perhaps most likely to develop a QC
is also one that could potentially benefit from quantum-resistance
as a distraction, or that might have better QC based attacks, and
that that organisation is pushing us towards this kind of work, and
is also an organisation that reportedly has a gigantic (and IMO
gigantically stupid) budget for making Internet security worse...
remains a highly relevant consideration for me here. But I don't
think that that is needed to justify asking for consensus guidance
on when to depend on this stuff.



On 16/03/16 19:45, Alexey Melnikov wrote:
> This message starts 4 weeks RGLC on
> draft-irtf-cfrg-xmss-hash-based-signatures-03.txt (XMSS: Extended
> Hash-Based Signatures) which will end on April 13th. Please let chairs
> know if you think the document is ready for IRSG review (and publication
> as an RFC) or if you find any issues with it.
> 
> Best Regards,
> Kenny and Alexey
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>