Chris, Thanks for the input. I'd been hoping for a while that you'd comment the NNTP SASL/STARTTLS stuff, especially reasons why your DSS draft died on the vine. I'm going to forward your response to the nntpext mailing list in the hope that it might help steer the discussion a little bit. All of the discussion about reneg and/or DSS on the list has been in an effort to appease those that have a fear of TLS/PLAIN crushing servers, so we can try to move the STARTTLS and AUTHINFO SASL drafts along at something quicker than glacial speeds (something that you're all too familiar with I'm sure).
Ken Chris Newman wrote: > > FWIW, my opinion is this is likely another case of computer engineers > trying to optimize something that doesn't need to be optimized (a sin I > have been guilty of many times). > > And I'm saying that as someone who went to the trouble of writing a spec > and implementing a prototype SASL mechanism for this purpose (plaintext > password encrypted only during the authentication phase). I now think that > work was largely a waste of time (although I had fun doing it and learned a > lot). > > The cost of symmetric ciphers is small to negligable on modern hardware, > particularly a wimpy cipher like RC4 which is the most common in SSL/TLS. > > Rather than making TLS implementations more complicated (and less secure) > to support mid-stream down-negotiation, or introducing another SASL > mechanism to do this, why not just optimize the RC4 code? That will > benefit _all_ protocols using TLS and reduce the complexity of the Internet > suite of protocols. > > Encrypting data that doesn't need to be encrypted is good for overall > security of the system. > > - Chris -- 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
