Re: IETF mail server and SSLv3

[John C Klensin <[e-mail]>]

--On Thursday, February 04, 2016 19:00 -0800
[e-mail] wrote:

>> > On Feb 4, 2016, at 11:22 AM, John C Klensin
>> > <[e-mail]> wrote:
>> > 
>> >> I am quite comfortable at this time with a requirement of
>> >> better than SSLv3 for SMTP on the public Internet.
>> > 
>> > Unless there is a fallback to clear text, I am not.
> 
>> Yes, of course with cleartext transmission in the absence of
>> STARTTLS support.  I had expected that would have been clear
>> from context.
> 
> That's in no way sufficient. Not only do you have to be
> willing to do without STARTTLS, you also have to be willing to
> close the connection and try another in the event that the
> server offers STARTTLS, the client attempts to use it but the
> TLS negotiation fails for some reason.
> 
> I suspect this is the "fallback" John was talking about.

I hadn't thought through all of the details but more or less
yes.  

> Not all SMTP clients offer this capability, and without it you
> can get into stuck message situations.
> 
>> The point being that systems that are STARTTLS-capable are at
>> this point essentially without exception capable of TLSv1 or
>> better.
> 
> Maybe. But even if this is true, there are other ways for TLS
> negotiation to fail. (The one that has been the biggest
> nuisance historically is where TLS is enabled on the server
> but no certificate is installed, causing all attempts to use
> TLS to fail unconditionally.)

In addition, the IETF often fails to understand how slowly
change occurs, especially when the changes are expected to
replace existing practices that seem to work.  We've still got
messaging systems around that haven't fully gotten MIME and that
therefore still using "message and attachments" models.
Similarly, 18 or 19 years ago, our big focus was on
authentication rather than privacy and the IETF was on an
anti-password tear, so we developed CRAM-MD5, not just as a
serious proposal but a hack to show that, with the technology of
the time, it was possible to move beyond passwords without
requiring heavy-duty authentication servers.  It has been a long
time, but I think we were also concerned about restrictions on
encryption and encryption export (a set of problems that were
not solved the IAB/IESG statement in RFC 1984 a few years
earlier).    Despite our understanding of the difficulties with
CRAM-MD5 (most obviously, its reliance on MD5 itself), I still
see it used and used with SMTP AUTH as well as with POP and
IMAP.  Why?  Well, maybe to avoid encryption, but I'd guess more
likely just out of habit and legacy behavior.

RFC 1918 is, itself, another example.  It is a good policy
statement which most of us supported and considered valuable
then and still do.   But it is  not a magic wand that brought
about immediate and lasting changes -- many of the debates and
policy proposals it refers to are still very much with us; some
seem to be experiencing a resurgence after appearing to have
gone away.    

Ultimately, some actors are going to follow our advice and some
aren't and, especially when we promote a "stop doing this or
using that" measure, we need to decide what sort of Internet we
want: one that is as open or inclusive as possible or one that
isn't nearly as open to those who don't follow our rules and
preferences.  While I appreciate Victor's follow-up
clarification, that tradeoff applies whether we are talking
about, e.g., "crypto or the mail doesn't go through" or "no
transit privacy unless you use a preferred version of TLS".   

FWIW, I think what Ned, I, and many others have heard from users
over the years is that they prefer that messages get through
and, most of the time, behave as if that is far more important
than marginal privacy or security.  I wish that preference were
a little different, but my (and other) efforts to educate the
public about why they should care more --at least to the extent
of making sure they can use whatever privacy and authentication
mechanism that are available and that they judge to be effective
for their needs have, so far, not been very successful.

       john