Re: [Lurk] Cryptoanalysis of KeyLess SSL

Daniel Kahn Gillmor <> Wed, 03 May 2017 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72014129AE3 for <>; Wed, 3 May 2017 09:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6aBug6V9EjiR for <>; Wed, 3 May 2017 09:47:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A75DF129ADF for <>; Wed, 3 May 2017 09:44:59 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 55F9CF98C; Wed, 3 May 2017 12:44:59 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 7B3342061B; Wed, 3 May 2017 12:44:49 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Dmitry Belyavsky <>, LURK BoF <>
In-Reply-To: <>
References: <>
Date: Wed, 03 May 2017 12:44:49 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lurk] Cryptoanalysis of KeyLess SSL
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Limited Use of Remote Keys <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 May 2017 16:47:14 -0000

On Fri 2017-04-28 15:40:31 +0300, Dmitry Belyavsky wrote:


thanks for the link, Dmitry!  And thanks to the authors of the paper for
documenting these gaps in the keyless protocol.

I note that the authors of the paper include the following remarks:

    To fully protect clients’ privacy, we believe that clients should be
    made aware of proxying, so they can decide whether they want a
    faster but less secure connection to a CDN or a slower but more
    secure connection directly to the origin server.

It's not clear to me that such a change would actually provide better
protection of client privacy.  In particular, such an option could be
misused by operators of malicious networks or other would-be MiTM
attackers to force themselves into the channel that would otherwise be
opaque to them.

I hope that proposals like the one above will give thoughtful
consideration to the user experience for common clients.  For example,
what would such a notification look like in a web browser?  What would
be the common experience of the browser user?  What would the user's
likely behavior be?  would such a situation really "fully protect
clients' privacy" or would it provide yet another lever of control that
the network operator can exercise over the endpoints?