Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

Aaron Zauner <azet@azet.org> Thu, 14 April 2016 12:38 UTC

Return-Path: <azet@azet.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 3F88112DAE4 for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 05:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org
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 gR6CfcUaIckN for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 05:38:31 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 2F19712D0A7 for <uta@ietf.org>; Thu, 14 Apr 2016 05:19:00 -0700 (PDT)
Received: by mail-pa0-x231.google.com with SMTP id fs9so25795544pac.2 for <uta@ietf.org>; Thu, 14 Apr 2016 05:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=0wRdDYMwtQDCWa9xMY6IDQbPTVLw4vMOhH171WLtKjM=; b=WyLdPgFjTcQxgmb10m6REqIhKd/wn/PMuqnto6Y4WbZmNkoJDV25k0j8AuuIXR4hgV OvsHCHLQvmrOZzNV/DOKKA3VqCnTu2DJMaY3SFbJYFFiBKaJnzB1tvvQKsl8xJEyykTB pyi0wLkd+KHqB7WzN4spiyjx+dsepsCy2Tm7s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=0wRdDYMwtQDCWa9xMY6IDQbPTVLw4vMOhH171WLtKjM=; b=E7jyq47E9NqJy2eRMXSbNf0ONt8lzDaWaxYny50LoFtgJknkaqpd9SpodlHTT6SRuh LmpWVxtwvczwNTR2Qx+0vkA8p3His2A/yVFYrUDunA3QlSW3/dUiebe4yk7vvjIh78aG t6kIJIb9aTH9natbH17LSdmjbGYAMyke0NXDfBe7+AOY92NZFUFeE4w26l3mbLi6/HL9 Fdk62sCDIYEMAjFFh4vlumayjysa91vQdnfK1PVH2E4+pp8hDyOSVJH6hF6lbNiGxGd1 g/xp7pZrLi/jtiZqn1zzQdfHILRH/J2VtVofj9RiOH8tjBIlMoHhrJloLvItGbxZW5r6 Shig==
X-Gm-Message-State: AOPr4FXy3SwyIpufFk/5dO7eDUAvp9pqLZnBiYUkjjfSeEbRLgrdjYDSRXN/806yGH7ITA==
X-Received: by 10.67.14.98 with SMTP id ff2mr20631203pad.105.1460636339740; Thu, 14 Apr 2016 05:18:59 -0700 (PDT)
Received: from [192.168.0.128] (node-278.pool-180-180.dynamic.totbb.net. [180.180.11.36]) by smtp.gmail.com with ESMTPSA id f12sm57627942pfd.87.2016.04.14.05.18.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Apr 2016 05:18:57 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7E2FA12B-8C9D-4ED8-B3C9-0C2E17CC95C5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Aaron Zauner <azet@azet.org>
In-Reply-To: <CANtKdUdT+Lf89-EiJQ9rCvv=ph+z2AJEjSM7KUDcs85ztgRPEw@mail.gmail.com>
Date: Thu, 14 Apr 2016 19:19:32 +0700
Message-Id: <28DE8B5E-C588-48C3-A6ED-790C45A5B103@azet.org>
References: <20160413191405.GF26423@mournblade.imrryr.org> <542002133.1160.1460581138072.JavaMail.yahoo@mail.yahoo.com> <20160414063807.GB17212@mournblade.imrryr.org> <CANtKdUdT+Lf89-EiJQ9rCvv=ph+z2AJEjSM7KUDcs85ztgRPEw@mail.gmail.com>
To: Daniel Margolis <dmargolis@google.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/fzxs35809D-3-6pXI0jZql356Ws>
Cc: uta@ietf.org
Subject: Re: [Uta] "webby" STS and DANE/DNSSEC co-existence
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: Thu, 14 Apr 2016 12:38:32 -0000

> On 14 Apr 2016, at 15:58, Daniel Margolis <dmargolis@google.com> wrote:
> 
> 
> On Thu, Apr 14, 2016 at 8:38 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> If the STS spec is just for email between Yahoo and Gmail, sure,
> go for it.  Less work for me, I won't need to implement yet another
> transport security mechanism.
> 
> A more reasonably modest STS would stay well clear of prescribing
> such fine details.  Once the policy lookup requires WebPKI support,
> pinning MX host certs is fragile over-engineering.
> 
> To be clear, HPKP allows pinning a root or intermediate cert, not just the host cert. I think pinning someone in the cert chain and not the host cert is generally preferable (in terms of safety and ease of certificate rollover).

The SMTP-STS draft mentions 'certificate pinning' as future work. Would you really want to go the way of HPKP? It's been an utter deployment and management disaster [0] [1]. While I agree that pinning to host-keys will mean more trouble for admins, I do feel that HPKP in general is a completely wrong approach. Adding this on top of STS will most surely make mails bounce at massive scale, at least in small deployments. Companies like the ones authoring the STS draft will have proper engineering teams and man-power available. Not every MX on the internet is Gmail or Yahoo, just to reiterate my concern about STS's complexity and out-of-band behaviour.

I've repeatedly suggested a better solution for pinning that works with WebPKI based trust anchors and would not need a webserver along with an MTA.

To be honest: this is getting a bit frustrating. I feel the STS authors look for a solution that works well within their domains and management cycles, but that's far from the rest of the internet community - they do not have the same man-power as said companies have. And even automating HPKP is doomed to fail, some tried, I haven't seen a good working solution.

Aaron

[0] http://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html (current)
[1] https://www.internetsociety.org/sites/default/files/01_4_0.pdf (about a year old)