Hiya, On 10/23/2013 07:30 PM, [email protected] wrote: > > Keeping in mind that this is hardly a comprehensive list of the world's > ISPs,
Quite useful though. Thanks. > I'll first note that the ciphersuite situation is better than I expected. Ditto. > A > minority of services, albeit some of the biggest ones, prefer RC4. And > nobody > insisted on it. Quite a few even go so far as to prefer a DHE variant. > But more > of them need to support and prefer something in the DHE/AES set. This is > a place > where some clear guidance would probably be helpful, as long as it involves > using ciphersuites for which support is readily available. (The obvious > starting > point is for servers to always prefer AES to RC4 and always prefer DHE > variants > to non-DHE variants. I'll the ranking of those two to those more > pedantic than > I.) Any voluneteers? Might be close enough to fit in the smtp/tls draft Alexey said he'd look at. > > Only three of the services tested, one in North America and the others in > Europe, offered no SSL/TLS at all. That strikes me as pretty good coverage > overall, and perhaps the Snoden revelations will make something good > happen to > those, as it is doing at Yahoo. > > But these results, while encouraging, don't say anything good about the > IETF's > ability to mandate security. The IETF recommended best operational practice > (effectively a SHOULD in RFC 3501) is to only offer port 143 and require > STARTTLS on that port, as indicated by the LOGINDISABLED capability. Not a > single provider I tested implemented that specific variant. Not. One. Yep. I agree that's a problem. Seems we disagree about the conclusion to be drawn though. For me, the above indicates that our current "make 'em specify a MTI (in the RFC6919 sense)" failed in this case. I conjecture that had there been a more-than-MTI practice in place way back then, its a good bit more likely we'd not have screwed up on the TLS stuff. And so I figure its worth investigating that some more. (Not for IMAP, but in general for current/future work.) S. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
