Re: which is our DIGEST-MD5 successor?

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Jeffrey Hutzelman <jhutz@xxxxxxx> writes:

>> While I prefer to avoid two different wire encodings for the same
> function,
>> I consider the deployability of the mechanism to be a much more important
>> concern and the deployment impact of binary in the SASL authentication
>> protocol is significant in my experience.
>
> Let us please be clear.  SASL is not a text-based.  SASL is binary.
> SASL-using application protocols may be text-based, and this often
> requires them to hex- or base64-encode SASL messages.  You are not going
> to be able to look at the bits on the wire and debug a SASL mechanism,
> especially in the text-based protocols that are its major users, without
> some decoding assistance.
>
> For example, IMAP's AUTHENTICATE command exchanges base64-encoded tokens;
> this means that you cannot read SCRAM's semi-human-readable tokens in a
> packet trace.
>
> SMTP's AUTH command behaves the same way.

In fairness, I've done a fair amount of SASL authentication debugging
using only a base64 decoder (e.g., emacs), and every time I have been
grateful that the protocol was textual rather than binary, even though I
had to by-pass the initial base64 obfuscation.

> 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.

/Simon