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
- Re: [Trans] [Cryptography] Certificate transparen… Tom Ritter
- Re: [Trans] [Cryptography] Certificate transparen… Tao Effect
- [Trans] Question regarding new gossip protocols [… Tao Effect
- Re: [Trans] Question regarding new gossip protoco… Dmitry Belyavsky
- Re: [Trans] Question regarding new gossip protoco… Paul Wouters
- Re: [Trans] Question regarding new gossip protoco… Tao Effect
- Re: [Trans] Question regarding new gossip protoco… paul
- Re: [Trans] Question regarding new gossip protoco… Tao Effect
- Re: [Trans] Question regarding new gossip protoco… Tao Effect
- Re: [Trans] Question regarding new gossip protoco… Tom Ritter