[Uta] Questions about MTA STS complexity

Alberto Bertogli <albertito@blitiri.com.ar> Sun, 04 December 2016 16:06 UTC

Return-Path: <albertito@blitiri.com.ar>
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 B85C7129541 for <uta@ietfa.amsl.com>; Sun, 4 Dec 2016 08:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 TYSFO2Vw8QBP for <uta@ietfa.amsl.com>; Sun, 4 Dec 2016 08:06:57 -0800 (PST)
Received: from blitiri.com.ar (cdt.blitiri.com.ar [IPv6:2001:41d0:401:3100::2c1a]) (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 52730129440 for <uta@ietf.org>; Sun, 4 Dec 2016 08:06:57 -0800 (PST)
Received: from blitiri.com.ar (authenticated as alb@blitiri.com.ar) by cdt.blitiri.com.ar (chasquid) (over submission TLS-1.2-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) (envelope from "albertito@blitiri.com.ar") ; Sun, 04 Dec 2016 17:06:55 +0100
Date: Sun, 04 Dec 2016 16:06:54 +0000
From: Alberto Bertogli <albertito@blitiri.com.ar>
To: uta@ietf.org
Message-ID: <20161204160654.GL12784@blitiri.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/J2jZtC0jBRDOMUqZm6Z_SH6jXHI>
Subject: [Uta] Questions about MTA STS complexity
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 04 Dec 2016 16:06:59 -0000

Hi!

I recently came across the MTA STS draft as part of some SMTP work I'm
doing on my spare time.

I really like the end goals of it, and would love to see them widely
deployed.

However, I couldn't help but find it a bit complex, in particular in
ways that I think will make it difficult for smaller domains to adopt.

While surely it's not outside the abilities of a strong dedicated team
or a careful individual, it requires significant domain knowledge in a
few areas, and is easier to get wrong.

In particular:

- Requiring additional DNS records make it more difficult to set up.
- Having to keep the IDs in sync between the DNS records and the HTTPS
  policy is, IMO, a significant operational burden, and makes it more
  difficult to “get it right" when making changes.
- The above also carries a complexity overhead in the RFC itself and the
  software implementation, by having to consider the interactions
  between the two (such as the caching logic, multiple level domains,
  etc.).


I was wondering if this you had any rationale about those decisions that
would help me understand why the current draft chose to go in this
direction, instead of potentially simpler approaches.


I hope this doesn't come across the wrong way, I debated whether to send
this or not, but seeing the invitation to comment on your git repository
tipped the scale :)

Thanks a lot!
                Alberto