Re: [lamps] WGLC: draft-ietf-lamps-pkix-shake-02

Quynh and Panos:

I have not heard anyone speak against Jim's suggestion for deterministic ECDSA without a random generator for k.  Let's go that way unless there is a scream from the group now.

Russ

> On Sep 5, 2018, at 1:44 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
> 
> I would have no problems with deterministic ECDSA. But, the adoption was for the original ECDSA. 
> 
> We need advice from the chairs. 
> 
> Regards,
> Quynh. 
> 
> 
> From: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>>
> Sent: Wednesday, September 5, 2018 11:19 AM
> To: Dang, Quynh (Fed)
> Cc: 'Russ Housley'; 'Tim Hollebeek'; 'Panos Kampanakis (pkampana)'; spasm@ietf.org <mailto:spasm@ietf.org>
> Subject: RE: WGLC: draft-ietf-lamps-pkix-shake-02
>  
> Mostly looks fine – one comment below
>  
> From: Dang, Quynh (Fed) <quynh.dang@nist..gov> 
> Sent: Wednesday, September 5, 2018 7:08 AM
> To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>>
> Cc: 'Russ Housley' <housley@vigilsec.com <mailto:housley@vigilsec.com>>; Tim Hollebeek <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com>>; Panos Kampanakis (pkampana) <pkampana@cisco.com <mailto:pkampana@cisco.com>>
> Subject: Re: WGLC: draft-ietf-lamps-pkix-shake-02
>  
> Hi Jim,
>  
> We appreciate your review and comments.
>  
> By the co-chairs' direction, let's try to improve the doc using your comments.
>  
> From: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>>
> Sent: Friday, August 3, 2018 3:40 PM
> To: draft-ietf-lamps-pkix-shake@ietf.org <mailto:draft-ietf-lamps-pkix-shake@ietf.org>
> Subject: WGLC: draft-ietf-lamps-pkix-shake-02
>  
> Not ready for progression.
> 
> * Run the NITS on this document and fix them.  Examples of problems are the
> fact that MUST language section is missing, possible incorrect references,
> and you have lines that are too long.
>  
> Comment 1: correct. Will fix it.
>  
> 
> *  Introduction - I have a problem with the cardinality of items in the
> second and third paragraphs here.  I do not ask that you fix the problems
> that I have but you should be ready to address this is you get the same
> questions from the RFC Editor or the IESG.  I would consider SHAKE to be a
> family of extendable-output hash functions and thus has a cardinality of
> one.  The two specific hash functions have a cardinality of greater than
> one.  The question of cardinality comes in terms of the usage of 'A', 'is',
> 'are'.
>  
> Comment 2: "the SHAKE hash functions " in second paragraph in the intro. should be changed to "the SHAKEs" for a smooth read.  A SHAKE is defined as one function with variable output length. 
> 
> 
> * Introduction - paragraph 2 - I find the last sentence to be difficult to
> read.  The usage of 'and' here seems to be incorrect and it may be difficult
> to figure out which pair comes first - resistance or function.
>  
> Comment 3:
> It would read better if the sentence  "The corresponding collision and preimage resistance security levels for SHAKE128 and SHAKE256 are respectively
>    min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256) bits."  to be replaced with "The corresponding collision and second preimage resistance strengths for SHAKE128 are min(d/2,128) and min(d,128) respectively. And, the corresponding collision and second preimage resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits respectively. "
> 
> 
> * Introduction - paragraph 3 - I am unaware that ECDSA has a mask generating
> function associated with it.  This sentence needs to be cleaned up
>  
>  
> Comment 4: This sentence "
> SHAKEs can be used as the message digest function (to hash the
>    message to be signed) and as the hash function in the mask generating
>    functions in RSASSA-PSS and ECDSA." should be replaced with "
> SHAKEs can be used as the message digest function (to hash the
>    message to be signed) in RSASSA-PSS and ECDSA and as the hash function in the mask generating functions in RSASSA-PSS."
> 
> 
> * Introduction - paragraph 3 - Consider putting in a reference to the
> algorithm identifiers that are not changing.  Probably overkill but still
> useful
>  
> Comment 5: Adding " see section 3 below" at the end of this sentence: "In this document, we define four new OIDs for RSASSA-PSS and ECDSA when SHAKE128 and SHAKE256 are used as hash functions.".
>  
> 
> * Identifiers - This section needs to nail down all parameters associated w/
> the different SHAKE functions when used here.  Otherwise you end up with the
> first assumption that I made which was d = 128 for SHAKE128 which would not
> produce an acceptable result.
>  
> Comment 6: The specification of output lengths of the 2 SHAKEs is in Sections 4.1..1 and 4.1.2.  Adding a sentence " See Sections 4.1.1 and 4.1.2 for specification of a required output length for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA."
>  
> 
> 
> * Signatures - Para #3 - you refer to section 3 for OIDs, but they are not
> there for public keys.
>  
> Comment 7: Adding this "
> Conforming CA implementations MUST specify the algorithms explicitly
>    by using the OIDs specified in Section 3 when encoding  public keys for RSASSA-PSS and ECDSA with SHAKE signatures in certificates and CRLs." as the first paragraph in Section 4.2 "Public keys". 
> 
> 
> * IANA Considerations is incorrect and MUST be updated
>  
>  
> Comment 8: IANA Considerations is incorrect and will be updated.
>  
> 
> * Why is there no reference to deterministic ECDSA signatures in the
> document.
>  
> Comment 9: Deterministic ECDSA has a different signing function because of the way k is generated. The working group has not adopted this option yet. Verification is the same. 
>  
> [JLS] If you want to say that it is a different signature algorithm that is fine.  I’ll call and raise.  It should be that it is required that ECDSA w/ SHAKE implements deterministic ECDSA and MUST NOT use a random generator for k.
> 
> 
> * The ASN.1 module is absent and needs to be instantiated.  Even doing so
> with TBD is sufficient for now.
>  
> Comment 10: Yes. 
> The ASN.1 module is absent and needs to be instantiated. 
>  
> 
> Are you ok with the proposed resolutions ?
>  
> Regards,
> Quynh. 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org <mailto:Spasm@ietf.org>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>