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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sun, 08 December 2013 22:00 UTC

Return-Path: <hannes.tschofenig@gmx.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 569E31AE121 for <perpass@ietfa.amsl.com>; Sun, 8 Dec 2013 14:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Dc3vfvOa2UcJ for <perpass@ietfa.amsl.com>; Sun, 8 Dec 2013 14:00:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1F81AE120 for <perpass@ietf.org>; Sun, 8 Dec 2013 14:00:30 -0800 (PST)
Received: from [192.168.10.137] ([2.102.217.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MU0U9-1VykWn0J8b-00QkyU for <perpass@ietf.org>; Sun, 08 Dec 2013 23:00:24 +0100
Message-ID: <52A4EBF3.4000001@gmx.net>
Date: Sun, 08 Dec 2013 22:00:19 +0000
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> <52A4DB71.8040806@cs.tcd.ie>
In-Reply-To: <52A4DB71.8040806@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------060909000101040809060802"
X-Provags-ID: V03:K0:+CHYQpTXgAnsIk1kWY35/3IIrSKYSbP2BWxWdEyv1Dw6lxkMlih JPfJGVpFXIgZi/oZzyrhIk1wvHJag4Da/mTC0FJPWn36AyaDVPinYWQ1rvB1Wm5iBEp8Yzz rNeL0w0j18xRPC9uhn3bXaCGjqzAccMhQfv9bDxxVcIJyf5wZqeVnyWTnHTG78g2Sf4Evnj 2hn2do+i/N8qA54NoWXjA==
Cc: perpass <perpass@ietf.org>
Subject: Re: [perpass] Fwd: Re: perens-perpass-appropriate-response-01
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Sun, 08 Dec 2013 22:00:32 -0000

Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us
why the group at that time decided to develop a NULL encryption
mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have
no heard

In context of our discussion on this list the answer will give us a lot
of guidance for the future.  Even 2 years ago I had lots of people
arguing in the OAuth working group that authentication and integrity
protection is sufficient and that we do not need confidentiality
protection. So, I wouldn't be surprised if the same argument showed up
10 years earlier.

We have to look forward, with our knowledge of the changed threat
landscape, so that we make better design choices in ongoing and future
IETF work.

Ciao
Hannes

 
On 12/08/2013 08:49 PM, Stephen Farrell wrote:
>
>
> On 12/08/2013 03:55 PM, Nicholas Weaver wrote:
>
> > On Dec 7, 2013, at 4:09 PM, Bruce Perens <bruce@perens.com> wrote:
> >> Well, we do have some HTTP uses where encryption that hides the
> >> content won't be allowed, and thus authentication is important.
> >>
> >> We can't have encryption when we use HTTP over Amateur Radio in
> >> the US and many other countries. There is self-policing on ham
> >> frequencies that requires that people be able to copy other
> >> people's transmissions, and encryption defeats that. Obviously
> >> we don't put confidential data on those frequencies, that belongs
> >> on your cell phone. So, an authentication-only WiFi protocol is
> >> needed for Amateur Radio, and possibly an authentication-only
> >> version of TLS.
>
> > NO!!!!
>
> > The reason is downgrade attacks.  A huge problem with the IPSec
> > standard is that NULL encryption was allowed in there, and also
> > known weak modes (single DES, 720b D/H etc).  Its one of the
> > primary reasons why John Gilmore and therefore others feel the
> > IPSec process was sabotaged by the NSA.
>
> Really? That makes no sense to me. I've never heard any report of a
> use of IPsec that "accidentally" used a NULL or weak cipher. Have
> you? And Jeff Schiller I think convincingly repudiated claims that
> either the development process for IPsec or the output were
> saobtaged in any such way.
>
> I wasn't much involved myself but my impression was that we (the
> IETF security community) shot ourselves in the foot a bit via
> complexity and various refusals to prioritise progress and
> deployment over purity.
>
> We need to carefully balance security and pragmatism here IMO if
> our goal is to make for a more secure and privacy friendly Internet.
>
> I also think that throwing "sabotage" into the mix damages that
> discussion so should be avoided.
>
> S.
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass