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

Jim Fenton <fenton@bluepopcorn.net> Mon, 18 April 2016 03:45 UTC

Return-Path: <fenton@bluepopcorn.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 E6DC312DBC9 for <uta@ietfa.amsl.com>; Sun, 17 Apr 2016 20:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level:
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 2c1dgJwjofYM for <uta@ietfa.amsl.com>; Sun, 17 Apr 2016 20:45:13 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C5F12DBCC for <uta@ietf.org>; Sun, 17 Apr 2016 20:45:12 -0700 (PDT)
Received: from splunge.local (c-24-4-98-3.hsd1.ca.comcast.net [24.4.98.3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id u3I3jBrK019232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Apr 2016 20:45:12 -0700
To: Chris Newman <chris.newman@oracle.com>, uta@ietf.org
References: <570C0CD2.9030401@cs.tcd.ie> <20160411212128.GA26423@mournblade.imrryr.org> <CANtKdUekXNkVvsfq0UjCiaaPVBgoVGfrfnYUrdoOf0EegXMuPg@mail.gmail.com> <20160413014304.GB26423@mournblade.imrryr.org> <CANtKdUf0kN5aOmX0-NsyQXz_+PRGfaXa37DFZoCX3FqdYh5CpA@mail.gmail.com> <etPan.570e8549.3d8c14b4.1614d@jcaps-rd2.us.oracle.com> <57107E44.3040108@bluepopcorn.net> <etPan.5712752a.309ce839.18439@dhcp-adc-twvpn-3-vpnpool-10-154-102-192.vpn.oracle.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <57145842.2050604@bluepopcorn.net>
Date: Sun, 17 Apr 2016 20:45:06 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <etPan.5712752a.309ce839.18439@dhcp-adc-twvpn-3-vpnpool-10-154-102-192.vpn.oracle.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1460951112; bh=J8DQusQNXAPvcOi75hAI58fCuDXg375gR+/He5nxOvQ=; h=Subject:To:References:From:Date:In-Reply-To; b=BNlzEsywJuwipGyU5C7cjT+1aHeuUHxS1sDRa93aP9cjKRD2n9Oq4VpwSmsfuwcMA XyLBFxC2FZEOetwmWmdahK4VX0WFKRAkjXb9Enj31SlBtu2ZmU0EAwdMWwRx3TQpCG kuy1+u+zcCkOP9dKEuVoNxkmrPhHdZWu2zJ9ISaA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/gguxVFJp4QrZxSaa2ejV9QrG6PI>
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: Mon, 18 Apr 2016 03:45:15 -0000

On 4/16/16 10:23 AM, Chris Newman wrote:
>  
>>> So while Viktor made a compelling case that the TLS version directive is not appropriate for SMTP relay, I think it is appropriate for the MUA STS scenario where it’s simpler to implement, where very old MUAs are in wide use requiring permissive servers, and I’d really like to be sure my client is using the stronger versions of TLS as long as I don’t have to manually configure it.

I'm a little confused by the language in section 9.1 "All [client and
server] implementations MUST be configurable to support implicit TLS
using the TLS 1.2 protocol or later."  So why not insist in TLS 1.2 all
the time? There must be a deployment corner case that I'm not considering.

But, as you noted in section 6, the choice of TLS version isn't the only
thing that needs to be considered. Why does TLS version rise to the
level of importance of creating a directive, but cipher suite doesn't?

I don't see the complexity and interoperability risk associated with all
this to be warranted by the relatively low level of security risk.

Also, if we're talking about some unification of STS and DEEP (as
"MUA-STS" or something, if I recall correctly), and the STS policy is
retrieved in a "webby" manner, the policy record probably also needs to
adhere to its own standards for TLS version, cipher suite, etc. Which
could be problematic if an attacker can publish a record for a
known-vulnerable cipher suite or something.

-Jim