Re: [Trans] comments on draft-linus-trans-gossip-ct-01

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 25 March 2015 04:17 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA81ACD86 for <trans@ietfa.amsl.com>; Tue, 24 Mar 2015 21:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level:
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Bqma-2FVOofv for <trans@ietfa.amsl.com>; Tue, 24 Mar 2015 21:17:31 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40EF1ACD7B for <trans@ietf.org>; Tue, 24 Mar 2015 21:17:30 -0700 (PDT)
X-AuditID: 1209190c-f792b6d000000d1f-ae-551236d987ef
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 46.D3.03359.9D632155; Wed, 25 Mar 2015 00:17:29 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t2P4HST2017615; Wed, 25 Mar 2015 00:17:29 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2P4HR6K010586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2015 00:17:28 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2P4HQlP011019; Wed, 25 Mar 2015 00:17:26 -0400 (EDT)
Date: Wed, 25 Mar 2015 00:17:26 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Linus Nordberg <linus@nordu.net>
In-Reply-To: <alpine.GSO.1.10.1503241738310.22210@multics.mit.edu>
Message-ID: <alpine.GSO.1.10.1503250013100.22210@multics.mit.edu>
References: <alpine.GSO.1.10.1503222238550.22210@multics.mit.edu> <CA+cU71nN3f7TSoda_DOUzt5YVDzOmyLVhu8f9bR9hg42QNCLkw@mail.gmail.com> <87fv8wge7h.fsf@nordberg.se> <alpine.GSO.1.10.1503231043340.22210@multics.mit.edu> <87bnjic0fx.fsf@nordberg.se> <alpine.GSO.1.10.1503241738310.22210@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nonvTTCjUYN1ZDYvt894zWax9fJHF gcljyZKfTB7dF+cwBjBFcdmkpOZklqUW6dslcGW0rznMXrBNuuLYktnMDYzrRLsYOTkkBEwk 7s+4xghhi0lcuLeerYuRi0NIYDGTxPsrrewQzkZGiW8dt1kgnENMEo87NkE5DYwSq/89Zu1i 5OBgEdCWuPirEGQUm4CKxMw3G9lAbBEge93W2UwgNrOAkMTyG9PBbGEBe4lpbY+ZQFo5BZwk Zu/XAQnzCjhKLH/ZxwQxfh2TxO8ZR9lBEqICOhKr909hgSgSlDg58wkLxEwtieXTt7FMYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjKBQ5ZTk2cH45qDS IUYBDkYlHl4PEaFQIdbEsuLK3EOMkhxMSqK8J9SBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 DSSAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErx7TYEaBYtS01Mr 0jJzShDSTBycIMN5gIb7gtTwFhck5hZnpkPkTzHqcvSdaVzMJMSSl5+XKiXO2wFSJABSlFGa BzcHlmJeMYoDvSXMOwekigeYnuAmvQJawgS05Fw+H8iSkkSElFQDY3/aXh3njZuCOZnXcrUe reZ29hSfIpphH2N/97p+QNOfT+92R7EGZy59a8wjsWZr/YNvAfEVmjNit1T8iW0Oj3vf8sv1 a+b3vy6sehrCssWZ9xTC5tZsD2K6cWez7vpvYkpdKiYmMuV7+Jwd4+PsmP48ORWn7JbY8G1B x4Mdlb2TE5e9WDNXiaU4I9FQi7moOBEAzP660wwDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/au4aWyFwMiWx3Q2BV5pNBQzwCeY>
Cc: trans@ietf.org
Subject: Re: [Trans] comments on draft-linus-trans-gossip-ct-01
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 04:17:33 -0000

On Tue, 24 Mar 2015, Benjamin Kaduk wrote:

> On Tue, 24 Mar 2015, Linus Nordberg wrote:
>
> > Benjamin Kaduk <kaduk@MIT.EDU> wrote
> > Mon, 23 Mar 2015 11:50:26 -0400 (EDT):
> >
> > | On Mon, 23 Mar 2015, Linus Nordberg wrote:
> > |
> > | > Tom Ritter <tom@ritter.vg> wrote
> > | > Sun, 22 Mar 2015 22:38:48 -0500:
> > | >
> > | > | > I'm not
> > | > | > sure that the client wants to always trust the server, given that the
> > | > | > scheme is positing a universe where some clients will sometimes
> > | > | > successfully connect to hostile servers supplied with fraudulent
> > | > | > certificates (that validate) by the attacker.
> > | > |
> > | > | The client is trusting that it will eventually connect to a behaving
> > | > | server and that a server is interested in detecting mis-issuance for
> > | > | itself. Another way to phrase it is that a client is not cordoned off
> > | > | for a given server once and forever, with no way to ever connect to
> > | > | the valid server again
> > |
> > | I know that, and you know that, but we want to make sure that the document
> > | says that as well.  Linus's suggestion below is a good start.
> > |
> > | But this is still not really addressing the issue I was trying to raise.
> > | Yes, the goal of this protocol is to enable a client and server to
> > | cooperate to detect misbehavior by third parties.  But that does not
> > | absolve us of a responsibility to analyze the situation where one of the
> > | client and/or server misbehaves, and document the security and privacy
> > | considerations in that case.
> >
> > Do you have suggested text?
>
> Any text I would suggest would be text that I am not entirely happy with,
> since I do not have confidence that I correctly understand the security
> and privacy considerations in question.
>
> Unfortunately, I left the copy of the document that I marked up at the
> hotel, so I have to recreate my work and only remember one of the places
> that tickled this concern (there were at least two):
>
> In section 3.1.1, """When the client later reconnects to any HTTPS server
> for the same domain it again receives a set of SCTs.  The client [...]
> MUST send to the server the ones in its store that were not received from
> that server."""  This precludes the client from doing any sort of MITM
> detection and refusing to send SCTs to a (presumed) attacker.  Admittedly,
> the scope of exposure here is pretty small; it seems like the only privacy
> loss would be that attacker A who has MITM'd the client then can learn
> whether the client has *also* been MITM'd by attacker B at some point in
> the past (since presumably the attackers know which SCTs are legitimate).
> But, it is not too much of a stretch to think that three-letter
> organizations might want to know if their target is being attacked by
> someone else.

It looks like the other one was in 3.1.2, "HTTPS servers MUST NOT share
any other data that they may learn from the submission of SCTs by HTTP
clients".  My immediate response to that statement was "what goes wrong if
a server misbehaves?"  Thinking about it now, it seems like the answer is
"not very much, compared to a misbehaving server which does not implement
CT", but confirmation would be nice.  Maybe my response to this line of
thought would be to remove the RFC 2119 language and just ensure it's in
the security/privacy considerations, but it's probably not a big deal
either way.

-Ben