Re: [perpass] perens-perpass-appropriate-response-01

Dave Crocker <dhc@dcrocker.net> Fri, 27 December 2013 01:16 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E871AE0CD for <perpass@ietfa.amsl.com>; Thu, 26 Dec 2013 17:16:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 FfbKKWTJDrhj for <perpass@ietfa.amsl.com>; Thu, 26 Dec 2013 17:16:36 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E31AE0CA for <perpass@ietf.org>; Thu, 26 Dec 2013 17:16:35 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBR1GRW8028860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Dec 2013 17:16:30 -0800
Message-ID: <52BCD497.20501@dcrocker.net>
Date: Thu, 26 Dec 2013 17:15:03 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
References: <E2DA1477-C86E-441E-A33D-D47A0D67AFF3@iab.org> <EF9BD1E4-6EF3-4035-AC4E-1A2D3CADE615@mnot.net> <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <BC888A6F-F048-4BA6-92F4-8812753F8534@icsi.berkeley.edu> <52A2235A.2030801@perens.com> <ADD6858C-7548-479E-BB71-316E9C52F812@icsi.berkeley.edu> <c97f3134-eedf-44e1-880c-147efb172fc6@email.android.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu>
In-Reply-To: <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 26 Dec 2013 17:16:30 -0800 (PST)
Cc: perpass@ietf.org
Subject: Re: [perpass] perens-perpass-appropriate-response-01
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Dec 2013 01:16:37 -0000

On 12/7/2013 7:48 AM, Nicholas Weaver wrote:
> So the idea of "authentication problem rather than a confidentiality
> one" is a red herring:  We have a solution that solves the
> authentication problem for HTTP.  Its called TLS.  We MUST use it
> everywhere, if only to protect US citizens from the French and
> Chinese, and Russians, and Brazilians, and Israelis...


Except that it solves only a narrow case of authentication.

It's a hop-by-hop solution and mostly authenticates the server, rather 
than the data the server is feeding the client.  For the data the server 
truly is creating, that's probably ok.  For data it's merely relaying, 
on behalf of the actual author, it's probably not.

So while, yes, authenticating the content is more hassle, it's also more 
meaningful.

And therefore, contrary to Richard's assessment, I think the question of 
widely-used content-based authentication mechanisms is relevant, 
specifically because it demonstrates the viability of actual, end-to-end 
identification, rather than hop-by-hop (and therefore 
within-relay-exposed) channel-based approaches.  The question then is 
not what mechanisms exist, but what mechanisms are actually in 
widespread use.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net