Hum theatre

Abdussalam Baryun <> Thu, 07 November 2013 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CD8C11E8230 for <>; Wed, 6 Nov 2013 22:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7M4Y3QO6Wnbj for <>; Wed, 6 Nov 2013 22:00:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c02::229]) by (Postfix) with ESMTP id 69AD511E8167 for <>; Wed, 6 Nov 2013 22:00:39 -0800 (PST)
Received: by with SMTP id q10so109325pdj.14 for <>; Wed, 06 Nov 2013 22:00:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aHL+bpYuXkVHMXAzF5yisgAgw1EHAfLeJ4puEpUiSPI=; b=OnkmNH/e0bsODqlasR58vSL7324FCETNlozTg4rK+Tv6ollh2FH5O5w0ZA9TlEkWWd 8mGUW32PpzjMW9K8wJKtzSCY/5I0tALhtrXPqtzNRRuSc7zzQeQ6FGjOtXVZDwo7OQIZ 1q3EuoPIU8Vf35MS7d3D/tOXO896gZBLSWJ3gVy3hyCUAcC9W2ptg5dCpujKJXoBMAzs vSs7qJ28/B0duiemLEqmtdPYUQTs2WKzKL2G0BMvygXbEGxsBRzm47BgYSIukxeEM9Rl 4Mw8r5kRGMgceaTwNkCFCP3QCoBIaqN8t31gK8/SMek+K8Fkvj89kDiuG9uWOKSUuzWE CTPw==
MIME-Version: 1.0
X-Received: by with SMTP id l5mr7116454pbj.134.1383804036139; Wed, 06 Nov 2013 22:00:36 -0800 (PST)
Received: by with HTTP; Wed, 6 Nov 2013 22:00:36 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 7 Nov 2013 06:00:36 +0000
Message-ID: <>
Subject: Hum theatre
From: Abdussalam Baryun <>
To: "Fred Baker (fred)" <>
Content-Type: multipart/alternative; boundary=bcaec520eb1503575704ea8ffc76
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 06:00:40 -0000

On Thursday, November 7, 2013, Fred Baker (fred) wrote:

> 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 think the implication is to be how we do things should change, designing
without considering security is wrong and we need more cross WGs to avoid
future problems, making design simple is ok to do parts but not  full
work/protocol. We need to UPDATE all protocols. The old designers should
admit that there are mistakes no ones perfect.

. 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.

May be more options of security techniques not only few security algorithms
which may affect other protocols.

> 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?

We should be sure, and we should update protocols for the best services to
the world.

> 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.

 IMHO, We need to update all the Internet transport and
application protocols for security focus.

> 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.
> Agree

> 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.

At least we report breaks and possible attacks, and do or best updates for
our users. If operators don't fix and update,we then blame them, the
community of users are very intelligent.

> 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.

Why privacy threats were not addressed before users noticed the attacks and
that the designers failed? The IETF way of work and structure needs to
change, I already suggested it in past. Once an AD suggested more cross
area, but I think it is better to have cross WGs and changing structure of
IETF areas.

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

Yes, It is easy to say or implement but what matters is what happens and
how we work to adapt and develop quicker than our attackers.