Re: [TLS] Industry Concerns about TLS 1.3

Dave Garrett <> Thu, 22 September 2016 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A949712B852 for <>; Thu, 22 Sep 2016 12:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MU0SHdCGwdAe for <>; Thu, 22 Sep 2016 12:29:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1414F12B3FD for <>; Thu, 22 Sep 2016 12:29:45 -0700 (PDT)
Received: by with SMTP id t7so86351286qkh.2 for <>; Thu, 22 Sep 2016 12:29:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=hPcuabvlOqWsG3z/GQ4F5mKqYGMqRUTnAzY92vbK7n4=; b=0PUbSS67qOWVdw3Ms6FDf16lhH2oLBurSTf4/K4u6deFDkfwdMmKBqAF/mHEuJ3XaS 4DgqSKbfCHFiPconwgGPuSUVgNB0RXRJ5kMoUUhQp/lzFAIW6EiFstSvuoAtyo4OKTdS 2KYAJJJpwcxGodivACwV2YZorHTrIylFvYeCXLkvesXdJ4oC5/Q8F6Scgj+PbRfo3ZCr 2zGsxaOfW8myMKPKc+mmvc8g7oxVnxtqFWgvDjyLRylkYU57i20Aw93vfvr/kjFKaS2h 2/sreeEKpnh0QUXJ9sMawQR/iNTN07JVXI5znA/ralGdKEb6PpU5a55ZvUQ3L4xr8p4X VSdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=hPcuabvlOqWsG3z/GQ4F5mKqYGMqRUTnAzY92vbK7n4=; b=Gvc3EYgSC/2v1QeSUaOVSkiHa5RM+3+K8ODNrSu+Qu8CF7LEx58FiWOzirTqswGS6r GYLol82Z9agf2IqG26s2SCrU0dmAPHzyr6Y8VVet3zZwjDvF/ffNhb9BBePkxqMeJ4VT NajfevoKhD90pB47fkP/i1Hft6HldqAsTXzdlXTWjn74RDLDJoF2kh969nBTTQ3DN/ES Exbj6JjxfdKNH0ZsWVqEBV3hCyJ1HtvO2PPxTtJHZ4n9RkirFd+B31L3Ss29t45SpqAv mv4qan1F2U/o0cR3rMBwkc1xRIlXaqYFyn6i4PQWdUvNHwtCzJ2PE+wRPAscKjQTePTI NV8g==
X-Gm-Message-State: AA6/9Rl63TprLNi0agMuV6WBfLN2Itq9k8LsqZzNKxmUgdMq8uukw3t0v86sOOrXxn0RkQ==
X-Received: by with SMTP id w9mr3688677qkw.147.1474572584201; Thu, 22 Sep 2016 12:29:44 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id c44sm1744739qta.49.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 22 Sep 2016 12:29:43 -0700 (PDT)
From: Dave Garrett <>
To:, BITS Security <>
Date: Thu, 22 Sep 2016 15:29:42 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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: Thu, 22 Sep 2016 19:29:47 -0000

Mandating forward secrecy for TLS 1.3+ has been a strong consensus of this working group, so there's no point in myself or any other contributors just mass-replying with a big "no" here. That said, there is one puzzling thing I'm curious about:

On Thursday, September 22, 2016 01:19:48 pm BITS Security wrote:
> The impact on supervision will be particularly severe.  Financial institutions are required by law to store communications of certain employees (including broker/dealers) in a form that ensures that they can be retrieved and read in case an investigation into improper behavior is initiated.  The regulations which require retention of supervised employee communications initially focused on physical and electronic mail, but now extend to many other forms of communication including instant message, social media, and collaboration applications.  All of these communications channels are protected using TLS.

Yes, all of these other channels are protected using TLS... which you do not control in any way. Also, many sites/services already prioritize FS cipher suites, so the deprecation of plain RSA key exchange doesn't actually affect the vast majority of people. (e.g. Facebook & Twitter both prefer ECDHE with NIST P-256) Within this very argument is already the argument that supervision at endpoints is required here. The security on the pipe is irrelevant. I don't see how you can make a point to bring this up but think keeping plain RSA KE suites is a useful solution.