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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 18 April 2016 04:48 UTC

Return-Path: <ietf-dane@dukhovni.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 9779612DE89 for <uta@ietfa.amsl.com>; Sun, 17 Apr 2016 21:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 jYbzJIlHsTl7 for <uta@ietfa.amsl.com>; Sun, 17 Apr 2016 21:48:31 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE6812D815 for <uta@ietf.org>; Sun, 17 Apr 2016 21:39:51 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CBD60284B6F; Mon, 18 Apr 2016 04:39:50 +0000 (UTC)
Date: Mon, 18 Apr 2016 04:39:50 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <20160418043950.GJ26423@mournblade.imrryr.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> <57145842.2050604@bluepopcorn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <57145842.2050604@bluepopcorn.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/q4YOdDyK5CVtnvXE3o-8xPjEKqE>
Subject: Re: [Uta] "webby" STS and DANE/DNSSEC co-existence
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
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 04:48:32 -0000

On Sun, Apr 17, 2016 at 08:45:06PM -0700, Jim Fenton wrote:

> 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 agree that it may make more sense to set protocol floors in TLS
libraries and "die die die" RFCs that obsolete old protocol versions
than to do so via DEEP application latches.  The TLS protocol
version latches are likely too much work for too little gain.

-- 
	Viktor.