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