> 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.
It absolutely did fail, but because we screwed up and specified the wrong
thing. It absolutely escapes me how you can believe that putting a stronger
mandate for the wrong thing would have helped. The far more likely
result would have been more confusion and a overall poorer outcome.
What happened instead was both implementors and deployers of the technology did
the right thing IN SPITE OF OUR HAVING SCREWED UP. A "let's give implementors
and deployers even less leeway in the name of better security" change hardly
seems to be justified by these events.
> 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.)
OK, if I understand you correctly, you're saying that had we demanded more back
then, we would have done a better job. Since I was there at the time and
remember the arguments and decisions quite well, it's easy to demonstate that
this conjecture does not stand up to any sort of analysis.
I first note that the main reason SSL/TLS was on the table was to protect
passwords, not to protect entire mail sessions. The latter was a "nice to
have", not a "must have".
Nevertheless, the concern over password protection was serious. But there was
also serious concern that whatever was specified would be both implementable
and deployable. That concern was focused on clients - it was felt that the
number of combinations and permutations clients had to deal with needed to be
kept to an absolute minimum or client implementors wouldn't support any of it.
(This concern seems ridiculous now in light of the large number of IMAP
extensions that have specified since then and the resulting combinatoric
explosion that clients have to deal with.)
On the server side, there was little if any concern expressed over
deployability at large scale. There was some concern expressed over export
restrictions. (Remember that this was happening in 1999-2002 and all this stuff
was in a state of flux.)
And then there was the feedback we were getting from the security area. We
were being told:
(1) Having any sort of clear text mechanism was bad, because there was
tremendous skepticism that SSL/TLS would actually be deployed to
protect password exchanges.
(2) Two port solutions are bad. If you're going to use SSL/TLS, it needed to
be negotiated inband.
(3) GSSAPI/Kerberos was the path of truth and righteousness for password
protection. There was reluctant acceptance that DIGEST-MD5 could be
used, but not CRAM-MD5.
As a result of all these competing interests, what got specified was that
password needed to be protected and therefore it was mandatory to implement
either STARTTLS/PLAIN, DIGEST-MD5, or GSSAPI. Which was hardly a recipe for
interoperability. Rather, it was a reflection of the fact that we just didn't
know what the right solution was.
And at that point we got really, really lucky: Four separate IETF screwups
conspired to make the right thing happen: (1) DIGEST-MD5 was a total faiure,
(2) GSSAPI was seen as undeployable, (3) The negotiated one port solution for
SSL/TLS was undeployable, and (4) Our assessment of what implementors would be
willing and able to do was wildly incorrect.
Given this backdrop, I don't think a claim that demaning more security would
have led us to the correct two port SSL/TLS solution is remotely credible. Had
that happened it is *far* more likely we would have mandated DIGEST-MD5
support. But even if we'd moved in the SSL/TLS direction it would have
been a one port approach.
Of course if we were doing this now we wouldn't make the same mistakes. What
we'll do intead is make a great big bunch of new ones. Indeed, that is already
happening: See Paul Hoffman's recent message about how attempts to increase
SSL/TLS security is conspiring to lower its use in the field.
Ned
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
