Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard
Dave Cridland <dave@cridland.net> Wed, 11 April 2018 11:38 UTC
Return-Path: <dave@cridland.net>
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 344F6126CE8 for <uta@ietfa.amsl.com>; Wed, 11 Apr 2018 04:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
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 Js9iyXosfSMf for <uta@ietfa.amsl.com>; Wed, 11 Apr 2018 04:38:41 -0700 (PDT)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53DB124BE8 for <uta@ietf.org>; Wed, 11 Apr 2018 04:38:40 -0700 (PDT)
Received: by mail-lf0-x244.google.com with SMTP id g203-v6so2133549lfg.11 for <uta@ietf.org>; Wed, 11 Apr 2018 04:38:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=6OTOh+2158N6PN+EgbWjlp+nrADrdXjb4hXZdW7BIso=; b=E+yXYx1ooTZ1AfM7A+wZw4o5yZPH1Ah5+K9Pi9UcgqQX/yjKsncYL1asJtYiu5g8dT wsO5LfOntZg5SgeIn/sszt5F26vRNO/0empufsyY8oSCWyX0Z/zkmJN8NT7/5WhRCQvn ZzdWFfwkHuqp0cb/udvuLrmZwGG3krz/tvIdI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6OTOh+2158N6PN+EgbWjlp+nrADrdXjb4hXZdW7BIso=; b=sqwwRs7tyHRlqoUjIVzz3rwCBhiFGxpCPtvy6xWgO0ctOLbFjE/dSfjdR1b5DN4L3x 2Hu2WWisC1ExAyykn4/zaG1B2ilj1N4xVR7v/iuZEDbxUIwk9mxs/FKHRPl+ETQaf1+P x3WlovsaXQw0TyO0GWvQCwbzAkekD2x/u8HZO4r9KYOSMGxNynXcv840oScF/hyG/68S vSAZdk8wkZqxunP8aO+hn/PzqO6x49D8uO/gnQN8u+IUYL+GJGJ6aKchi/5kE5TCBmIp cf+jKA9IHVhoiZ50AxarxHrLG0fS3W/sK4+JPFV9oQMvKEXvK1YyYLL+VjPBS7SlR6uI fFcQ==
X-Gm-Message-State: ALQs6tBA5zgzgO+tyDBbUBa4SSsCreJa+hsq/AHwA8MnLTAiSQeKlJu3 wkuMGBbQN0ENknRow7FBnkKpNFlJ+z5jmxC9nWkuTQ==
X-Google-Smtp-Source: AIpwx48S8GtMeDXs8u29N8TkkJJYTSPs9W3vDDcMRN+2+UM4mw6V8zMqIUnM/fk9w5NqvO5n+aysO2+75vR2Ry+NFN4=
X-Received: by 10.46.46.10 with SMTP id u10mr2698128lju.77.1523446718777; Wed, 11 Apr 2018 04:38:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.179.71.202 with HTTP; Wed, 11 Apr 2018 04:38:38 -0700 (PDT)
From: Dave Cridland <dave@cridland.net>
Date: Wed, 11 Apr 2018 12:38:38 +0100
Message-ID: <CAKHUCzwes5vHjBSDqYXkvGRCGPeSPnqNgsJ2J_tDzF2FG+RuMg@mail.gmail.com>
To: "ietf@ietf.org Discussion" <ietf@ietf.org>
Cc: uta@ietf.org
Content-Type: multipart/alternative; boundary="089e0823f83481e6b105699114fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/9lWyDMZnOdCaipGze0hg9Kxv-Zk>
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: Wed, 11 Apr 2018 11:38:45 -0000
Since this was mentioned to me at IETF 101, I managed to find the time to look it up and review. Several design decisions have left me confused; most notably the notion of a call-out to HTTPS in the first place. Much of the document is unclear to me, despite having a background of both Internet Mail and the application of PKI in application protocols, and it appears to willfully ignore prior art in this area. 1) A History Lesson First, some history: In XMPP-land, we faced a similar issue with large-scale providers (most notably Google) not wishing to host or manage the certificates for their customers, alongside an assertion that customers would not wish to provide their private keys to their provider. Despite the strong evidence to the contrary in the case of HTTPS, the community nevertheless developed POSH (RFC 7711), and did so in a protocol-neutral way. In POSH, an entity fetches a well-known document from an HTTPS server in order to securely obtain information with which to validate a certificate by means other than building a traditional chain etc. Notably, this was against a backdrop of CAs which were not free, and generally quite expensive - this has changed markedly over the years since, and I should note that POSH's support for self-signed certificates is probably no longer relevant. However, it surprises me that the MTA-STS draft does not appear to note this prior art at all, and this makes me wonder whether it was even on the radar. Importantly, POSH was never deployed very heavily - I can find only one deployment (and "most users opt to just give us the cert"). This was in part because of Google's withdrawal from standards-based IM, which liberated the community from having to support a use-case only Google really felt important, and also the rise of free CAs, which avoided the cost issue associated with traditional PKIX. For reference, the XMPP community has a high penetration of DANE records (around 10% of the self-selected group who test their servers through community tooling) and a very high penetration of CA-signed certificates (mostly Let's Encrypt). 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. 3) DNSSEC or not? The MTA-STS problem is reasonably well-defined in the document - SMTP servers often do host numerous domains, and unfortunately operating one's own server has become a rarity, so domains are concentrated on a few servers. STARTTLS is, as the abstract notes, theoretically susceptible to a downgrade attack - but this does require either active MITM or some fairly tight hoops to jump through to actually exploit. The draft then goes on to compare the solution to DANE, and notes that DNSSEC is not required with MTA-STS - "at a cost of risking malicious downgrade attacks". These would be performed by DNS spoofing, which has a known history of occurring. In any case, what is distinctly unclear to me is whether MTA-STS without DNSSEC is materially different from RFC 7672 without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my immediate question is whether it might therefore be good enough for at least some cases of DANE. I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record is sufficient to mandate TLS - hence my question is whether an insecure TLSA record stipulating a particular trust anchor and/or valid certificate (PKIX-TA and PKIX-EE) might be sufficient to meet the same security requirements here. 4) Wildcard on Wildcard Action. It is deeply unfortunate that MTA-STS mandates a name match based on dNSName SANs only. I would have thought that emulating an SRV, and matching a corresponding sRVName, would be more useful - and overall, the idea that a new matching algorithm has been included so as to match an "mx pattern" to a dNSName wildcard just feels like an exploit waiting to happen. It would feel considerably safer to do one of: a) Make matches operate the same way as DANE, by being based on hashes of SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's approach of a certificate hash). b) Make matches operate the same way as RFC 6125 (unreferenced, I note). 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. 5) Terminology and Nomenclature. It is well-known that naming things remains the hardest problem in technology. However, this draft appears to have taken bold strides in demonstrating that coming up with new names for things needn't be so challenging. Take §7.1, for example, which dictates that the SNI extension MUST contain the "MX hostname" - this latter term does not appear anywhere else in the document. I'm going to guess that it means the RHS of the MX record, as defined in RFC 7672 (and informative reference), which is the same as RFC 7672. "MX host", which appears once in RFC 5321, also appears elsewhere in this draft, including in §1.1, where it is in this definition: 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. Using more common - and more uniform - terminology would be of huge benefit: "Sending MTA", "Receiving MTA", and so on are well-known terms. If a new term is needed, please do define it. If you mean to use terms from other RFCs, these need to be Normative References and noted in the Terminology section. 6) Reference Identifiers and derivation. RFC 6125 provides a slew of terminology and best practise - from the same UTA working group, as I recall. RFC 7672 also provides terminology and much behaviour. It feels as though this draft should at least attempt to use the same terminology, and ideally the same behaviour, as RFC 7672 (and RFC 6125). This is particularly noticeable in the difference between the reference identifiers used within RFC 7672 (and used within the SNI discussed there) compared with this draft, see for example this draft's §7.1, compared with RFC 7672 §8.1 7) Trust Anchors RFC 7672 suggests that MTAs cannot rely on a set of common trust anchors, in Section 1.3.4. While I'm not actually convinced this is really the case, I'm finding it odd that on the one hand, we have a consensus standards-track document that makes this assertion, yet on the other this draft makes - implicitly - the opposite assertion. It would be useful to understand if circumstances have changed. Dave.
- [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> … The IESG
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… ned+uta
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Dave Cridland
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… ned+uta
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Dave Cridland
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Dave Cridland
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… ned+uta
- [Uta] Digression on DANE for MTAs implementation … Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Dave Cridland
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Dave Cridland
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.t… Daniel Margolis