Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Viktor Dukhovni <[e-mail]>]

On Tue, Aug 25, 2015 at 07:26:53AM +0000, Peter Gutmann wrote:

> Viktor Dukhovni <[e-mail]> writes:
> 
> >Opportunistic TLS was added to Microsoft Exchange 2003, and further extended
> >in 2007.
> 
> It's not true opportunistic TLS (unless they've fixed it recently), it's "pay
> a commercial CA to be allowed to do TLS", unlike pretty much every other MTA
> I'm aware of which allows you to just set up and go without having to buy a
> cert for each server.

Server side STARTTLS support, which is agnostic as to whether the
client is opportunistic or not, is available with Exchange 2003
and later.

Opportunistic TLS is supported in at least Exchange 2007 and later.
I don't recall what Exchange 2003 did outbound, I only recall
helping  Microsoft to design fixes for various issues prior to the
release of Exchange 2007.  Some flaws remain, but it is largely
workable without a CA tax.

> (I'm not saying this as part of some anti-CA crusade, but to point out that
> Exchange puts a considerable hurdle in the way of universal opportunstic TLS
> for email.  To do opportunistic TLS with Postfix or most (all?) other MTAs,
> you need just the MTA.  To do it with Exchange, you need the MTA plus
> permission from a commercial CA to use TLS.  In the interests of getting hard
> data for this, I wrote to Aaron Zauner, who did the TLS-with-SMTP survey, a
> few days ago to ask if he has distinct stats for Exchange vs. everything else).

Inbound, Exchange does not and cannot know whether the client is
authenticating the server certificate or ignoring it.  Outbound,
there are still a few known defects, that I've communicated to
Microsoft, and will I hope be fixed at some point.

The most significant known issues are TLS handshake failure and
fallback to cleartext when:

    * The peer's certificate is expired.  Even though authentication
      is not required and it would be accepted from an untrusted
      issuer.

    * The peer's certificate chain has certificates signed with
      MD5.  Even if the only use of MD5 is in the self-signature
      of a root CA, and even for client cerficates which are
      solicited though the server does not use them.

    * The server's certificate uses SHA2-256, but the peer only supports
      TLS 1.0, or in any case fails to include SHA2-256 in the supported
      signature algorithms extension.

The last of these is a result of implementing RFC 5246 (TLS 1.2),
rather than what makes sense.  It looks like TLS 1.3 is on track
to be sensible in this regard (server-side handling of certificate
signature algorithms).

The majority of clients and servers don't run into the above
problems, but they do thwart STARTTLS for a non-negligible minority
of systems.

-- 
	Viktor.