> > Thanks for the draft. As you might guess from earlier discussion
> > on here, I think the more-than-MTI approach espoused is maybe the
> > right one, if we can figure out how to state the requirement well.
> > Have you any ideas on that, or on how we could get towards a
> > situation where that gained consensus?
> Networking standards are promoted by consensus and by network effects. In
> the absence of some forcing function, "fallback to clear text" gets promoted
> by network effects, because it is de facto forced by the sites that don't
> bother deploying the more secure options. The best way to break that is to
> provide "air cover" for security, e.g. a text in the protocol description
> RFC that says "nodes requiring a modicum of security SHOULD refuse to use
> clear text connections." That would effectively turn the tables.
Exactly! The only thing I would add is that "cover" should include a
clear presentation of the tradeoffs and consequences.
Unfortunately this is surprisingly hard to do well. It's much easier to start
throwing MUSTs around.
This also is effectively what happened in the IMAP case: Large sites like gmail
and Apple only deployed imaps, with the result that a fully standards-compliant
client actually won't work with their service!
> Suppose for example that a large enough mail service starts to require TLS
> for SMTP connections. Many sites who are accustomed to send mail in clear
> text will initially protest when their mail gets bounced. But if the
> standard says that yes, they have all right to do that, then the big site
> has "air cover." "I am not breaking you, I am just following best practice."
> At this point, you will see more and more sites opting to turn on TLS, and
> pretty soon the network effects will work in favor of encryption.
This, OTOH, is a little trickier. You first have to distinguish between
SMTP SUBMIT and SMTP relay. I haven't surveyed the former extensively,
but the odds are good it's in roughtly the same situation as IMAP.
The latter is a problem due to the need for every client to work with every
server, as opposed to saying "use a client with these capabilities if you want
to use our service". It's a very different dynamic. Moreover, lots of people
have tried to shift to SSL/TLS in this space and it has not worked well at all.
But this doesn't mean there's no way to make the transition. One possibility is
an SMTP extension to require SSL/TLS on a per-message basis. (A draft has
already been written and is being discussed.) Another one, which I like a lot
better, is to opportunistic SSL/TLS use plus latching. Chris Newman is
working on a draft on that.
And this is actually a case where often-derided "bilateral agreement" idea in
X.400 could go a long way. The distribution of email usage is such that an
agreement to require SSL/TLS between the top-tier MSPs and ISPs would protect a
significant percentage of traffic. And think of the incentive that would
represent to other providers.
> Of course, to be practical, this requires that sites can easily get a
> certificate of some kind, PKI or DANE, to actually use TLS...
Require? Not necessarily - see above. But it would definitely improve the
situation if this stuff were easier to deploy.
Ned
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
