Re: [Lurk] Cryptoanalysis of KeyLess SSL

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 03 May 2017 16:47 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72014129AE3 for <lurk@ietfa.amsl.com>; Wed, 3 May 2017 09:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aBug6V9EjiR for <lurk@ietfa.amsl.com>; Wed, 3 May 2017 09:47:12 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id A75DF129ADF for <lurk@ietf.org>; Wed, 3 May 2017 09:44:59 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 55F9CF98C; Wed, 3 May 2017 12:44:59 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 7B3342061B; Wed, 3 May 2017 12:44:49 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Dmitry Belyavsky <beldmit@gmail.com>, LURK BoF <lurk@ietf.org>
In-Reply-To: <CADqLbzKCWg5VgEd=c0dAEdh4rGuAu-4V-2kuBdC86ZvapMnJhQ@mail.gmail.com>
References: <CADqLbzKCWg5VgEd=c0dAEdh4rGuAu-4V-2kuBdC86ZvapMnJhQ@mail.gmail.com>
Date: Wed, 03 May 2017 12:44:49 -0400
Message-ID: <87y3udrita.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/pJPreJWyoqFW9zXNCCnPgi1hc1I>
Subject: Re: [Lurk] Cryptoanalysis of KeyLess SSL
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=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:

> http://epubs.surrey.ac.uk/813643/1/mainKeyless.pdf

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?

   --dkg