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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jun 2016 11:53:17 +0100

On 16/03/2016 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.
With apologies from chairs, we haven't officially closed the RGLC.

Can people who raised comments confirm that their comments were 
responded to and/or addressed? We would like to get confirmation that 
this is ready for publication.

Thank you,
Kenny and Alexey

---

From: Gilles Van Assche <[email-masked]>
Date: Tue, 28 Jun 2016 15:25:26 +0200

Hi Andreas,

Thanks for adding the SHA-3 parameters to the XMSS draft.

Based on the cryptanalysis results we have seen so far, SHA-3 has a
thicker safety margin than SHA-2, so it may be an interesting option to
choose in a protocol that aims for long-term security.

Kind regards,
Gilles

On 21/03/16 11:41, A. Huelsing wrote:
> Our reasoning behind choosing SHA2 for the first parameter sets was
> based on the availability of implementations in the field. However,
> this selection is not exclusive! We even describe in the document what
> has to be done to define parameter sets based on other hash functions
> / block ciphers.
>
> I think it is a question for cfrg if we want to include parameters
> based on different hash functions in this state. I guess we can easily
> include SHA3 parameters as optional if someone provides us with a
> section describing how the different function families are
> instantiated using SHA3.
>
> Andreas
>
> […]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jun 2016 15:56:10 +0100

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:
> Best Regards,
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 28 Jun 2016 08:02:36 -0700

> intends to publish updated guidance on this topic."

We actually have significantly more confidence in XMSS security then any
other signature scheme. Signatures imply one way functions which are all
XMSS needs. There is a catch with backups I don't like, but there are
workarrounds.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jun 2016 16:08:05 +0100

> XMSS needs. There is a catch with backups I don't like, but there are

That was not my only concern and nor was my concern specific to
this scheme.

But sure, if someone wants to make a claim that this scheme is
one on which large chunks of the Internet could today safely
depend, and if that's a CFRG consensus position then saying that
would be fine.

Personally, I'd be in rough in that case, if for no other reason
that the relatively immaturity of implementations.

S.