Re: [TLS] Industry Concerns about TLS 1.3

Sean Turner <> Wed, 12 October 2016 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8479C1295C6 for <>; Tue, 11 Oct 2016 17:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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, 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 fF-I5X_5bTwP for <>; Tue, 11 Oct 2016 17:24:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5F8D1293E1 for <>; Tue, 11 Oct 2016 17:24:53 -0700 (PDT)
Received: by with SMTP id n189so12019312qke.0 for <>; Tue, 11 Oct 2016 17:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3jP2rcUn2BWLuAD9cHFinLTjYATyzswRNVzblXRqOGg=; b=heAQI7cTNLRBPg+Yq17rOcuqIym+MmeTrkta+QwxOuyWIVs8LvEujkYtHueUZW/m1f WxtHv7vVJcd+37tV/Joo75575ti5JpApbPCyBKS4MF2yFfYjRLhvZgItn6ub5/+18+CX wHSW2EG7KxIa/tddBooPUDOMAx6AS5sr8NPTY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3jP2rcUn2BWLuAD9cHFinLTjYATyzswRNVzblXRqOGg=; b=RcZsErKxjn27YAKm8mREL91yKLFBo33OsW0TlcG5uY4vGGkrEbMN9vEKViepKZ+bv0 mZflpElpig5ELrjpNVTx8ezwv1UxvnYMl0p7fz9gxQDNXGTm2m/IByeuHb1SRdtj2Vew 8+wcz4ev+a8XhnypXw6bEVnNjb97VOik56ssvrTMqhy7IPzypmrtbjgq53a3a7v6nheJ W2Fd6Splzr3G4JqezYL8Qn+AfOdP4btJ2ZYON8uDzq2F7mUhpVpKSYvewkBCLr567GoQ /tIXbB1EFjONfbM+5vHD+yAnEzd12Gxbe+uKtAbX3UKPRRjsSRJJmMdOPjFWsUWlPCIy YoVg==
X-Gm-Message-State: AA6/9Rm1FWoe/KI3YWr+BrkdCdgfbQvhf2w5VREVKFIlRolYnlEAF2bn+wiHZ6BCPFgxPg==
X-Received: by with SMTP id o22mr5610866qka.136.1476231892775; Tue, 11 Oct 2016 17:24:52 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id l6sm1959842qkd.41.2016. for <> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 17:24:51 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <>
In-Reply-To: <>
Date: Tue, 11 Oct 2016 20:24:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
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, 12 Oct 2016 00:24:56 -0000

As one of the WG chairs, it looks like it’s time to bring to a close whether or not we’ll be re-introducing static RSA key exchange.

One digression before that though: I think there is a realization in the IAB, IESG, and many parts of the IETF that significant operational/management issues exist with encryption; the MaRNEW workshop [0][1][2], some related drafts [3][4], and the PLUS/ACCORD BOFs proposals are just some examples that reflect this.

On dropping static RSA key exchange: The DH-only key exchange proposal had a very lengthy and robust discussion.  PFS was definitely a driver [5], but the simplifying effect of removing static RSA key exchange was another one that should not be forgotten; less options, less code, (hopefully) less coding errors.  It is probably also worth pointing out that the "remove RSA key exchange" shoe has been dropping since 2003: “RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications” [6].

On the one hand, I am sympathetic to concerns about impacts resulting from protocol changes.  On the other hand, the cycle of new protocol version followed by product updates is not really that out of the ordinary; this cycle is disliked by those with budgets but normal nonetheless.  Also, there appears to be a couple of different solutions that would allow an enterprise to do what it wants.  I’m not seeing anything that would alter the consensus that we reached earlier to drop static RSA key exchange from TLS 1.3.



> On Oct 05, 2016, at 15:37, BITS Security <> wrote:
> Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few years back that moved Diffie Hellman to the top cipher suite priorities which broke security and fraud monitoring, APM reporting, and sniffer troubleshooting for a financial services client and at least one other organization in a different industry.  
> The solution, at the time, was to put the PFS options (choices we will no longer in 1.3) at the bottom of the priority list.  I don't know how much of this was communicated back to the vendors at the time.  
> In retrospect, this could have been seen as the canary in the coalmine... but here we are now at least.  
> - Andrew 
> -----Original Message-----
> From: Florian Weimer [] 
> Sent: Wednesday, October 5, 2016 2:17 PM
> To: BITS Security <>
> Cc:
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
> * BITS Security:
>> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
>> problems for financial institutions, almost all of whom are running 
>> TLS internally and have significant, security-critical investments in 
>> out-of-band TLS decryption.
>> Like many enterprises, financial institutions depend upon the ability 
>> to decrypt TLS traffic to implement data loss protection, intrusion 
>> detection and prevention, malware detection, packet capture and 
>> analysis, and DDoS mitigation.
> We should have already seen this with changing defaults in crypto libraries as part of security updates.  That should have broken passive monitoring infrastructure, too.
> Maybe some of the vendors can shed some light on this problem and tell us if they ever have received pushback for rolling out ECDHE-by-default.  (I know that some products have few capabilities for centralized policy management, which is why defaults matter a lot
> there.)
> _______________________________________________
> TLS mailing list