Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

Kurt Zeilenga wrote:
 
> The group has determined that DIGEST-MD5 (RFC2831) is not suitable  
> for progression on the Standards Track due to interoperability, 
> internationalization, and security concerns.

Interperability and deployment might be a problem.  The intended
compatibility with RFC 2617 has a problem with an 2617 erratum.
Apparently nobody wants more than authentication, and then a
design offering confidentiality is overkill.

What I18N concerns ?  SASLPREP bound to Unicode 3.2 isn't very
attractive when IDNAbis wants to use whatever Unicode offers,
but that is a 2831bis concern.

The only security concern I've heard of is the lack of channel
bindings, did I miss something important ?   

> The replacement mechanism is expected to be "better than"
> DIGEST-MD5 from a number of perspectives including 
> interoperability, internationalization, and security.

Better than DIGEST-MD5 wrt to interoperability is no challenge,
better than CRAM-MD5 while not being more complex could be more
interesting for deployment.  

> Use of well understood and broadly-implemented algorithms (e.g.,  
> HMAC, SHA1),

Not everybody likes SHA1, and those who like SHA1 are supposed to
like SHA2 better.  

> Algorithm agility

That's a SASL feature, one side offers what it can do, the other
side picks what it supports and considers as best.  ITYM hash
agility, the mechanism must allow to be cloned for another hash.
No additional negotiation "within" the new mechanism.

> Negotiated key hardening iteration count,

When H(x) is not "hard enough", then H(H(x)) shuffling the bits 
again using the same H is not necessarily "harder".  It might
be interesting to look at H(x||count) or RMX if the PBKDF2 idea
turns out to only burn cycles, instead of being really "harder".

> Downgrade attack protection,

I'm not sure what you have in mind.  When one side offers SASL
mechanisms A, B, and C, the other side can only pick, or say 
"not good enough" - especially if it knows that there used to
be a better D when not talking to an attacker.

> Channel Binding,

Unfortunately I'm not sure what this means.  Is this about
A <- TLS -> M <- TLS -> B, when A and B happily use SASL PLAIN
and don't know that they really talk "via" an attacker M ?  Do
channel bindings imply to use TLS ?
 
> Additionally, the WG will deliver a document summarizing its 
> DIGEST-MD5 concerns and requesting RFC 2831 be moved to  
> Historic status.

What will the WG do with standards having a normative reference
to RFC 2831 ?  I've heard that the XMPP folks try to get rid of
DIGEST-MD5, so that's hopefully soon out of the way.

 Frank