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

Phillip Hallam-Baker <> Sun, 08 December 2013 18:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C64E1AE04D for <>; Sun, 8 Dec 2013 10:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0rzKnZF8r_9h for <>; Sun, 8 Dec 2013 10:51:32 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) by (Postfix) with ESMTP id 224191AE03E for <>; Sun, 8 Dec 2013 10:51:31 -0800 (PST)
Received: by with SMTP id hn9so2864153wib.0 for <>; Sun, 08 Dec 2013 10:51:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=h+bdYGOPJQ+1IuxsMCyE8N4+UT4tsHGKFUr7erFSOJU=; b=De1CjPoVz7FRbHifoNDUJ7GEcQgXSSNSsOH4gM5w/zej0FNryXXkcj73U9w2ofEiGN ZQkoiPgn25j5I/SacdvDVDb2aMjvVdSluv0F0zNAudW/nfIkMMDfpMwrG6UUr3y01itg 4XebFvx1qeIH3O/IS857qDBtAxXGwc1REnSSiLzuav1a4ZJ7npl6mzIN/r0pTIhfwh2e lf9K+UnvAEsOiyx5RmTjU2aYhyPJT2vl93bOnttWCe6iweAqrwuKCK9+Aq4Dzmh4AuR5 CUGs+732qenNAXY870phzQHmW5yMy29CBlxVHhtT1H/pSYeVyXr6k+XlYRc4ttKp4Qup XMqg==
X-Received: by with SMTP id gg16mr10912084wic.32.1386528687178; Sun, 08 Dec 2013 10:51:27 -0800 (PST)
References: <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
From: Phillip Hallam-Baker <>
Date: Sun, 8 Dec 2013 13:51:25 -0500
Message-ID: <-917337036588491953@unknownmsgid>
To: Nicholas Weaver <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: perpass <>, Bruce Perens <>
Subject: Re: [perpass] Fwd: Re: perens-perpass-appropriate-response-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Dec 2013 18:51:34 -0000

This is actually my reason for opposing making http a mandatory

I am fine with the idea of requiring strong TLS

I am fine with the idea of a new mechanism for weakly authenticated http.

But do not weaken TLS so that it can be used as a proxy bypass
strategy without strong crypto

Do it right or write your own. Do not damage the only security
protocol we have so some folk can shave a few msec off latency

Sent from my difference engine

> On Dec 8, 2013, at 10:55 AM, Nicholas Weaver <> wrote:
>> On Dec 7, 2013, at 4:09 PM, Bruce Perens <> 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.
> To explicitly support downgraded, athuentication w/o encryption is STUPID!  it is DANGEROUS!
> About the only thing that is not a horrid idea is to have the key exchange generate a separate MAC and encryption key, using an encrypt then MAC structure.   Yet that loses out on the benefit of authenticated encryption modes that build the MAC into the communication.
> So face it Bruce, your only option should be to have the client leak the session keys keys, and thereby explicitly say "NO SECURITY ON THIS CONNECTION, HAVE A NICE DAY".
> And yes, this means the French can pwn you.  Sorry, use a network that allows encryption.  Or have your session key leaker in UDP, and only 2-3 hops on the TTL, so only locals can pwn you.  [1]
> Anything more built into the protocol to support unencrypted communication represents a sabotage attempt on the rest of the Internet.
> [1] I'm just waiting for the Botnet that uses open-WiFi to pwn the fellow computers in the local starbucks.  Its an old idea, but a good one...
> --
> Nicholas Weaver                  it is a tale, told by an idiot,
>                full of sound and fury,
> 510-666-2903                                 .signifying nothing
> PGP:
> _______________________________________________
> perpass mailing list