Re: which is our DIGEST-MD5 successor?

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Tue, Mar 18, 2008 at 11:23:37PM +0100, Simon Josefsson wrote:
> 
> Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
> 
> > 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; the flags and the maxbuf can be expressed textually.
> 
> That is true, and getting rid of the length fields would be neat.  But
> if we are holding GS2, I suspect GS2 will be radically different when/if
> brought back from its zombie state.  I'm not sure it makes sense to
> spend time at this point to re-work the protocol for a technically small
> change like this, when we may be doing larger changes later on.

I'm not done writing up the SCRAM+GS2 ABNF and related text.  After I
post that hopefully Chris and others will agree that it's not overly
complex, or perhaps they'll insist on making the changes I mention
above and then they'll find it agreeable.  That will get GS2 "unheld."