Re: Comments on DH-GEX draft

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:

>Page 3 says:
>
>     1.   C sends "min || n || max" to S, indicating the minimal accept-
>          able group size, the preferred size of the group and the maxi-
>          mal group size in bits the client will accept.
>
>     2.   S finds a group that best matches the client's request, and
>          sends "p || g" to C.
>
>Would you like a clarification here?
>
>        The group selected MUST be within the bounds preferred by the
>        client; if no such group is available, the server should
>        fail this key exchange, allowing a fallback to a secondary key
>        exchange.

It would help.  The problem is that at the moment the text has:

>     1.   C sends "min || n || max" to S,

and:

>          The recommended
>          values for min and max are 1024 and 8192 respectively.

which is the combination that I interpreted to mean "you can use any key size
you feel like".  In addition on the server side:

>     2.   S finds a group that best matches the client's request,

the "best match" rules given in the text that follows the extract again allow
the server to choose anything it feels like:

>     The server should return the smallest group it knows that is larger
>     than the size the client requested.  If the server does not know a
>     group that is larger than the client request, then it SHOULD return
>     the largest group it knows.

If the clarification is included, the matching text would need to be changed
as well.  As I mentioned in my original message, it looks like there are two
lots of text there, one that applies to { min, n, max } and another that
applies to { n }, which makes it rather confusing.  Well, not necessarily
confusing, but it allows an implementation to do almost anything and still
claim to be compliant.  Perhaps splitting it into two parts, one for when the
client sends { n } and the other when it sends { min, n, max } would
disambiguate it.

(I realise it's too late now, but the real problem is that the client is
 expected to guess at a parameter that only the server knows, with the
 solution being that the server advise the client what to do in advance.  Want
 me to throw together a one-page informational draft documenting the
 "xxx-1024-xxx,xxx-2048-xxx"-style algorithm options?).

Peter.