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

[Allison Mankin <[e-mail]>]

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 <[e-mail]> 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
>
>