Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08
"A. Huelsing" <ietf@huelsing.net> Tue, 08 August 2017 13:42 UTC
Return-Path: <ietf@huelsing.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA2132457; Tue, 8 Aug 2017 06:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yycR2jzTviAH; Tue, 8 Aug 2017 06:42:16 -0700 (PDT)
Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C036132390; Tue, 8 Aug 2017 06:42:15 -0700 (PDT)
Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from <ietf@huelsing.net>) id 1df4lu-0007VU-5J; Tue, 08 Aug 2017 15:42:10 +0200
Received: from [131.155.70.110] by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <ietf@huelsing.net>) id 1df4lt-0005Ot-L1; Tue, 08 Aug 2017 15:42:09 +0200
To: Allison Mankin <allison.mankin@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Alexey Melnikov <alexey.melnikov@isode.com>, "irsg@irtf.org" <irsg@irtf.org>, "cfrg@irtf.org" <Cfrg@irtf.org>, "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" <draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org>
References: <D4FDAF9D.8D586%kenny.paterson@rhul.ac.uk> <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <D566ADE0.963E4%kenny.paterson@rhul.ac.uk> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <D56DBB2C.96A67%kenny.paterson@rhul.ac.uk> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net> <CAP8yD=sTXB7trXyjz+VGHOAvh9egiSHmBcukNVN1yiq0mwkfFw@mail.gmail.com>
From: "A. Huelsing" <ietf@huelsing.net>
Message-ID: <367c689b-1463-f39d-6541-24a68aa2227a@huelsing.net>
Date: Tue, 08 Aug 2017 15:42:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAP8yD=sTXB7trXyjz+VGHOAvh9egiSHmBcukNVN1yiq0mwkfFw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------8FC302CF60327746429A8B5D"
Content-Language: en-GB
X-Authenticated-Sender: ietf@huelsing.net
X-Virus-Scanned: Clear (ClamAV 0.99.2/23645/Tue Aug 8 14:27:48 2017)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0I2mncnmbIMXIIXGHWG8e_O600g>
Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 13:42:19 -0000
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 <ietf@huelsing.net > <mailto:ietf@huelsing.net>> 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 > >
- [Cfrg] IRSG review of draft-irtf-cfrg-xmss-hash-b… Paterson, Kenny
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Paterson, Kenny
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Watson Ladd
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Allison Mankin
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Paul Hoffman
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Paul Hoffman
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Allison Mankin
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing