On Thu, Feb 19, 2015 at 09:35:50AM -0500, Richard Barnes wrote:

> > > Part of the source of my confusion here is that from the pure perspective
> > > of TLS, the server is *always* authenticated (and the client,
> >
> > Factually incorrect. Anon-DH has been present in TLS since the
> > beginning. If your DISCUSS is based on that misapprehension then
> > you need to re-consider.
> 
> Well, that brings up another thing that this document should deprecate.  ;)
> 
> As RFC 5246 points out:
> """
>    Note that using non-anonymous key exchange without actually verifying
>    the key exchange is essentially equivalent to anonymous key exchange,
>    and the same precautions apply.
> """

    * Some servers may prefer to know which clients have chosen to
      not authenticate them, and may offer such clients reduced
      service or simply have a better audit trail of client policy.
      This is explained in:

	https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-8.2

      This is, for example, how I know that though ietf.org's email
      server has TLSA records and can be authenticated by DANE-capable
      SMTP clients, it is not yet itself a DANE-capable MTA, and
      does not authenticate my SMTP server's certificate (it uses
      anon-DH when connecting to my domain).  [ I might reach out
      to the AMSL email admins and see whether they're yet in a
      position to upgrade to Postfix 2.11.x and also enable outbound
      DANE verification. This was not yet an option at the time
      they first published TLSA RRs a year or so back. ]

    * A client that knows that it will not in fact check the server
      certificate, can inform the server of this fact by announcing
      support for anon-DH ciphersuites in addition to support for
      various types of certificates that it will ignore.

    * Such a client interoperates with servers that field no
      certificates, as well as with servers that field certificates.

    * Some clients will support only anon-DH, but will be secure
      because they use channel-binding (e.g., with GSSAPI) to secure
      the connection, and any negotiation of certificates is then
      just wasted bits on the wire and wasted processing.

> The basis of my DISCUSS is I haven't heard anyone say what they would want
> to change about this document to make it suitable for an "unauthenticated"
> environment.  Regardless of whether there's consensus for changes, if
> nobody's asking for changes, we shouldn't preemptively open the door.

In an opportunistic context, (TLS) encryption is used simply because
it appears to be possible.  Cleartext transmission is permitted
and used otherwise, and no more security than that is expected.
If TLS happens to be possible, hooray, maybe you get more than you
expected.  So the peers communicate by any means available, but
try to be as secure as circumstances allow.

In this context, any crypto that is not demonstrably as weak as
cleartext, and is still the best that some non-negligible fraction
of peers are capable of (e.g. some Exchange 2003 SMTP servers that
do at best TLS_RSA_WITH_RC4_128_SHA) is acceptable crypto.  If the
TLS stack refuses to support that, then communication happens in
the clear.  The identity function (cleartext) offers less
confidentiality (against humans glancing over your shoulder) than
ROT13 which is in turn offers less security (against passive
attackers) than 128-bit RC4.

> After talking with Pete some last night, I think another confusion here is
> (predictably) over uses of "opportunistic"  (as indeed the title of section
> 5.2 implies).
> 
> 1. Using TLS without checking the credentials presented by the remote side
> 2. Interoperating with legacy things using whatever TLS settings possible
> 
> I get the sense that a lot of the discussion here, especially from the mail
> perspective, is related to the second thing, which is so clearly out of
> scope for this document that it doesn't bear mentioning.  

With opportunistic TLS one accepts both communication where
authentication is impractical and communication where cryptography
is uses deprecated algorithms that are still sufficiently widely
"best available".

Thus most Postfix deployments disable SSLv2 (everyone can do better),
but not RC4 (enough sites for now cannot do better).  The RC4
ciphersuites required for interoperability are also non-PFS.

> And what I'm
> saying above is that this document *also* doesn't need to say anything
> about the first thing, because TLS looks exactly the same on the wire
> whether you check the credentials or not.

The document is not only about the bits that go on the wire.  It
is also about checks that clients SHOULD or MUST perform.

> I would probably be OK if the "Opportunistic" stuff were scoped down to
> say, "This document doesn't say anything about how you choose whether to
> use TLS for a given session, just how you use it once you do," and the
> unauthenticated stuff were removed entirely.

Well, when Postfix uses opportunistic TLS both client and server
prefer anon-DH ciphersuites over RSA or ECDSA ciphersuites, clients
ignore any certificates the server may return, and at present even
EXPORT (which include 40-bit RC4) cipher-suites are allowed.  TLS
is used routinely in ~70% of email MTA to MTA email transactions,
with no user to "click-OK".

Where the BCP recommends things that should be preferred, it is
largely applicable to opportunistic TLS with SMTP, one just needs
to prefer best-practice.  

Where the BCP attempts to proscribe things that are now potentially
vulnerable to attack, but which are still the best available for
enough peers, opportunistic use of TLS needs to ignore any advice
that would otherwise lead to much cheaper attacks on cleartext.

Basically, I'm fine with "raising the ceiling" as high as it seems
to make sense, but once the floor is raised too high, the BCP no
longer applies to opportunistic TLS.

	* server authentication needs to remain optional
	* non-PFS key exchange is still needed
	* RC4 and SSLv3 are still needed (perhaps another 2-3
	  years might be enough to change this).

	* SSLv2, MD5 and <= 64-bit ciphers can go, they are no
	  longer used, but banning them is largely unnecessary.
	  They've disappeared without a ban.

-- 
	Viktor.

P.S.  I am surprised by the repeated statements that "we don't know"
      what is required for opportunistic security.  It is rather
      simple, what's required is the freedom to adapt to the peer's
      capabilities, including those of peers in the long tail of the
      protocol technology adoption curve.

      Of course at some point truly obsolete protocols are left
      behind, but that happens long after they are no longer
      best-practice, rather it happens when they are essentially
      no longer practiced at all.

      Best current practices still make it into opportunistic
      security.  They are what should expect happen when the
      communicating peers are reasonably up to date.  Often
      one even gets better than best current practice, because
      both peers are "bleeding edge".