Re: [TLS] A la carte concerns from IETF 93
Hubert Kario <hkario@redhat.com> Thu, 23 July 2015 11:10 UTC
Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7141A8729 for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 04:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 M2NA1WK1THjo for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 04:10:01 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304A41A872A for <tls@ietf.org>; Thu, 23 Jul 2015 04:10:01 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C734F42891E; Thu, 23 Jul 2015 11:10:00 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-112-79.ams2.redhat.com [10.36.112.79]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NB9uue029323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 07:09:59 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 23 Jul 2015 13:09:49 +0200
Message-ID: <1724827.ajpDBsKllU@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <201507221610.27729.davemgarrett@gmail.com>
References: <201507221610.27729.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2130764.cYrfbPgWRb"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/XJMNl5o0gcp_RYVEY5nwsxGhlHg>
Subject: Re: [TLS] A la carte concerns from IETF 93
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 11:10:02 -0000
On Wednesday 22 July 2015 16:10:27 Dave Garrett wrote: > Consensus was my current WIP proposal is not viable, for some of the > following main reasons: > > 1) cost/benefit analysis doesn't seem to be worth it > 2) backwards compatibility handling > 3) some argue harder to implement; others argue easier > > cost: > - change has risks of mistake at various points (implementation, deployment, > admin, client config, etc.) and server/client config is a huge cost vast swaths of web servers are misconfigured; introducing a more complex mechanism to server configuration when the existing situation is incomprehensible to many administrators won't help (and even many people that write the various blog posts about "how to configure SSL [sic] in httpd" clearly haven't read openssl ciphers(1) man page) any changes like this will require new APIs for configuration, that in turn means that not only libraries will need to be modified to add support for TLS1.3 configuration but applications too - that will slow adoption -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- [TLS] A la carte concerns from IETF 93 Dave Garrett
- Re: [TLS] A la carte concerns from IETF 93 Hubert Kario
- Re: [TLS] A la carte concerns from IETF 93 Ilari Liusvaara
- [TLS] ban more old crap (was: A la carte concerns… Dave Garrett
- Re: [TLS] ban more old crap (was: A la carte conc… Viktor Dukhovni
- Re: [TLS] ban more old crap (was: A la carte conc… Dave Garrett
- Re: [TLS] ban more old crap Stephen Farrell
- Re: [TLS] ban more old crap (was: A la carte conc… Yuhong Bao
- Re: [TLS] ban more old crap Eric Rescorla
- Re: [TLS] ban more old crap Hubert Kario
- Re: [TLS] ban more old crap (was: A la carte conc… Hubert Kario
- Re: [TLS] ban more old crap Dave Garrett
- Re: [TLS] ban more old crap Ilari Liusvaara
- Re: [TLS] ban more old crap Hubert Kario
- Re: [TLS] ban more old crap Dave Garrett
- Re: [TLS] ban more old crap Hubert Kario
- Re: [TLS] ban more old crap Dave Garrett
- Re: [TLS] ban more old crap Yuhong Bao
- Re: [TLS] ban more old crap Ilari Liusvaara
- Re: [TLS] ban more old crap Viktor Dukhovni
- Re: [TLS] ban more old crap Salz, Rich
- Re: [TLS] ban more old crap Stephen Farrell
- Re: [TLS] ban more old crap Benjamin Beurdouche
- Re: [TLS] ban more old crap Eric Rescorla
- Re: [TLS] ban more old crap Martin Thomson
- Re: [TLS] ban more old crap Salz, Rich
- Re: [TLS] ban more old crap Martin Thomson
- Re: [TLS] ban more old crap Viktor Dukhovni
- Re: [TLS] ban more old crap Viktor Dukhovni
- Re: [TLS] ban more old crap Dave Garrett
- Re: [TLS] ban more old crap Viktor Dukhovni