Re: [TLS] draft-ietf-tls-tls13-16

mrex@sap.com (Martin Rex) Wed, 28 September 2016 16:28 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A4812B1D8 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 09:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bldczDmiZg8b for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 09:28:16 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FAF12B0FA for <tls@ietf.org>; Wed, 28 Sep 2016 09:28:16 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3skjmt2RKPz1Hj7; Wed, 28 Sep 2016 18:28:14 +0200 (CEST)
X-purgate-ID: 152705::1475080094-00003836-FB763B36/0/0
X-purgate-size: 1150
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3skjms65jGzkqYc; Wed, 28 Sep 2016 18:28:13 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C66D61A558; Wed, 28 Sep 2016 18:28:13 +0200 (CEST)
In-Reply-To: <2e7c0ab005d840ca94a3d887caeb93ae@usma1ex-dag1mb1.msg.corp.akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Wed, 28 Sep 2016 18:28:13 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160928162813.C66D61A558@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Jf5iyvRPq7pkWjXZmiN3mltfW_M>
Cc: Stephen Checkoway <s@pahtak.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls13-16
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 28 Sep 2016 16:28:18 -0000

Salz, Rich wrote:
> > I generally agree, though we just added one small exception to NSS, and
> > have been discussing another for a while now:  Respecting client preference
> > for ChaCha over GCM makes a real difference for clients that don't have AES-
> > NI.
> 
> Yes, a number of net companies do this (Google, CloudFlare, Akamai and no doubt others).  OpenSSL will support something like this in a future release (boringSSL has "equivalence classes" but the syntax and limitations aren't great).
> 
> But it doesn't matter -- it's still the server choosing what to do :)

For all TLS protocol parameters where the client presents a list
and the server selects one element from that list, it is a
server-local (policy) decision which one element it chooses.

Describing the order of elements in such lists as "client preference order" 
has led to numerous bogus server implementations, which erroneously
default to "do what the client proposes", rather than "do what the server
admin has configured".

Out-of-curiosity, is the ChaCha-over-GCM to be configurable for the
server admin, or is it hidden black magic?

-Martin