Subject: Re: Comments on DH-GEX draft

From: [email-masked] (Peter Gutmann)
Date: Tue, 18 Nov 2003 16:23:44 +1300

Bill Sommerfeld <[email-masked]> 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.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 18 Nov 2003 14:44:39 -0500

>  "xxx-1024-xxx,xxx-2048-xxx"-style algorithm options?).

What sort of client-side policy do you have in mind other than "pick a
group at least as large as X and less than Y"?

						- Bill

---

From: Niels Provos <[email-masked]>
Date: Tue, 18 Nov 2003 15:05:57 -0500

> group at least as large as X and less than Y"?

It seems that the issue might be the common misconception of an
untrusted server.  In the case of SSH, the server is fully trusted by
the client.

Niels.