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.
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- [Uta] "webby" STS and DANE/DNSSEC co-existence Stephen Farrell
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Mark Risher
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Chris Newman
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Binu Ramakrishnan
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Eric Rescorla
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Chris Newman
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Chris Newman
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence =JeffH
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Stephen Farrell
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Leif Johansson