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

Nico Williams <> Mon, 10 July 2017 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E7D9131861 for <>; Mon, 10 Jul 2017 12:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001] 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 IuooOTXsx9bg for <>; Mon, 10 Jul 2017 12:03:49 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20F2713187A for <>; Mon, 10 Jul 2017 12:03:49 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 7C035C086D41; Mon, 10 Jul 2017 12:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s=; bh=jfeEGcTENRg2K8fkGetoPNMHsNo=; b=tACSzvQx7Oy px8QMCtyK1Z6zhiLmag4rboDtO99Y2bf7dI2K9kzVXZ2/v0zxHVPuJ60S/QTV93x L6lmNadQ7gZ2wA9rnN0GBVbGkFESLsVNKmjKdw4HkOk/UXxK99YpyjHKST3EAYAA Jd7jmzrUypnVXONe1T2+kI84SOGX7fU4=
Received: from localhost ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id D252AC0028A9; Mon, 10 Jul 2017 12:03:47 -0700 (PDT)
Date: Mon, 10 Jul 2017 14:03:44 -0500
From: Nico Williams <>
To: Yoav Nir <>
Cc: Stephen Farrell <>, "Polk, Tim (Fed)" <>, "" <>
Message-ID: <20170710190343.GA16447@localhost>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Content-Transfer-Encoding: quoted-printable
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:03:51 -0000

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.