Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08

From: "A. Huelsing" <[email-masked]>
Date: Tue, 8 Aug 2017 15:42:09 +0200

Dear Allision,

we were wondering what happens next. Is there any interaction from our side
necessary (or helpful to speed things up)?

Thanks,

Andreas

Am 24-07-17 um 16:39 schrieb Allison Mankin:
> Thanks for making the changes.  Stephen, let me know if you are ready to give
> this a thumbs-up, and I'll start an IRSG poll.
>
> Allison
>
> On 24 July 2017 at 16:30, A. Huelsing <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear Stephen,
>
>     we tried to make the required changes. Please have a look if you are fine
>     with the changes (especially regarding section 5 and the reference
>     implementation).
>
>     You find our answers to your review below and the new draft version attached.
>
>     Thanks again for your time,
>
>     Andreas, Aziz, Denis, Joost & Stefan
>
>
>     ################# Answers ####################
>     possible errors:
>     ----------------
>
>     - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be
>     missing parenthesis around the "(w-1)" to me.  Without those
>     brackets I could interpret that test to always result in false.
>
>     #Done
>
>     - 4.1.9: should the call to setIdx in alg 12 be after treeSig?
>       as-is you seem to have incremented the index too soon so
>     that when alg 11 does getIdx it'd presumably get the
>     incremented index and cause verification failure. I think
>     the same is true of alg 16 as well, in section 4.2.4.
>
>     #Done
>
>     significant comments, but likely fixable:
>     -----------------------------------------
>
>     - section 5: there are waaaay too many options defined here.
>       As-is, this will damage potential deployment of xmss. I
>     would strongly suggest deleting all of the options except the
>     minimum, that being one (and only one) set of parameters for
>     XMSS and one for XMSS^MT. If others are needed later, those
>     can be defined later. (Note that the damage done here includes
>     the hours of developer time that would be wasted debating
>     which of these choices to implement/use. Consider the case of
>     pre-hash variants of eddsa for an ongoing example.)
>
>     ####
>     #   We significantly changed section 5, please check if this
>     #   satisfies your remarks
>     ####
>
>     - section 5 (or an appendix) should contain some test vectors
>       (including intermediate values). Without those, implementers
>     have a much harder time of getting their code right.
>
>     # Added section on reference implementation
>
>
>     nits, near-nits and other ignorable things:
>     -------------------------------------------
>
>     - abstract: I'd suggest s/can withstand attacks/ can withstand
>       so-far known attacks/
>
>     # Done
>
>     - 1.1: You say if used >1 time "no cryptographic security
>       guarantees remain." It might be clearer to give some
>     examples of consequences, e.g. that the attacker can forge new
>     signatures or whatever.
>
>     # Done
>
>     - 1.1: I think you might mention that XMSS and other OTS ideas
>       require some new crypto APIs. I'm not aware if anyone has
>     developed proposals for such, but would be interested if
>     someone has.
>
>     # Done
>
>     - 2.3, 2nd last para: you might want to say what happens with
>       e.g.  B<<2 where B=0xf0. I assume the result is 0xc0 but
>     someone might think it's 0x3c0 or even 0xc3.
>
>     # Done: Removed the left shift as it is never used for single bytes
>
>     - 2.5: having the "type word" as octet 15 of a 32 byte address
>       seems odd. Is there a reason why? (Just wondering.)
>
>     # Yes: We got the space and think that it simlifies implementation if
>     one always has to manipulate whole words (and can treat the address as
>     uint32_t[8])
>
>     - 2.6: It seems odd to given an example where the input and
>       output of base_w() are the same. A different example may be
>     more useful. (More examples generally would be great.)
>
>     # Done
>
>     - 3.1.3: maybe note that "/" means nothing? Which I assume it
>       does? Better might be to just say that.
>
>     # Done
>
>     - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing
>       units
>
>     # Done: value -> Integer value
>
>     - 3.1.5: "the variable" - which one?
>
>     # Done: Added explanation
>
>     - 3.1.5: "For the parameter sets given in Section 5 a 32-bit
>       unsigned integer is sufficient." Sufficient for what?
>
>     # Done: Added " to hold the checksum"
>
>     - 3.1.5: The ascii art at the end of p16 doesn't help much.
>
>     # while the art does not contain new information, we think it's
>     a handy reminder. Would prefer to keep it like this.
>
>     - 3.1.7: The "MUST match" statement doesn't seem enforceable
>       nor testable so I'm not sure it's a good idea to include.
>     OTOH, I do get the idea of using 2119 terms for emphasis.
>
>     # Ok, so what should we do? I agree that key handling cannot be
>     verified. Still, it seems necessary to emphasize this.
>     If it is just about the use of the 2119 term,
>     how about:
>     "but it is crucial for security that the cryptographic strength
>     matches that of the used WOTS+ parameters."?
>
>     - 3.1.7: I think it might be useful to point out any specific
>       problems associated with using a low entropy human memorable
>     secret (password) for the value S. No matter what you say,
>     people will do that, so better if you can say you told them
>     specifically about downsides of doing that.
>
>     # We adressed this in a new sentence at the end of the
>     # paragraph.
>
>     - 4.1.12: I'm not sure if the MAY there is correct or not.  If
>       it means "you MAY use a different algorithm to get the same
>     output as alg 12" then that'd be fine. If something else is
>     meant I'm not sure what you're saying, and it'd probably be
>     better to not even mention it.
>     # That is exactly what it means. There are far more efficient
>     # algorithms to compute that output (but also far more complex)
>
>     - section 5 should also spell out the signature and
>     public key sizes in bytes and ideally, if you keep multiple
>     options, (but please don't:-) describe relative or measured
>     timings.
>
>     # Done
>
>