[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: which is our DIGEST-MD5 successor?
--On Tuesday, March 18, 2008 05:05:46 PM -0500 Nicolas Williams <Nicolas.Williams@xxxxxxx> wrote: 



On Tue, Mar 18, 2008 at 10:47:37PM +0100, Simon Josefsson wrote:

Jeffrey Hutzelman <jhutz@xxxxxxx> writes:
> I'm seeing an awful lot of "GS2 is going to make the wire encoding more
> complicated!  It's binary; binary is always complicated!" and similar
> FUD. I really wish people would stop spreading that, RIGHT NOW, and go
> actually read (or re-read) the documents in question.

For GS2, I think binary isn't an unreasonable choice, and I agree with
you.  I also think that there is some merit to having textual protocols,
and I think making our DIGEST-MD5 successor textual would be nice.


There's very little binary anything in GS2:

 - two 32-bit unsigned network byte order lengths
 - another 32-bit quantity: maxbuf for security layers
 - a pair of one-byte flags for security layer and channel-binding
   negotiation
 - the actual GSS-API mechanism tokens in the authentication exchanges

Base64-encoding the GSS tokens would allow us to get rid of those two
lengths
It would, but it would be otherwise unnecessary and would lead to a double-base64 in many cases. That's a lot of bloat, not to mention making it more difficult to debug things when the underlying mechanism is text-based like SCRAM. It makes the pure-SASL implementation of SCRAM look like "construct this string of key=value,..., then base-64-encode it. Then (usually) base-64 encode it again." I see developers of non-framework-using applications getting confused, and only applying the encoding once, or to the wrong thing, or....
I agree the flags and maxbuf can be expressed textually. I submit that the lengths also can be, such that one might send 

ctxlen=NNN\n<context token><wrap token>

(note the length of the wrap token is implicit.

-- Jeff