Subject: Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-cose-hash-sig-05

From: Alissa Cooper <[email-masked]>
Date: Wed, 4 Dec 2019 11:17:35 -0500

Elwyn, thanks for your review. I entered a No Objection ballot and requested a response to your review.

Alissa

> On Oct 28, 2019, at 7:30 PM, Elwyn Davies via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Elwyn Davies
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-cose-hash-sig-05
> Reviewer: Elwyn Davies
> Review Date: 2019-10-28
> IETF LC End Date: 2019-10-29
> IESG Telechat date: Not scheduled for a telechat
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <" dir="auto">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> 
> Document: draft-ietf-cose-hash-sig-05
> Reviewer: Elwyn Davies
> Review Date: 2019/10/28
> IETF LC End Date: 2019/10/29
> IESG Telechat date: (if known) N/A
> 
> Summary:
> Almost ready,  There is one minor issue (barely above editorial) and a number
> of nits.  I haven't checked the details of the HSS/LMS summary derived from RFC
> 8554 and I am taking the contents of the Appendix on trust!
> 
> Major issues:
> None
> 
> Minor issues:
> s1.1, last para:  I found the note which provides particular motivation for
> this proposal rather obscure on first reading.  After thinking about it, I now
> understand why this is here, but another sentence or so reinforcing the idea
> that getting the software distribution system post-quantum secure at the
> earlest opportunity is key to avoiding melt down should quantum computing
> develop more quickly than we might expect.   Also referring to the SUIT WG is
> not future proof.
> 
> Nits/editorial comments:
> s1, HASHSIG reference anchor:  I would be inclined to stick with the 'standard'
> anchor for RFC 8554 i.e. [RFC8554].
> 
> s1, para 2: Expand DSA, ECDSA and EdDSA on first use ( RSA is claimed to be
> well-known).  Arguably references for the various mechanisms might be desirable.
> 
> s2, last para: s/The the/The/
> 
> s2 and subsections:  The terminology and symbology used (e.g, || for
> concatenation) are (I believe) those defined in RFC 8554. This should be
> mentioned.
> 
> s2.2, para 1:  'This specification supports only SHA-256':  I think this is a
> cut-and-paste from RFC 8554.   Suggest: s/This specification supports/[RFC8554]
> initially only supports/ and add at the end 'This specification would
> automatically support any such additional hash functions.'
> 
> s4/s4.1: Rather than leaving an empty s4 and having a single subsection
> (generally frowned upon), the phraseology used at the start of s17 of RFC 8152
> would be an improvement.
> 
> s4: The security considerations of RFCs 8152 and 8554 are also relevant to
> implementations of this specification.
> 
> s6: References to the relevant IANA registries for 'COSE Algrithms' and 'COSE
> Key Types' should be added.
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Dec 2019 15:01:42 -0500

Elwyn:

Thanks for the review.  I missed the review when you posted it, but I saw Alissa's recent reply to it.

> develop more quickly than we might expect.   Also referring to the SUIT WG is

I hope this resolved your concern:

   Since the HSS/LMS signature algorithm does not depend on the
   difficulty of discrete logarithm or factoring, the HSS/LMS signature
   algorithm is considered to be post-quantum secure.  The use of HSS/
   LMS hash-based signatures to protect software update distribution
   will allow the deployment of future software that implements new
   cryptosystems.  By deploying HSS/LMS today, authentication and
   integrity protection of the future software can be provided, even if
   advances break current digital signature mechanisms.

> anchor for RFC 8554 i.e. [RFC8554].

I guess this is taste.  I find [HASHSIG] easier to read in many of the places where RFC 8554 is referenced.

> well-known).  Arguably references for the various mechanisms might be desirable.

All of these are well known digital signature algorithms.  They only appear as part of the motivation section; however, I will add references.

> s2, last para: s/The the/The/

Good catch.  Thanks for the careful read.  Corrected.

> concatenation) are (I believe) those defined in RFC 8554. This should be

At the first use, I added:

   where, the notation comes from [HASHSIG].

> automatically support any such additional hash functions.'

I suggest:

   The [HASHSIG] specification supports only SHA-256,
   with m=32.  An IANA registry is defined so that other hash functions
   could be used in the future.

> (generally frowned upon), the phraseology used at the start of s17 of RFC 8152

Agreed.  That is an improvement.

> implementations of this specification.

Agreed.  I added a paragraph.

> Key Types' should be added.

Agreed.  I added a reference to the IANA Registry page.

Russ