Subject: [Curdle] Roman Danyliw's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 07:38:56 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-curdle-gss-keyex-sha2-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 5.1, Per “The exchange hash SHOULD be kept secret”, when should it
not be (i.e., why isn’t this a MUST?)?

Editorial Items:
** Section 2.  Provide a reference to X25519 and X448 Curves

** Section 3.  Typo.  s/>RFC2119/RFC2119/

** Section 4.  Editorial.  The sentence “The following new key exchange …” is
indented.

** Section 4 and 5.2.  Per “Each key exchange method id implicitly registered
by this document”, aren’t these key exchange methods explicitly registering
them in IANA-KEX-NAMES per Section 7?

** Section 4.  Explicitly name, number and reference the table in the text

** Section 4.  Typo.  s/refences/references/

** Section 5.  Editorial. s/Additionally we utilize also/Additionally, we also
utilize/

** Section 5.  Editorial.  s/3 classic/three classic/

** Section 5.1.  It is worth repeating (or moving the text) to Section 8 that
the Security Considerations of RFC7546 apply

** Section 5.1.  Typo.  s/trasmitted/transmitted/

** Section 5.1. Typo.  s/estalishment/establishment/

** Section 5.1.  The various variable (e.g., V_C, V_S) are introduced early in
the algorithm to construct H and the messages in page 6, but they aren’t
described until the end of page 7.  I wasn’t following the narrative until I
hit that section.

** Section 5.2.  Explicitly number the table and reference it in the text.

** Section 5.2.  Typo.  s/refences/references/

** Section 6.  This section references a table.  Explicitly name and number
that table.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 25 Jun 2019 18:49:48 +0200

On Monday, 24 June 2019 16:38:56 CEST Roman Danyliw via Datatracker wrote:
> ** Section 5.1, Per “The exchange hash SHOULD be kept secret”, when should
> it not be (i.e., why isn’t this a MUST?)?

this is reiteration of the language from RFC 4253, page 23

given how RSA signatures work, it's impossible to keep it secret in all 
circumstances so it can't be a MUST. That being said I'm not aware of any way 
to attack the handshake if that value is exposed so it looks to be here for 
"abundance of caution" reason...
 
> ** Section 4 and 5.2.  Per “Each key exchange method id implicitly
> registered by this document”, aren’t these key exchange methods explicitly
> registering them in IANA-KEX-NAMES per Section 7?

no, the * is a wildcard character here, we don't explicitly list names that 
will be used
 
> ** Section 5.1.  It is worth repeating (or moving the text) to Section 8
> that the Security Considerations of RFC7546 apply

repeating probably would be better

> ** Section 5.1.  The various variable (e.g., V_C, V_S) are introduced early
> in the algorithm to construct H and the messages in page 6, but they aren’t
> described until the end of page 7.  I wasn’t following the narrative until
> I hit that section.

those come from RFC 4253, a prerequisite to implement this I-D 

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic