Re: pgp signing in van

Hector Santos <hsantos@isdg.net> Sat, 07 September 2013 15:41 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBABF11E8149 for <ietf@ietfa.amsl.com>; Sat, 7 Sep 2013 08:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.983
X-Spam-Level:
X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmKXtEZYnir8 for <ietf@ietfa.amsl.com>; Sat, 7 Sep 2013 08:41:34 -0700 (PDT)
Received: from catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 78B2911E8144 for <ietf@ietf.org>; Sat, 7 Sep 2013 08:41:34 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2622; t=1378568483; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qDkIWck3P5UuouJHBbnTqiIMh7M=; b=fbhoS0sWI7uMlF9z7OzZ z6DuozfHyAbCtjIPUWj91xEGOSgumWiHEW7nN5EIEEbvYkYRIJY85lMK6qm0A7PS i1hPRObvMADvqAmLYl+2O2cIXm0T6gtdaBltDEnb9TH/lPBIPdkiYdSJoIukERCs CltMFYjBo1JCeBtuF5m0ofE=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 07 Sep 2013 11:41:23 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 736014514.23265.1024; Sat, 07 Sep 2013 11:41:22 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2622; t=1378568141; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TF+iQbD mrJ5DfEM14Flgr+9qxJhmZcBu8k8Mmfvi+LE=; b=owcZfkepoCwQyf1WclOyzpV McSgsmN8OUW4eQ3ypEa6+DuGsGiTKf7kyHqeNjofQRnILM2yKXDZ24gED7h3EAFA iEt9PshVt2Ks4y4vBJ/N5CxNBvsoM1JDmYXYChKTE1mS6TfeR9wes6cIVRT0Cs0f mMOc+svcStSOvnx54nNw=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 07 Sep 2013 11:35:41 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 182421597.9.5596; Sat, 07 Sep 2013 11:35:40 -0400
Message-ID: <522B491A.5050500@isdg.net>
Date: Sat, 07 Sep 2013 11:41:14 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: pgp signing in van
References: <m2zjrq22wp.wl%randy@psg.com> <2309.1378487864@sandelman.ca> <522A5A45.7020208@isi.edu> <CA2A6416-7168-480A-8CE1-FB1EB6290C77@nominum.com> <522A71A5.6030808@gmail.com> <6DE840CA-2F3D-4AE5-B86A-90B39E07A35F@nominum.com> <CAPv4CP_ySqyEa57jUocVxX6M6DYef=DDdoB+XwmDMt5F9eGn1A@mail.gmail.com> <A6B01C4B-B59A-49FD-9524-D49F85750BF7@nominum.com> <522A9105.60108@gmail.com>
In-Reply-To: <522A9105.60108@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Sep 2013 15:41:47 -0000

On 9/6/2013 10:35 PM, Melinda Shore wrote:
>
> One of the useful things that PKI provides is some agreement,
> at least, about what we expect from certification authorities
> and what it means to issue and sign a certificate.  That is
> to say, the semantics are reasonably well sorted-out, which is
> not the case with pgp.
>
> Melinda


Much of the discussions also deals with how protocol implementators, 
i.e., mail, browser, routers market, has added these as features.  Are 
they secured out of the box?

For example, the browser market has recently began to enable OCSP 
(Online Certificate Status Protocol) out of the box. Is this good or 
bad?  Is this further violation of privacy? an ethical concern.  Is it 
more 3rd party tracking, monitoring with a good security purpose?

Add the same concept to the address bar searching methodologies that 
are now also enabling the out of the box for further 3rd party search 
and tracking path.

Add to that Javascript, 3rd party cookies and cross domain 
communications, once a major taboo, is now enabled out of the box. 
The enabling of "ping home" and "cross talking" ideas across the 
board, it is all enabled now.

Overall, we lost the focus of private by design with this exploding 
need to socialize and share information mentality.  Its not end to end 
any more.  Its an OPT-OUT, not OPT-IN mentality. The market is 
allowing it to happen, is it because they are aware of this and a made 
a choice or they don't even know it was even an issue?

The IETF methodology needs to be revamped to lead the way ago, take 
more charge of not being so relaxed in its security aspects towards 
communications protocols.  Consolidation of information is a start.

We knew since the beginning of SMTP how it was well known the SMTP 
(821) sender/return path was not secured.  Too much spoofing 
potential, yet it was written in stone in RFC2821 not to hurt a useful 
feature because of an ignorant bad guy.  Well, we finally recognized 
the bad guy was no longer ignorant by RFC5321. It took nearly a score 
of years to begin to address it, we have SPF for example, we have DKIM 
too.

And even then, we are still too relaxed.  I have always called for 
strong exclusive end to end, i.e., SPF -ALL, policies when possible. 
ADSP for DKIM, etc.

But overall, we allowed too much security relaxation into the 
protocols, making it them work with much lower payoffs and much more 
waste on the system.  We passed the buck to others and the future to 
address these well known issues. Too much time wasted.

The IETF can do better to lead the way.

-- 
HLS