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

"Salz, Rich" <> Wed, 28 September 2016 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E66F12B1FA for <>; Wed, 28 Sep 2016 09:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.017
X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DEx8FmWN-ht8 for <>; Wed, 28 Sep 2016 09:37:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C405C12B1EE for <>; Wed, 28 Sep 2016 09:37:06 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id 20FF7423705; Wed, 28 Sep 2016 16:37:06 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 0AF28423701; Wed, 28 Sep 2016 16:37:06 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1475080626; bh=tgdmzj2xzbWwcSPAzexobYYNkqZnOmAgqrvmffJq4zc=; l=1209; h=From:To:CC:Date:References:In-Reply-To:From; b=EDGcXq/r0od3L/3to/g5haoY1zaP0R1Q223/ZBtZVEHFqyj2mVE5tUlwWaFfGztqr vnA9dT6Aq+Y9sUQKvadgdDxjKvrTFrqH1ybH7p+n0vciAOoqYWl8eEHreHxh+/tqxz AlxyQaE2QJYiOjpHHAOtUMs8ZhluSjKG6IBaBAd0=
Received: from ( []) by (Postfix) with ESMTP id 060F61FC86; Wed, 28 Sep 2016 16:37:06 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 28 Sep 2016 12:37:05 -0400
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Wed, 28 Sep 2016 12:37:05 -0400
From: "Salz, Rich" <>
To: "" <>
Thread-Topic: [TLS] draft-ietf-tls-tls13-16
Thread-Index: AQHSFSsTmqD6Mi0JokSpim9DtXhY6qCPXC8AgAABjgD//71KAIAASE6A//+9fRA=
Date: Wed, 28 Sep 2016 16:37:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-ietf-tls-tls13-16
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2016 16:37:08 -0000

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

On the server-side, I think most of them work the same way:  if the client puts ChaCha at the start of its list, and the server is configured with ChaCha as one of its ciphers, then the server "moves" Chacha to the front of its list and proceeds as normal.  I think the CloudFlare patches just implemented that policy in code, based on patches they posted. I'm not going to say how Akamai did it except that no animal sacrifice is involved. I don't know how Google did it, but see next paragraph.

On the crypto-library side, boringSSL had equivalence classes so you could specify that by configuring the CIPHER list. If running in a server, and the configured ciphers were like "[AES:CHACHA]:3DES:RC4" for example, then either AES or ChaCha would be picked.  I don't know if Google servers use that, but I'd be a bit surprised if they didn't.

As for OpenSSL, we need to figure out something.  The "ciphers" syntax is showing its age.

Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: Twitter: RichSalz