Following up on my own point - not stylish but I think in this case justified:-)
On 10/15/2013 12:41 AM, Stephen Farrell wrote: > I don't > see why we shouldn't be equally comfortable in saying "don't > send cleartext" - *if* that's an IETF consensus position - as > we have seen sending cleartext is also just broken when one > consideres pervasive monitoring. I guess this Washington Post story [1] that I saw this morning would appear to provide a relevant example. In that case, I would argue that the fact that cleartext IMAP provides interop and is successful does imply that some services somewhere will use that for large populations that will inevitably (as we now know) be subject to pervasive monitoring. When the numbers involved ("500,000 buddylists and inboxes" collected on a "representative day" for just one agency) are at that scale, then it seems to me that one can fairly describe that as a failure in protocol design and not solely as a bad deployment choice. With the 20-20 hindsight afforded, if IMAP were a new protocol, would we be correct to only have TLS as MTI as we currently do [2] or would the Internet be better if we *only* had port 993 and had TLS as MTU perhaps with anon DH or something (*) like that? The latter approach is certainly now far more likely to be tractable than it was in 2003 (when RFC3501 was done). Maybe its time we do that. Cheers, S. (*) Yes, there's a bit of arm-waving there since one can validly argue that the TLS ciphersuite that's MTI for 3501 is still just a bit too hard to deploy as one is supposed to get a server cert that the UA can verify, which implies some management overhead. So something slightly more easily deployed (and hence not quite 3501) might really be needed. But *how* to do MTU stuff could be a protocol-specific debate to have after we concluded we had consensus for more-than-MTI in some form. (Which we don't, today.) But of course, a new IMAP security BCP doesn't have to wait either (hint, hint:-) [1] http://www.washingtonpost.com/world/national-security/nsa-collects-millions-of-e-mail-address-books-globally/2013/10/14/8e58b5be-34f9-11e3-80c6-7e6dd8d22d8f_story.html [2] https://tools.ietf.org/html/rfc3501#section-11 _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass