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

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 24 March 2015 22:16 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 B751C1A1B29 for <trans@ietfa.amsl.com>; Tue, 24 Mar 2015 15:16:13 -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 bWlyq_2uumMm for <trans@ietfa.amsl.com>; Tue, 24 Mar 2015 15:16:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC391A1A66 for <trans@ietf.org>; Tue, 24 Mar 2015 15:16:10 -0700 (PDT)
X-AuditID: 12074422-f79cb6d000000d7b-b3-5511e229f815
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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.1F.03451.922E1155; Tue, 24 Mar 2015 18:16:09 -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 t2OMG8E1023281; Tue, 24 Mar 2015 18:16:09 -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 t2OMG7uR018587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2015 18:16:08 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2OMG6Ya025751; Tue, 24 Mar 2015 18:16:06 -0400 (EDT)
Date: Tue, 24 Mar 2015 18:16:06 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Linus Nordberg <linus@nordu.net>
In-Reply-To: <87bnjic0fx.fsf@nordberg.se>
Message-ID: <alpine.GSO.1.10.1503241738310.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>
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+NgFnrNIsWRmVeSWpSXmKPExsUixG6noqv5SDDUYMVWbYvt894zWax9fJHF gcljyZKfTB7dF+cwBjBFcdmkpOZklqUW6dslcGU0b5/PVHDVqmLlndAGxvO6XYwcHBICJhKL G/i7GDmBTDGJC/fWs3UxcnEICSxmkrh29iUjSEJIYCOjRN8pa4jEISaJS137oKoaGCXmvl/B DlLFIqAtsfPQJjCbTUBFYuabjWwgtgiQvW7rbCYQm1lASGL5jelgtrCAvcS0tsdgNqeApsTK 2y0sIBfxCjhKtLXUQMz/xijRseQu2ExRAR2J1funsIDYvAKCEidnPmGBmKklsXz6NpYJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZopeaUrqJERymLko7GH8eVDrE KMDBqMTDG7BEIFSINbGsuDL3EKMkB5OSKO+mbYKhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 n7cD5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHjjHwI1ChalpqdW pGXmlCCkmTg4QYbzAA23B6nhLS5IzC3OTIfIn2JUlBLnlQFJCIAkMkrz4HphaeQVozjQK8K8 1x8AVfEAUxBc9yugwUxAg8/l84EMLklESEk1MK72sG/8bNV5SMUpSkxNca+4Toh9eWJAqC5v 0rLQT1W8ynf7Nx0PUGC8Mzuj7Noi+6UCuhF/mKzn/hfKbJ0ttG6NfDCfltuT9xflnvMIunec CXn1fvJ8lcCYizP8ND/pNs1IXryE9cmifxvm77geYMB+wDB+X0wsp5d/06djkzerlWR1vBLi UmIpzkg01GIuKk4EALNz43r+AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/CPVtcGmxpHOuz8rMQFPMin1rpNA>
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: Tue, 24 Mar 2015 22:16:13 -0000

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.



> |
> | """
> | However, there is no loss in privacy if a client sends SCTs for a given
> | site to the site named in the SCT, since the site's access logs would
> | already indicate that the client is accessing that site.  In this way a
> | site can accumulate records of SCTs that have been issued by various logs
> | for that site, providing a consolidated repository of SCTs which can be
> | queried by an auditor interested in that site (such as the site's owner
> | itself).
> | """
>
> Tweaked it a bit and added it (1c45c37) to section Problem, now renamed
> Introduction. Thanks.

Looks good; thanks for the cleanup.

> | > | > In a related vein, in 3.1.2, should the server be allowed to exclude SCTs
> | > | > that it considers legitimate?
> | > |
> | > | This is an optimization: if a server sends you SCTs A,B,C and then you
> | > | as a client report back to it "I know about SCTs A, B, and C - it
> | > | doesn't make a whole lot of sense for a server to report those to the
> | > | auditor.
> | > |
> | > | I suppose; however, that an attacker may feed a server invalid SCTs
> | > | somehow to 'load it's cache' such that it never reports them. So
> | > | perhaps yes, it should report the SCTs it knows about to an auditor.
> | >
> | > I'm thinking of SCT's being legitimate as a "policy decision" made by
> | > the operator and not something a piece of software decides. Does this
> | > make sense? Should we add text to explain this?
> |
> | I guess I'm coming at this from the assumption that an auditor will want
> | to know about all SCTs for a given site, including the "legitimate" ones.
> | On the other hand, it could be useful for the site to have a way to
> | indicate to an external auditor which SCTs it believes are legitimate.
> | But it's not clear that omitting them from the results is the best way to
> | make that indication, since it is not distinguishable from the site not
> | knowing about those SCTs.  In short, is the extra complexity of making
> | this optional justified?
>
> Backing up a bit, the question can be posed as whether the optimisation
> of not sending them all is justified. This is somewhat related to the
> open question of how (push vs. pull) and how often and much auditors and
> web servers gossip. Getting an idea about the quantity of data would
> help. I don't have any numbers at the moment.


Waiting for data seems like a fine plan for now.

I do wonder if there should be an explicit way for an auditor to query
which SCTs are considered "legitimate".


> | > | > I'm also a little confused by the last paragraph of 3.1.2, "the selection
> | > | > MUST NOT be influenced by potential HTTPS clients connecting directly to
> | > | > the auditor".  It seems like the only risk of allowing a client to request
> | > | > monitoring for a given site is additional resource usage by the server
> | > | > (assuming the client is aware of the privacy considerations of making such
> | > | > a request).  I suspect that there is a valid concern here, but the text as
> | > | > written may be overly broad.
> | > |
> | > | It's designed to prevent the following traffic analysis:
> | > |
> | > | - Adversary is watching traffic of the auditor and client, and wants
> | > | to learn historical client behavior
> | > | - Client connects to an auditor and sends a bunch of SCTs over HTTPS
> | > | - Auditor immediately goes and queries all the domains the client sent for
> | > | - Adversary learns which domains the client sent in SCTs for
> | >
> | > Should we add text explaining this? Should explanations like this go
> | > into "Security considerations", refering to appropriate sections (like
> | > 3.1.2. in this particular case)?
> |
> | I think it would be fine to mention this in 4.1.2 (near "SCTs [are]
> | sensitive data").
> |
> | I still think it is possible for a properly-written auditor to add sites
> | to monitor in a way which does not expose client information via traffic
> | analysis (i.e., probabilistic/staggered/delayed queries), but I am willing
> | to conced that getting it right is sufficiently hard that we should not be
> | recommending it.
>
> Could this be what 4.1.2 calls "mixing"? We put that down as "TBD" for
> now.

They are very related issues, and TBD for now is fine.  When the mixing
question comes up again, we might think about auditors starting to monitor
more sites as well.



Hmm, re-reading the document just now I noticed a new issue -- in section
3.1.1 ("HTTPS client to server"), the first enumerated action is not
required for interoperability, so I don't think MUST is appropriate.  (It
is explicitly disclaimed as "a pure optimization".)

-Ben