[Uta] Comments on draft-ietf-uta-mta-sts-03
Federico Santandrea - Diennea <federico.santandrea@diennea.com> Mon, 27 March 2017 08:08 UTC
Return-Path: <prvs=1259b43191=federico.santandrea@diennea.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 A9325129474 for <uta@ietfa.amsl.com>; Mon, 27 Mar 2017 01:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 iVoWnqB-2S3f for <uta@ietfa.amsl.com>; Mon, 27 Mar 2017 01:08:26 -0700 (PDT)
Received: from mx-r1.mag-news.it (mx-r1.mag-news.it [46.29.201.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01531293DA for <uta@ietf.org>; Mon, 27 Mar 2017 01:08:25 -0700 (PDT)
Received: from mail1.mag-news.it by diennea.com (mx-r1.mag-news.it) (SecurityGateway 4.0.1) with ESMTP id SG003449555.MSG for <uta@ietf.org>; Mon, 27 Mar 2017 10:08:23 +0200S
Received: from EXC01-Arezzo.diennea.lan (10.80.108.190) by EXC01-Arezzo.diennea.lan (10.80.108.190) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Mar 2017 10:08:21 +0200
Received: from EXC01-Arezzo.diennea.lan ([fe80::5104:cf16:9c4c:7fda]) by EXC01-Arezzo.diennea.lan ([fe80::5104:cf16:9c4c:7fda%19]) with mapi id 15.00.1178.000; Mon, 27 Mar 2017 10:08:21 +0200
From: Federico Santandrea - Diennea <federico.santandrea@diennea.com>
To: "uta@ietf.org" <uta@ietf.org>
Thread-Topic: Comments on draft-ietf-uta-mta-sts-03
Thread-Index: AdKm0IX3L57s0I0dQZiX286rNOg8GA==
Date: Mon, 27 Mar 2017 08:08:21 +0000
Message-ID: <d42e535b43f14fc68b9b3e22cdff2e51@EXC01-Arezzo.diennea.lan>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.168.1.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SGSPF-Result: none (mx-r1.mag-news.it)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/N2QvMjX_z7nHwYJHU5MA3KLTw7w>
Subject: [Uta] Comments on draft-ietf-uta-mta-sts-03
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: Mon, 27 Mar 2017 08:08:29 -0000
Here's something that came to my mind while reading draft-ietf-uta-mta-sts-03. Let's suppose the sending MTA finds the MTA-STS TXT record, which states the receiving domain has an MTA-STS policy. The draft says "To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record". But what happens when the sending MTA can't fetch the actual policy via HTTPS? Now the sending MTA knows MTA-STS should be in place, but can't know what the list of expected MX is. It has to decide what to do. - If it refuses to send the message, and the (unreachable) policy states that it is in "report" mode, this can be considered a denial of service. - If instead it falls back to deliver the message to any available MX, either encrypted or in plain text, or even acts as if the domain had not stated it had an MTA-STS policy at all; and the (unreachable) policy states that it is in "enforce" mode, then effectively this was degraded to opportunistic. Making the HTTPS endpoint unreachable is just a DDoS attack away. This would expose all first-contact sending MTAs to this conundrum. I think there is a need to clearly state what must be done in such a situation. For example we could add to Section 3.3: "If a MTA-STS TXT record is found but no policy can be fetched from the HTTPS endpoint, and there is no previous cached policy, then senders MUST assume the recipient domain does not implement MTA-STS." While this does not really improve the situation, it makes clear for the implementor of the receiving side that this is effectively equivalent to opportunistic encryption and allows for countermeasures to be considered. The reason for the "no previous cached policy" part is to provide for the first-contact scenario, but there is another one: what if instead the sender has previously seen a policy for the domain, but now it's expired (because of max_age or new id in the TXT record) and it can't fetch a new one? I propose that we let the domain owner decide, by stating it in the at a time when it was reachable. We could add a "fallback_mode" property to the policy object, with possible values: "block", "keep_expired", "opportunistic" (names are provisional and for illustration only). This property would define what the sending MTA is to do when it must fetch a new policy but can't: - "block" would state confidentiality is still favored over availability, therefore since the new expected MX list is not known (and might be missing compromised servers), messages must be discarded or retried at a later time when the endpoint might be available again; - "keep_expired" would keep applying the cached policy, which would not be discarded until it's possible to fetch a new one. I see this as useful because to me it's often the case that an expired policy would be more useful than no policy at all. - "opportunistic" would say that, in this non-normal scenario, availability is to be favored over availability, so the sender should discard the expired policy and act like in the previously explained first-contact scenario. The last one of course would mean that it's possible to force a fall back to plaintext by making the HTTPS endpoint unavailable until a policy expires, but the domain owner would have chosen this explicitly and has to understand that. -- Federico ________________________________ Iscriviti alla nostra newsletter per rimanere aggiornato su digital ed email marketing! http://www.magnews.it/newsletter/ The information in this email is confidential and may be legally privileged. If you are not the intended recipient please notify the sender immediately and destroy this email. Any unauthorized, direct or indirect, disclosure, copying, storage, distribution or other use is strictly forbidden.
- [Uta] Comments on draft-ietf-uta-mta-sts-03 Federico Santandrea - Diennea
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Viktor Dukhovni
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Jim Fenton
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Viktor Dukhovni
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Federico Santandrea
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Federico Santandrea
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Viktor Dukhovni