Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4419

[Ballot discuss]
>      Copyright (C) 2000-2003 by Markus Friedl, Niels Provos and William
>      A. Simpson.

Document needs to have proper (ISOC) copyright.

>      The following message numbers have been defined in this document.
>
>        #define SSH_MSG_KEX_DH_GEX_REQUEST_OLD  30
>        #define SSH_MSG_KEX_DH_GEX_REQUEST      34
>        #define SSH_MSG_KEX_DH_GEX_GROUP        31
>        #define SSH_MSG_KEX_DH_GEX_INIT        32
>        #define SSH_MSG_KEX_DH_GEX_REPLY        33

Shouldn't there be an IANA considerations section for this? Indeed,
looking at draft-ietf-secsh-assignednumbers-05.txt, that document
could make it more clear that the 30-40 range is used for key
exchange-specific methods. In that case, the registry for this range
will have multiple values. If IANA is to record that, it would be good
to make those instructions more clear.

[Ballot comment]
- Hyphenation is in conflict with rfc2223bis

- No specification of what SHOULD, MUST NOT and such mean, and no
  reference to RFC2119

- I wonder if Haralds claim "RFC-Editor will remove Copyright" is
  or can be true? I thought we would not accepts stds track documents
  with these sorts of claims

- Missing IPR statement

- The normative references seem pretty out of date.

- I cannot say that it is easy to find where/how this group negotiation
  fits into the whole picture. I think it would be good if some additional
  text for that were included.

[Ballot comment]
- Hyphenation is in conflict with rfc2223bis

- No specification of what SHOULD, MUST NOT and such mean, and no
  reference to RFC2119

- I wonder if Haralds claim "RFC-Editor will remove Copyright" is
  or can be true? I thought we would not accepts stds track documents
  with these sorts of claims

- Missing IPR statement

- The normative references seem pretty out of date.

[Ballot comment]
- Hyphenation is in conflict with rfc2223bis

- No specification of what SHOULD, MUST NOT and such mean, and no
  reference to RFC2119

- I wonder if Haralds claim "RFC-Editor will remove Copyright" is
  or can be true? I thought we would not accepts stds track documents
  with these sorts of claims

- Missing IPR statement

[Ballot comment]
Copyright is nonstandard. I assume this will be deleted by the RFC Editor.
It seems strange to me that so many DH protocols have used fixed primes without there being any good reason for not just picking your own. But I trust the security reviewers that if there was a risk here (apart from the one Steve cites), they'd know about it.

[Ballot discuss]
Some discussion is needed of the risks if the suggested modulus is not prime, or if the putative generator is not a generator.  For example, it's a way for a server to deliberately leak data in a way not detectable by most IDSs.