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

[Hubert Kario <[e-mail]>]

On Monday, 24 June 2019 16:38:56 CEST Roman Danyliw via Datatracker wrote:
> 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?)?

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