Re: [TLS] chairs - please shutdown wiretapping discussion...

"Blumenthal, Uri - 0553 - MITLL" <> Mon, 10 July 2017 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69DCB131861 for <>; Mon, 10 Jul 2017 12:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u42bLm0f2XYE for <>; Mon, 10 Jul 2017 12:07:27 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id D63AD13187F for <>; Mon, 10 Jul 2017 12:07:25 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id v6AJ7OcJ036449 for <>; Mon, 10 Jul 2017 15:07:24 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "" <>
Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion...
Thread-Index: AQHS+YQIkdUXlkluJUyIYpIPJvLqsqJNXjoAgAAuKACAACIkAP//vfeA
Date: Mon, 10 Jul 2017 19:07:23 +0000
Message-ID: <>
References: <> <> <> <20170710190343.GA16447@localhost>
In-Reply-To: <20170710190343.GA16447@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3582544043_2080085662"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-10_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707100333
Archived-At: <>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
X-Mailman-Version: 2.1.22
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: Mon, 10 Jul 2017 19:07:32 -0000

My $0.02: absolutely not on the Standards Track (for reasons already expressed by others), might be discussable if Informational.

Uri Blumenthal

On 7/10/17, 15:03, "TLS on behalf of Nico Williams" < on behalf of>; wrote:

    On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote:
    > > On 10 Jul 2017, at 17:16, Stephen Farrell <>; wrote:
    > >> 2.  this proposal offers
    > >> significantly better security properties than current practice
    > >> (central distribution of static RSA keys)
    > > 
    > > I fail to see any relevant difference in security properties
    > > between those two, never mind a significant improvement.
    > I can see one way in which it is worse.
    > With static RSA keys, you can configure the server to use only PFS
    > ciphesuites (ECDHE-RSA or DHE-RSA). If you want to enable the non-FS,
    > you need to switch to RSA ciphersuites, and that would be obvious to
    > any client.  In fact, I think today a server would stick out if it
    > only supported RSA ciphersuites.
    > There is no way to know that a server is doing what it says in the
    > draft. It’s completely opaque to the client.
    > However, in both cases the server does get FS. As long as the server
    > has not enabled RSA ciphersuites or exportable private key shares, any
    > recorded TLS stream is safe even if the attacker later gets the
    > private key.
    Well, a client could observe reuse of server ECDHE public keys...
    And servers can always share session keys with an auditing system.
    There's no way a client could detect this.
    I don't think we need to have the client KNOW what the server is doing
    because... how the heck can the server prove it's not publishing the
    client's secrets??  The server simply cannot prove that it is adhering
    to any privacy policy.
    Brief reuse of server ECDHE public keys is an optimization.  I _think_
    it's a safe optimization, and it's safer the shorter the reuse period is
    -- and correspondingly less safe the longer the reuse period.
    But I would prefer that anyone wanting auditability just build that into
    their implementations as a proper audit capability.  Yes, it's more
    complex to later decrypt sessions, but it also doesn't mess with the
    protocol in any way.
    That said, I wouldn't object to the proposal if it meant to be
    Informational.  I don't see how a document that describes a possible a
    configuration (not protocol!) that is not relevant to the Internet
    should be a Standards-Track RFC, or BCP for that matter.  Informational
    will do.
    TLS mailing list