Re: [dispatch] [Secdispatch] A protocol for anonymity
Eric Rescorla <ekr@rtfm.com> Thu, 14 March 2019 03:09 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCEC13125D for <dispatch@ietfa.amsl.com>; Wed, 13 Mar 2019 20:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 hGza4Cd8qETs for <dispatch@ietfa.amsl.com>; Wed, 13 Mar 2019 20:09:30 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 029AA13125A for <dispatch@ietf.org>; Wed, 13 Mar 2019 20:09:30 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id a132so1618459lfa.13 for <dispatch@ietf.org>; Wed, 13 Mar 2019 20:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G6hrZ27yDxk2g+3UKtAiEYBCbbfmcq2stButHD90+W4=; b=EA1rJXU72pcyVJc1z/hZD7hPsVf0u4duVbJKxS4Q6khST2o/KsE+uIVUEACrxCDO6f a6K9U4zzi94oLjQFb6yv5kuRXVdj7cD2jO6Fbio2rBfmy+mljmvfo0Ya4m2/OAOFoMMX LjOaoLWfa5l9SqHRuk/ycK0h75nEOWdz7PICONXNUz1w53Uu8oGNI0PxDAuCUJ/7eSiw TGC6N7kbQkRaEXjfGAeEz+4VLExrrPkehnH4Q8jMtZs527PB5jAh6vPPTJq3FZrdu4aT s9QpZ1PDHZ8sDMbAXaEMLCdCY8xSVqwZCIQypQ6rzCJML1E1IhixjCbcJb4foyX52wTO ty7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G6hrZ27yDxk2g+3UKtAiEYBCbbfmcq2stButHD90+W4=; b=dIfyg4TEEzvKQO/uPQ/BOWx5ozAGqN8w7j4R3sp3BGa3JS/BdStrVxF8xL5xLO3La0 ThdsxYXGJI4U0uP4Crlt5F3LPaNmHCvQaYqOMbR/nihZlxkARTqhGWmFkXIwCBaKc0ae Lvlp93HR2ufvmI4ak0eypsmRrsu/4sFgPCAi4S0DE52iH4TvB/b1UosoZH9183KYV3ce yMHiyj/QsYDyr1ehEzG5liTT5CljnRazJ3ui5atUXyRGld+KG2QCJV4s7arFtuSmp7Io ciigCPlUuf6g8aAi/b7U/EJlz9OZybB8ZbWBW8oDr/farFBC45mVYr/EWVVAEEcfTmgv Lssg==
X-Gm-Message-State: APjAAAWRDP/bSYFOqFq/u+2nAO9zqqKV5CkcHUJf3hH3Lpw6GIfXkY/f BmzdpcIu4SwUcigLgsrjJZbWtTOLq+NpF9FIJPhk4A==
X-Google-Smtp-Source: APXvYqynk4GV7i+cTLmt4QGZJdZyxog8yBu3I+j6F6sIUb1YIwIQDQLBV4ym39DhkZHCrvRcEVtOGAuUolJ2qkoWzMg=
X-Received: by 2002:ac2:4191:: with SMTP id z17mr26217505lfh.78.1552532967995; Wed, 13 Mar 2019 20:09:27 -0700 (PDT)
MIME-Version: 1.0
References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <F7BDADFC-FBEF-4049-945B-BD865AB58229@akamai.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> <CALaySJK7rrzFCs-spcUV2YvEkKNUoPNSVn0jSv5-5eEaGjTuMQ@mail.gmail.com> <2512b74994985f18b6967c4cef8e41ed.squirrel@www.amsl.com> <bf0d4ad4-44a2-4691-9d01-0501dee1d131@www.fastmail.com>
In-Reply-To: <bf0d4ad4-44a2-4691-9d01-0501dee1d131@www.fastmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 13 Mar 2019 20:08:50 -0700
Message-ID: <CABcZeBOjP3BHEGWEeBTQNCKNWGYj6cuA3e84=dF_DDuX7n4hZQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f4ef70584054061"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/6Hy-9cLqm-gq44cG4RX9wP5fu_Q>
Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 03:09:33 -0000
On Wed, Mar 13, 2019 at 8:07 PM Martin Thomson <mt@lowentropy.net> wrote: > The challenging thing with a proposal that is as broad as this is finding > a home. There are, to varying degrees, lots of different pieces to this > design. Without going into the design in more detail, I see both > cryptographic and transport elements. Both of which are similar in the > abstract to existing work in the IETF, but entirely dissimilar in form. A > dispatch group is likely the best target for this, but even then it is > likely to contain elements for multiple areas (there's a whole section on > routing that I think is probably not routing in the sense that it would fit > in RTG, but it's still an entirely separate part of the design; there is > also a section on accounting that might or might not be suitable for OPS). > > That alone isn't information you could use to decide anything here (other > than perhaps the shortcomings of the IETF when it comes to dealing with > cross-area stuff). > > I have some reservations about the lack of context in the proposal. For > instance, the section on accounting launches into mechanisms without > establishing what is being accounted for and to whom. A protocol like this > would also typically require considerable security analysis. > > This looks like a specification at the sort of level that would be > appropriate for a BoF or dispatch session. If there was significant > interest in this, then I would expect to see - over time - those details > filled in. Using the dispatch process is probably right, and either would > be fine. > This all seems right, but I think the first question we would need to ask is "who is planning to implement this"? -Ekr > On Tue, Mar 12, 2019, at 21:43, RFC ISE (Adrian Farrel) wrote: > > Thanks Barry, > > > > Useful comments. > > > > To be clear on the ISE position, here... > > > > If there is a home for this work in the IETF (or possibly the IRTF), I > > would be delighted to see the work moved there, discussed, updated, and > > published with IETF consensus. That is, in fact, the purpose of this > > thread. > > > > Although it may be late for a presentation in Prague, I believe that the > > corridors in the Hilton will be fully functional, and that the mailing > > lists run 24x7 so we should at least be able to get an idea of whether > > there is support to look at this in the IETF. (I am getting a strong hint > > that that is the case, but as yet no firm commitment from a WG chair that > > their mailing list is the place to focus the conversation.) > > > > Thanks, > > Adrian > > > > Barry Leiba wrote: > > > I would feel better about this if it were done as an Experimental RFC > > > in the IETF stream, ideally through an ART/SEC working group, as it's > > > too much to be AD-sponsored. As such, it should go through > > > secdispatch or dispatch, and it's a bit late to do that for Prague. > > > > > > I'd be hesitant to actually *block* it from the Independent stream > > > (more specifically, asking the ISE not to publish it because it needs > > > IETF review), but I'd rather see it in the IETF stream. I also don't > > > know the history here, as I'm just stepping in as AD now, so perhaps > > > the issue of doing it in the IETF stream has already been hashed out. > > > If so, please clue me in. > > > > > > Barry > > > > > > On Tue, Mar 12, 2019 at 3:19 PM Martin <martin@gwerder.net> wrote: > > >> > > >> Hi Rich > > >> > > >> This is a valid point. Requested status is experimental. This allows > > >> going for a standard later. So the primary goal is to become a > standard > > >> on the long term and to expose the protocol to a broader public. In my > > >> eyes, for the standard, it would require that we have two seconding > > >> documents — one dealing with best current practices and one focusing > > >> security considerations (maybe both in one document). The main problem > > >> with those two documents is not the protocol itself. As SMTP or HTTP > in > > >> its pure form, this is a transport protocol only. It does not deal > with > > >> the client side or the content itself. > > >> > > >> Anonymity is broken easily by the users themselves. As an example, you > > >> may take the fact that almost no user is ready to write emails in > plain > > >> text. They want to embed graphics and emoticons. Allowing HTML > encoding > > >> on the other side makes the protocol vulnerable to bugging attacks. At > > >> the moment I am using Thunderbird as the client and the MessageVortex > > >> node as "local mail server." While this makes sense from the user > > >> perspective (no new client), it is maybe not the wisest decision from > an > > >> anonymity perspective. This, however, is not a problem of the > protocol. > > >> MessageVortex allows transferring any message and is not limited to > > >> emails. These possibilities should be further explored. > > >> > > >> At least for my person, this protocol opens a whole new world full of > > >> possibilities. So I am very keen to see what it can do. > > >> > > >> Regards > > >> Martin > > >> > > >> > > >> Am 11.03.2019 um 15:31 schrieb Salz, Rich: > > >> > I would turn this around: why does this have to be an RFC? > > >> > > > > > > > > > > > > > -- > > Adrian Farrel (ISE), > > rfc-ise@rfc-editor.org > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >
- [dispatch] A protocol for anonymity RFC ISE (Adrian Farrel)
- Re: [dispatch] A protocol for anonymity Hernâni Marques (p≡p project)
- Re: [dispatch] [Secdispatch] A protocol for anony… Stephen Farrell
- Re: [dispatch] [Secdispatch] A protocol for anony… Salz, Rich
- Re: [dispatch] [Secdispatch] A protocol for anony… Martin
- Re: [dispatch] [Secdispatch] A protocol for anony… Salz, Rich
- Re: [dispatch] [Secdispatch] A protocol for anony… Martin
- Re: [dispatch] [Secdispatch] A protocol for anony… Barry Leiba
- Re: [dispatch] [Secdispatch] A protocol for anony… Eric Burger
- Re: [dispatch] [Secdispatch] A protocol for anony… RFC ISE (Adrian Farrel)
- Re: [dispatch] [Secdispatch] A protocol for anony… Martin Thomson
- Re: [dispatch] [Secdispatch] A protocol for anony… Eric Rescorla