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
>