[Uta] draft-ietf-uta-mta-sts-04 Review

<Gerard.DRAPER-GIL@ec.europa.eu> Thu, 06 April 2017 09:08 UTC

Return-Path: <Gerard.DRAPER-GIL@ec.europa.eu>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A31243F6 for <uta@ietfa.amsl.com>; Thu, 6 Apr 2017 02:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wgO23Lih2jvE for <uta@ietfa.amsl.com>; Thu, 6 Apr 2017 02:08:54 -0700 (PDT)
Received: from out.mail.ec.europa.eu (out.mail.ec.europa.eu []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840361200FC for <uta@ietf.org>; Thu, 6 Apr 2017 02:08:53 -0700 (PDT)
Received: from S-DC-EMP019-I.net1.cec.eu.int ( by S-DC-EDG009-Q.rcnet.cec.eu.int ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 11:08:42 +0200
Received: from S-DC-EMP009-B.net1.cec.eu.int ( by S-DC-EMP019-I.net1.cec.eu.int ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 11:08:49 +0200
Received: from S-DC-ESTE03-B.net1.cec.eu.int ([]) by S-DC-EMP009-B.net1.cec.eu.int ([]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 11:08:50 +0200
From: <Gerard.DRAPER-GIL@ec.europa.eu>
To: <uta@ietf.org>
Thread-Topic: draft-ietf-uta-mta-sts-04 Review
Thread-Index: AdKutGbXiPZGQt7NR9iZoIOalBzYkA==
Date: Thu, 6 Apr 2017 09:08:49 +0000
Message-ID: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int>
Accept-Language: en-GB, fr-LU, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2DB01F3A9898AE41BB3266315D9FDA2704903D88SDCESTE03Bnet1c_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/2qY2Q3L0a6TuiB9-9hS0rxtRCZk>
Subject: [Uta] draft-ietf-uta-mta-sts-04 Review
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, 06 Apr 2017 09:08:57 -0000

Some minor comments and a question on policy updates.

_ Section 3.2 MTA-STS Policies, when describing the "mx" parameter, it says:

"For example, "["mail.example.com", ".example.net"]" indicates that
mail for this domain might be handled by any MX with a certificate
valid for a host at "example.com" or "example.net"..."
Should't it say: " valid for a host at 'mail.example.com'"?

_ Section 3.3 HTTPS Policy Fetching

"When fetching a new policy or updating a policy, the HTTPS endpoint
MUST present a X.509 certificate which is valid for the "mta-sts"
host (as described in [RFC6125]), chain to a root CA that is trusted
by the sending MTA, and be non-expired."
 Maybe it's redundant, but since it explicitly mention non-expired,
should it also mention not revocated?

"If a valid TXT record is found but no policy can be fetched via
HTTPS, and there is no valid (non-expired) previously-cached policy,
senders MUST treat the recipient domain as one that has not
implemented MTA-STS."
 I think that a better option would be to report the recipient and
continue with opportunistic TLS.

_ Section 4 Policy Validation:

"2.  That at least one of the policy's "mx" patterns matches at least
     one of the identities presented in the MX's X.509 certificate, as
     descriped in "MX Certificate Validation"."

The last line should say "described in ..."

_ Section 4.1 MX Certificate Validation: (Same than in section 3.3 about certificates)

"The certificate presented by the receiving MX MUST chain to a root CA
that is trusted by the sending MTA and be non-expired. "
 Maybe it's redundant, but since it explicitly mention non-expired,
should it also mention not revocated?

_ Section 5.1 Policy Application Control Flow

"3. Upon message retries, a message MAY be permanently failed
    following first checking for the presence of a new policy (as
    indicated by the "id" field in the "_mta-sts" TXT record)."

It does not specify the number of retries. A parameter could be added to
the policy to indicate the number of retries before permanent failure,
with a default value of X.

Maybe I missed it, but I didn't see any mention to what to do if
the id from the TXT record does not match the id from the HTTPS policy.

_ Security considerations:

The first paragraph of Section 6.1 contradicts the second paragraph on Section 8.3

  "Updating the policy requires that the owner make changes in two
   places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
   at the corresponding HTTPS endpoint.  As a result, recipients should
   thus expect a policy will continue to be used by senders until both
   the HTTPS and TXT endpoints are updated and the TXT record's TTL has
   passed." (1st paragraph Section 6.1)

  "This attack is mitigated in part by the ability of a victim domain to
   (at any time) publish a new policy updating the cached, malicious
   policy, though this does require the victim domain to both obtain a
   valid CA-signed certificate and to understand and properly configure
   MTA-STS." (2nd paragraph Section 8.3)

   If I am able to publish a new policy, but this policy does not reach
   the senders, then I am not solving the problem.

The whole policy application, update is not clear to me, it seems there is
a contradiction between the fact, mentioned a couple of times, that a policy
can be updated any time, and the resistance to "TLS downgrade" attacks. Please
correct me if I'm wrong.

In the policy updates, it clearly states that updating a policy requires
updating both the TXT record and the HTTPS policy.

DNS request are usually served by intermediary DNS servers, that will update
the cache based on the TTL of records, whereas HTTPS requests will be usually
served by the "final" server itself, therefore policy updates will immediately
(almost) be deployed.

This creates a dilemma. Using short TTLs to allow frequent policy updates increases
the window of vulnerability (policy update requires fetching the TXT record),
but using long TTLs reduces the ability to update the policy on-demand.

A possible solution could be to unlink the id from the TXT record from the id of the policy.
A long TTL (1 month?) can be used to "broadcast" that a domain applies MTA-STS, and a short
max-age (hours, minutes?) can be used to facilitate frequent policy updates.

Finally, regarding the JSON vs pair-of-values,  I think that at this stage the opinion of the
Implementors (those who will implement it) should prevail, to facilitate its future acceptance.
I don't think it makes much difference for domain controllers, who may deploy it.

Gerard Draper Gil