--On Monday, July 27, 2009 03:17:20 PM +0200 Chris Newman <Chris.Newman@xxxxxxx> wrote:
Section 10:SASL Mechanisms registry. IANA is requested to prevent future registrations of SASL mechanisms starting with SCRAM- without consulting the SASL mailing list <ietf-sasl@xxxxxxx> first.This at least needs to designate a successor review process if ietf-sasl@xxxxxxx goes away.
I don't think it does. There's plenty of precedent for setting up a mailing list as the reviewer; if the list goes away, the IESG can designate a new reviewer.
I'd also prefer the document enumerate principles for when to allow registration. Personally, I consider undesirable to have the family be large. I'd prefer it contain only SCRAM-SHA-1, and in the future SCRAM-SHA-3 (with the -PLUS variants).
I agree the growth rate should be small, and mostly related to the introduction of successor hashes.
I intend to implement it excluding section 8 and SASLprep. I will attempt to implement channel bindings, but it has gotten fairly complex particularly with all this stuff about different types of channel bindings.
If you ignore the discussions and look at the result, it's not that complex. Assuming CB is being used, the client tells the server what type to use. For now the only type is TLS. If you're a server and see something else, you can reject it out of hand. If you're a client, have a TLS channel, and succesfully negotiate the use of channel bindings according to the spec, you can assume the server will support TLS.
I am unsure how difficult it will be to add channel binding support to NSS. In the event I succeed with channel bindings, but subsequently experience interoperability problems with channel bindings, I will remove all channel binding support from my implementation.
What this tells me is that you don't consider this an important feature. That's unfortunate, because I consider security to be a very important feature, and if implementors won't commit to implementing a security feature, we have no chance of getting operators and users to actually use it.
-- Jeff