Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 04 May 2018 16:13 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 860B5126C83; Fri, 4 May 2018 09:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 e9rra-np6I4K; Fri, 4 May 2018 09:13:05 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D629126579; Fri, 4 May 2018 09:13:05 -0700 (PDT)
Received: from [100.70.184.123] (unknown [209.48.7.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2EEFF7A3309; Fri, 4 May 2018 16:13:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBN-SHAnyevhRvXeZA_AJ1ED7+hxOKznmyjyfiSX-9ZeYw@mail.gmail.com>
Date: Fri, 04 May 2018 12:13:03 -0400
Cc: uta@ietf.org, draft-ietf-uta-mta-sts@ietf.org, uta-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <0A702CAD-B5E0-4F6B-A32F-1CC6B86E65D1@dukhovni.org>
References: <152539648489.11713.7895583526344282774.idtracker@ietfa.amsl.com> <20180504051945.GS3322@mournblade.imrryr.org> <CABcZeBORH1iKZ2QZb_DBcwsDdBDS8Nbxb_A6Q7RxNL6X6Xg_BQ@mail.gmail.com> <7A6E57A9-E7B5-4326-B4B5-7777DFCF8C44@dukhovni.org> <CABcZeBN-SHAnyevhRvXeZA_AJ1ED7+hxOKznmyjyfiSX-9ZeYw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/-AbJNwJDvmCY3lPMJXjdiRK7_iw>
Subject: Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)
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: Fri, 04 May 2018 16:13:07 -0000
> On May 4, 2018, at 11:45 AM, Eric Rescorla <ekr@rtfm.com> wrote: > >> If the meaning of the matching field were changed to be an >> MX hostname pattern, rather than a presented-identifet (RFC6125) >> pattern, then we'd need rather prominent warnings in the >> text about routing loop avoidance. > > Well, in general when STS is misconfigured you can have problems. > I don't see that this case is sufficiently important to go away from > standard TLS semantics. For the record, I'm concerned about implementation pitfalls, not misconfiguration. A domain where not all the MX hosts are not listed in the STS policy is "normal" is not misconfigured per-se, STS-aware clients would send only via the secure MX hosts, other clients may use the full set. This is not a recommended configuration, but it should work, provided at least one best-preference MX host is listed. The basic idea is that STS is there to secure mail routing, not trump it. As much as possible mail routing should continue to be based on the MX host names. An MX host not listed in the policy might never-the-less possess a certificate matching the policy (if the policy specifies presented-id patterns rather than MX host patterns). Which is not to say that alternative designs can't work, they'd emphasize doing TLS "by-the-book" over doing SMTP "by-the-book". My instinct is to do SMTP "by the book", the goal here is to deliver email, securely when possible. This protocol is an opportunistic upgrade from cleartext to unauthenticated TLS to authenticated TLS when STS policy is located and/or cached, some caution may be appropriate to not over-optimize for security at the expense of operational robustness. Especially in the email space, fragile security gets turned off, RFC7435 and all that... One related observation (thanks for the hard questions that lead to the insight), perhaps worth mentioning in Security Considerations, is that with MTA-STS an attacker who can forge MX records or address RRsets of MX hosts can cause mail to bounce when the sender finds no A/AAAA records for any of the MX hosts. The reverse path may not be STS protected, and the bounce may return to the sender in the clear. An implementation that naively filters the MX RRset first, before eliminating MX hosts at the same or worse preference than the sending host is buggy, and I think this bug is quite likely. These days few read a complete document cover to cover, we tend read the bits we think we need. Information overload and all that. So the warning about MX loops would likely be needed in multiple places in the document to make MX patterns safer for implementors with a typical attention span. If the authors, IESG, the WG participants reading this, ... decide to go back to MX host patterns at this point, I won't stand in the way, I would just ask for prominent warnings about MX RRset truncation at the sending host's own preference (when found in the original MX RRset, forged or not) and above happening BEFORE any policy filtering of the MX RRset. -- Viktor.
- [Uta] Eric Rescorla's Discuss on draft-ietf-uta-m… Eric Rescorla
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Eric Rescorla
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Alberto Bertogli
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Eric Rescorla
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Alberto Bertogli
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis