Re: [Trans] Question regarding new gossip protocols [Was: Certificate transparency on blockchains]

Dmitry Belyavsky <beldmit@gmail.com> Fri, 27 March 2015 18:46 UTC

Return-Path: <beldmit@gmail.com>
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 A32551A8838 for <trans@ietfa.amsl.com>; Fri, 27 Mar 2015 11:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 x47ZUleo0ZAf for <trans@ietfa.amsl.com>; Fri, 27 Mar 2015 11:46:39 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25D51A1B63 for <trans@ietf.org>; Fri, 27 Mar 2015 11:46:38 -0700 (PDT)
Received: by lboc7 with SMTP id c7so13149715lbo.1 for <trans@ietf.org>; Fri, 27 Mar 2015 11:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zYPVj+TSAHKw3L5xTU4vaMG5CJxGXmylmsv1T5iX9K0=; b=aQV9uqfC49V3peLWVDmS4p0f0nh/zwSy2rvICl6xspOpU8OPl/mVjseGRNYW4IIpM3 iITnCXRvIrzCKgVA746la5q6+vJLrPj8noHUMRIYNxOm43EjP5Ex1oQ7DAsobI8uAUXw z3146vgOgYd1iXQGzj9ajqkBcXN9MSGdFyFWV7b94iMArG1PS8wQqYe8MVMLdINMgG/D /jYgmCpMUe2iL4kKq+7mN1opuRTXnpsY+gtYsWthYcxLCVabOiFQe8LLXpFDB5NuYqAW UO5cmJ7jhCgNB7Iicg33W8mYfT11MetAOQqKL3RuOvAZsb2A6HgcmfKHHApV2bMzmGvL HnyA==
MIME-Version: 1.0
X-Received: by 10.112.9.236 with SMTP id d12mr19426992lbb.102.1427481997085; Fri, 27 Mar 2015 11:46:37 -0700 (PDT)
Received: by 10.25.38.133 with HTTP; Fri, 27 Mar 2015 11:46:37 -0700 (PDT)
In-Reply-To: <BAD439C7-60C8-44D4-89F9-AC6E5613A5EA@taoeffect.com>
References: <007F2B41-C78E-4332-8206-7E4CB27A638B@kinostudios.com> <alpine.LFD.2.10.1503252231110.16175@bofh.nohats.ca> <2A773227-61C8-4196-8AFF-EC288A8AF150@kinostudios.com> <CA+cU71=7G5ZJMx3Vy+gXN00JpB61_6C+DLQRyCS=Hcq3vLR-Sg@mail.gmail.com> <CE157D3A-079C-4B09-B138-C21FD9D1FB03@taoeffect.com> <BAD439C7-60C8-44D4-89F9-AC6E5613A5EA@taoeffect.com>
Date: Fri, 27 Mar 2015 21:46:37 +0300
Message-ID: <CADqLbz+8br-F3CJEgTj8K3HmaGdNKfjCSeDtWrDmySmohhjXkw@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
To: Tao Effect <contact@taoeffect.com>
Content-Type: multipart/alternative; boundary="001a11346dac5c133a0512498d3d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/lVeEFjaDAwGwEvH57T1FTk7mBRY>
Cc: Tom Ritter <tom@ritter.vg>, Paul Wouters <paul@cypherpunks.ca>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Question regarding new gossip protocols [Was: Certificate transparency on blockchains]
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: Fri, 27 Mar 2015 18:46:42 -0000

Hello all,

On Fri, Mar 27, 2015 at 9:43 PM, Tao Effect <contact@taoeffect.com> wrote:

> (Changed the thread's subject title to reduce likelihood this question was
> missed:)
>
> The document does say that clients MUST send the certificate chain back to
> servers, and that's good, because if that's the case, shouldn't that be
> enough on its own for servers to detect that a MITM attack occurred (after
> the MITM leaves)?
>
> If that is so, it seems like a point worth highlighting in the document.
> It would completely address our concerns about CT's ability to detect MITM
> attacks post-facto.
>
>
I suspect that a smart enough attacker will be able to send native
certificates back to server instead of the ones he sent to client. Or am I
missing something?

Thank you!


