Re: Hum theatre

"Fred Baker (fred)" <> Thu, 07 November 2013 03:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96BEF21E80DA for <>; Wed, 6 Nov 2013 19:44:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.379
X-Spam-Status: No, score=-110.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IKMOfKryR5Io for <>; Wed, 6 Nov 2013 19:44:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BCCDD21E80C8 for <>; Wed, 6 Nov 2013 19:43:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3113; q=dns/txt; s=iport; t=1383795830; x=1385005430; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1csR94O7zlCS25wx2ml3B1RpWVU3woZQvh/3pkANtCk=; b=CuvycFPB/BWGFR/Y7+mtbOLmawK23g2m4ZhVLv3bIbkljmcmunj2PBKl 16u102kn6QrlHuMUdxPpbA3f945IHFoBjq9uH5I5JGSemI9HrXZ05GJwH ELAUqcEPLy5sI6VCa26JOJn+zM6FTgw2xazngfylP/qj53ZB4YcNKxxNW g=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFACoLe1KtJXG9/2dsb2JhbABagwc4U78cgSkWdIIlAQEBAwF5BQsCAQhGMiUCBA4FDodtBr5xj1kHgyCBEAOQLoEwhi6SCoMmgio
X-IronPort-AV: E=Sophos; i="4.93,649,1378857600"; d="asc'?scan'208"; a="281747214"
Received: from ([]) by with ESMTP; 07 Nov 2013 03:43:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rA73he5G031622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 03:43:40 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 21:43:40 -0600
From: "Fred Baker (fred)" <>
To: "<>" <>
Subject: Re: Hum theatre
Thread-Topic: Hum theatre
Thread-Index: AQHO22Bm278AERXjx0WkVd8HlPN725oZhOmA
Date: Thu, 7 Nov 2013 03:43:39 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_95ED60BF-529D-46D0-AF96-E877FF7C62FD"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2013 03:44:10 -0000

On Nov 6, 2013, at 6:23 PM, Dave Crocker <> wrote:

>     The IETF needs to press for careful attention to privacy
>     concerns in its work, including protection against surveillance.
>          [ ]  No
>          [ ]  Yes
>          [ ]  Don't Yet Know
>          [ ]  Don't Care

I guess that as a technologist I need a little more information.

First, as the questions were asked this morning and as you suggested they might have been reworded, the implication of a "yes" is that we will go back to each protocol we have deployed or in design and "do something" to make it more private, including protection against surveillance. I'm not sure we're likely to, for example, change RFC 791 to make it less available to surveillance, or for that matter RFC 2640. I'm not sure exactly how to change UDP, TCP, SCTP, and so on. Yes, there are some fields that could probably be encrypted, and doing so using IPsec ESP has some value in terms of integrity checking end to end. But I'm not sure that this would have an impact on privacy. ICMP? ARP? ND? OSPF? IS-IS?

So if the question is "all protocols", I'm not sure it is appropriate for all of our protocols to be changed, because I'm not sure that they face threats that we can effectively mitigate.

As we get further up-stack, the application of TLS or DTLS, and anything that would help with pervasive use of OpenPGP-or-whatever, would be a good thing. Where we have protocols that could usefully use TLS/DTLS and don't, we can address that, and I suspect it might be appropriate for the relevant working groups to amend their charters accordingly. In those cases, I would agree that the IETF SHOULD (not "needs to", this is a question of will and direction, not necessity) pay careful attention to privacy concerns in its work, including protection against surveillance.

After that, it's operational. If a site it deploying http and we might prefer it used https, running out and changing the protocol isn't going to fix anything. The operator of the site in question needs to change protocols to https - or something like that.

So, which protocols are under discussion, and what security/monitoring/privacy threats does each face? Where our protocols face legitimate threats, yes, we SHOULD address them. 

I'm not sure feel-good statements say much.