Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

ned+uta@mrochek.com Thu, 12 April 2018 00:18 UTC

Return-Path: <ned+uta@mrochek.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D2912D9FF for <uta@ietfa.amsl.com>; Wed, 11 Apr 2018 17:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk3D2k0PRF_o for <uta@ietfa.amsl.com>; Wed, 11 Apr 2018 17:18:10 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D3212D86E for <uta@ietf.org>; Wed, 11 Apr 2018 17:18:09 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QR8079P0BK00J6W8@mauve.mrochek.com> for uta@ietf.org; Wed, 11 Apr 2018 17:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1523491987; bh=28lbF6EwxTUKhtvRnk9Ss6bk/4CJrS8h1LClP0nKbfc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=eMov3jxnjLA2W/cuQfYypXPEFpB1MAwVZkLnwG5NbPiaTvXuBy2FfCHqdEvc1oe5w /9BCawos5Ibz0Rose1ADKo8d5P49uWXB/QkWWTWt/SJDhdb0flmxBrb3W+dwJ/p5Mk xFEzGpeamy+Gugnhvqv9+ZroV/m6jfBw7lSB1Ezs=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QR4MYJ0NQO000051@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for uta@ietf.org; Wed, 11 Apr 2018 17:13:03 -0700 (PDT)
From: ned+uta@mrochek.com
Cc: Ned Freed <ned.freed@mrochek.com>, "ietf@ietf.org Discussion" <ietf@ietf.org>, uta@ietf.org
Message-id: <01QR80776HKE000051@mauve.mrochek.com>
Date: Wed, 11 Apr 2018 16:49:54 -0700
In-reply-to: "Your message dated Thu, 12 Apr 2018 00:17:43 +0100" <CAKHUCzzLWNQqPbgh7iGraJqviFuSP_A4i2-qKKfNS5fypKbZzQ@mail.gmail.com>
References: <CAKHUCzwes5vHjBSDqYXkvGRCGPeSPnqNgsJ2J_tDzF2FG+RuMg@mail.gmail.com> <01QR7KDO3D96000051@mauve.mrochek.com> <CAKHUCzzLWNQqPbgh7iGraJqviFuSP_A4i2-qKKfNS5fypKbZzQ@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/vzXmE7ogvn-CjXlVlYDsm_rP1Z8>
Subject: Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 00:18:14 -0000

> > > 2) HTTPS Call-out
> >
> > > Given the policy is essentially trust-on-first-use, it's not clear to me
> > > why much of the STS policy cannot be transferred within SMTP itself,
> > > perhaps in response to the EHLO issued after STARTTLS completes. This is
> > > good enough for HTTPS's STS variant, and feels intuitively simpler for
> > MTAs
> > > to implement.
> >
> > I'm afraid you have this exactly backwards. Even if the SMTP server
> > approach
> > provided comparable security - and it doesn't -  deploying a new SMTP
> > extension
> > is quite difficult; we have an abundance of fully worked examples
> > demonstrating
> > this point. Whereas throwing up an A record, certificate, and server that
> > serves out a single document is trivially easy. These days I don't rank as
> > an
> > experienced IT person, and I was able to do it for a test domain in about
> > 20
> > minutes.
> >
> >
> I entirely agree that hosting a single document under HTTPS is trivial.


> > This is not to say that there aren't issues implementing MTA-STS. There are
> > significant issues, but they are all on the client side. Adding an HTTP
> > client
> > to your SMTP client significantly increases attack surface, so much so
> > that I'm
> > not willing to do it, and other folks have said they aren't willing to
> > either.
> >
> > The approach I'm using is to build an MTA-STS query server with integrated
> > caching support. I have one mostly coded, and while I haven't worked
> > through
> > all the caching and timeout issues yet, I have not found any significant
> > implementation obstacles.

> This workload is what I consider to be the antithesis of "intuitively
> simpler".

And once again I'm afraid what your intution is telling you is exactly the
opposite of my experience. For me implementing this using a separate query
server actually makes things much easier, not harder, in part because I'm not
constrained to code things in C/C++, which is what the SMTP client is coded in.

You might want to sit down and try mocking this up in, say, node.js. It may
change your mind about the approach.

And the client part is going to be maybe 50 lines of C code. Code of a sort
I've written many, many, many times before. Hardly difficult.

> > > c) Both/either of the above.
> >
> > > I assume the logic behind allowing a wildcard-to-wildcard match is to
> > allow
> > > a Google user to simply specify ".googlemail.com" and ".l.google.com" as
> > > their MX identity patterns; however it feels as though Google could
> > simply
> > > use a known name within the certificate for all their receiving MTAs,
> > > irrespective of the DNS records involved. This, of course, presupposes
> > that
> > > the administrator of the mail domain somehow does not know the precise
> > > names of the MTAs used in their own DNS records.
> >
> > > I further assume the logic in mandating matches against dNSName SANs is
> > > because these are readily available; however sRVName SANs, by restricting
> > > their use to a particular service, have the advantage that customers
> > giving
> > > these to their service provider might be deemed more acceptable.
> >
> > A comparable effect can be achieved by using a subdomain root reserved for
> > email server use.
> >
> > So it's a choice between an easily implemented naming convention  and a
> > bunch
> > of PKIX esoterica. This does not strike me as a difficult choice.
> >
> >
> Well, being *able* to use sRVName would be nice at least. The specification
> as written prevents it, which seems unfortunate.

I have to say I like the simplicity of the current specification, and I don't
want to see added complexity in this regard without a compelling reason for
adding it.

> > >    o  MTA-STS Policy: A commitment by the Policy Domain to support PKIX
> > >       [RFC5280] authenticated TLS for the specified MX hosts.
> >
> > > Impressively, by my reading, the commitment is for the Policy Domain to
> > > support PKIX for all SMTP; and not just for specified hosts.
> >
> > Of course that's the commitment. How could it be otherwise?
> >

> Then that needs rephrasing, because I didn't see any "Of course" about it.

> A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated
> TLS, using reference identifiers as listed.

> (I'm trying to guess what was meant by "for the specified MX hosts".)

The entire point of the mechanism is to say that the policy domain supports
and wants SSL/TLS transfers and that the servers have validated certs
with the specified names. So I really don't understand what you're getting
at here.

				Ned