>
> Thanks,
> Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Mar 27, 2015, at 12:12 AM, Tao Effect <contact@taoeffect.com> wrote:
>
> *(re-sending from the email I use with [trans].)*
>
> Thanks Tom for the very helpful reply.
>
> Thinking this through a bit more, I remember again something that was
> previously discussed about this technique.
>
> The document does say that clients MUST send the certificate chain back to
> servers, and that's good, because if that's the case, shouldn't that be
> enough on its own for servers to detect that a MITM attack occurred (after
> the MITM leaves)?
>
> If that is so, it seems like a point worth highlighting in the document.
> It would completely address our concerns about CT's ability to detect MITM
> attacks post-facto.
>
> Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Mar 26, 2015, at 6:18 PM, Tom Ritter <tom@ritter.vg> wrote:
>
> On 26 March 2015 at 15:45, Greg <greg@kinostudios.com> wrote:
>
> Reading over it, I still have several concerns, which I will voice here but
> let me know if it would be better to also voice them on [trans].
>
>
> It would be better to voice them on trans, which I am copying.  I
> suggest we move it there for follow-ups.
>
>
> In Section 3.1.1, it says:
>
> <begin>
>
> HTTPS servers MUST perform a number of sanity checks on SCTs from
>   clients before storing them:
>
>   1.  if a bit-wise compare of the SCT matches one already in the
>       store, discard
>
>   2.  if the SCT can't be verified to be a valid SCT for the
>       accompanying leaf cert, issued by a known log, discard
>
>   3.  if the leaf cert is not for a domain that the server is
>       authoritative for, discard
>
>   Check number 1 is a pure optimisation.  Check number 2 is to prevent
>   spamming and attacks where an adversary can fill up the store prior
>   to attacking a client.  Check number 3 is to help misbehaving clients
>   from leaking what sites they visit.
>
> </end>
>
> Concern #1: Discarding invalid SCTs
> ============================
>
> It is not clear to me what's going on in (2) above.
>
> Specifically:
>
> - How is the server verifying the SCT for validity?
>
>
>
> It checks if the signature over the data is valid.
>
>
> - Why is the server discarding the SCT if it is invalid?
>
> Wouldn't discarding an invalid SCT totally undermine the point of clients
> sharing them?
>
>
>
> Keeping data for an invalid signature (or a signature for a log which
> I do not recognize and thus don't have the public key) would allow
> clients to store arbitrary data on your server. Complex rate-limiting
> and DoS concerns now apply.
>
>
>
> Concern #2: The use of the word SHOULD
> =================================
>
> The doc states:
>
> (with ref to server => auditor comms):
> <begin>
>
> HTTPS servers SHOULD share all SCTs and certificate data they see
>   that pass the checks above
>
> </end>
>
> <begin>
>
> Auditors SHOULD provide the following URL accepting HTTPS POSTing of
>   SCT feedback data:
>
> </end>
>
> <begin>
>
> Auditors SHOULD regularly poll HTTPS servers at the well-known sct-
>   feedback URL.  How to determine which domains to poll is outside the
>   scope of this document
>
>
> </end>
>
>
> As per RFC2119, "SHOULD" means the advice is free to be ignored after the
> implications are "carefully weighed".
>
> This means that so far the document provides no guarantees that a
> misbehaving log will be caught.
>
>
>
> Yup. We can't force anyone to participate unfortunately.  A client
> _can_ opt-in to using a trusted auditor and send SCTs to them, which
> then mitigates the concerns over a server not participating.  But I
> will note that if a server does not participate they are essentially
> opening themselves to attacks by logs. So they have an incentive to
> participate.
>
>
> It is also disconcerting that instead of taking direct action themselves,
>
>
>
> There is nothing stopping a server from being an auditor and detecting
> log misbehavior.  I suppose we could add a note in the draft to that
> effect, but it's a pretty weighty option I imagine most people will
> not pursue.
>
>
> servers are supposed to initiate yet another HTTPS connection to an
> auditor.
>
>
>
> (nit: Server can instead just make the SCTs available for auditors to
> query and retrieve from them. Server doesn't have to initiate outbound
> requests.)
>
>
> This is cumbersome and will probably leave open holes for a global MITM to
> prevent SCTs from reaching auditors, yet again undermining the entire point
> of sharing SCTs.
>
>
>
> Yes, an attacker who can persistently isolate a client or server from
> the rest of the internet is powerful, and is difficult to defeat. We
> do not defend against such an attacker. I'm open to suggestions here,
> but none really came to me.
>
>
> While it's definitely a positive sign that the sharing of SCTs and
> certificate chains is now an official recommendation, I am concerned that
> the particular implementation is without any teeth to deliver concrete
> results, and so until these concerns are addressed I am not convinced that
> the problem has been fully addressed.
>
>
>
> That's fair.  There are limitations to the draft, to be sure - but
> balancing the very difficult privacy concerns of literally
> broadcasting the websites you've visited is also important.
>
>
> -tom
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>


-- 
SY, Dmitry Belyavsky