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

From: Jim Schaad <[email-masked]>
Date: Wed, 5 Sep 2018 08:19:56 -0700

Mostly looks fine - one comment below

From: Dang, Quynh (Fed) <[email-masked]> 
Sent: Wednesday, September 5, 2018 7:08 AM
To: Jim Schaad <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; Tim Hollebeek
<[email-masked]>; Panos Kampanakis (pkampana)
<[email-masked]>
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 <[email-masked] <mailto:[email-masked]> >
Sent: Friday, August 3, 2018 3:40 PM
To: [email-masked]
<mailto:[email-masked]> 
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.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 5 Sep 2018 17:44:08 +0000

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 <[email-masked]>
Sent: Wednesday, September 5, 2018 11:19 AM
To: Dang, Quynh (Fed)
Cc: 'Russ Housley'; 'Tim Hollebeek'; 'Panos Kampanakis (pkampana)'; [email-masked]
Subject: RE: WGLC: draft-ietf-lamps-pkix-shake-02

Mostly looks fine – one comment below

Cc: 'Russ Housley' <[email-masked]>; Tim Hollebeek <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>

Hi Jim,

By the co-chairs' direction, let's try to improve the doc using your comments.

________________________________

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 3, 2018 3:40 PM
To: [email-masked]<mailto:[email-masked]>
Subject: WGLC: draft-ietf-lamps-pkix-shake-02

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.

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. "

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."

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.".

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."

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".

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.

Comment 10: Yes.

Regards,

Quynh.

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Sep 2018 05:40:52 -0400

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) <[email-masked]> wrote:
> 
> From: Jim Schaad <[email-masked] <mailto:[email-masked]>>
> Cc: 'Russ Housley'; 'Tim Hollebeek'; 'Panos Kampanakis (pkampana)'; [email-masked] <mailto:[email-masked]>
> From: Dang, Quynh (Fed) <quynh.dang@nist..gov> 
> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>
> Cc: 'Russ Housley' <[email-masked] <mailto:[email-masked]>>; Tim Hollebeek <[email-masked] <mailto:[email-masked]>>; Panos Kampanakis (pkampana) <[email-masked] <mailto:[email-masked]>>
> From: Jim Schaad <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> 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."
>  
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 26 Sep 2018 16:58:59 +0000

Hi Jim,
Thank you for the thorough review.
All your comments (other than the ASN.1 which we deferred for later) were addressed and they are in https://github.com/csosto-pk/adding-shake-to-pkix/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+draft-ietf-lamps-pkix-shake-02
The latest, current version of the draft is in https://github.com/csosto-pk/adding-shake-to-pkix/blob/master/draft-ietf-lamps-pkix-shake-current.txt
Rgs,
Panos

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, September 05, 2018 11:20 AM
To: 'Dang, Quynh (Fed)' <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'Tim Hollebeek' <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: WGLC: draft-ietf-lamps-pkix-shake-02

From: Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 5, 2018 7:08 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: 'Russ Housley' <[email-masked]<mailto:[email-masked]>>; Tim Hollebeek <[email-masked]<mailto:[email-masked]>>; Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC: draft-ietf-lamps-pkix-shake-02

Hi Jim,

Comment 3:

Comment 7: Adding this "

[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.

Comment 10: Yes.

Regards,
Quynh.