[NNTP] NNTP Extensions drafts

[Ken Murchison]

Ken Murchison wrote:

> Russ Allbery wrote:
> 
>  > Unless we're specifically using capabilities that were added in the
> 
>> revisions, I'd rather not add the additional complexity to the 
>> publication
>> process of depending on I-Ds.  Ken, were there reasons why we were citing
>> the works in progress rather than the published RFCs in particular, or 
>> was
>> it just an effort to stay current?
> 
> 
> Mainly just to stay current, with the exception of RFC2222bis, which is 
> now going to require the use of the SASLprep profile of StringPrep for 
> authorization ID.  I don't believe that there any updates to the SASL 
> mech docs or TLS docs which have any bearing on our work, so I can 
> fallback to the current RFCs and let the editor update them if possible.

On second thought, RFC 2831bis (DIGEST-MD5) is deprecating the 3DES 
cipher (because of a CBC mode attack) and mandating AES.

We're currently mandating DIGEST-MD5 for interoperability, so I don't 
know how we want to handle this.  One alternative is to mandate CRAM-MD5 
(which is less secure), or TLS+PLAIN (which is what the latest IMAP4 
update does), but I'm guessing we'll get a big pushback from members of 
the WG.

Another alternative is to block this doc while waiting for a new SASL 
mech which resembles PASSDSS.  I've been meaning to write this up for a 
while, but haven't gotten to it yet.  Members of the SASL WG feel that 
such a mech would be a useful thing.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp