Re: [Endymail] Another view of the problem and what the IETF could do

Steffen Nurpmeso <sdaoden@yandex.com> Tue, 02 September 2014 10:42 UTC

Return-Path: <sdaoden@yandex.com>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1111A000F for <endymail@ietfa.amsl.com>; Tue, 2 Sep 2014 03:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uUCYWQ1f2M-D for <endymail@ietfa.amsl.com>; Tue, 2 Sep 2014 03:42:28 -0700 (PDT)
Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [84.201.143.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56A71A000E for <endymail@ietf.org>; Tue, 2 Sep 2014 03:42:27 -0700 (PDT)
Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [37.140.190.28]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 21348BC1031; Tue, 2 Sep 2014 14:42:23 +0400 (MSK)
Received: from smtp3o.mail.yandex.net (localhost [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id 82D341E2B8C; Tue, 2 Sep 2014 14:42:22 +0400 (MSK)
Received: from unknown (unknown [82.113.106.133]) by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RVMOqmmLsu-gLWCaxOH; Tue, 2 Sep 2014 14:42:21 +0400 (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client certificate not present)
X-Yandex-Uniq: 91594e8b-053a-42a1-8a4f-d62089669da7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1409654541; bh=mJnFOdXb1ILhHkqmFJMKoEIgxzkD59Ocnmy3xT3mXzw=; h=Date:From:To:Cc:Subject:Message-ID:References:In-Reply-To: User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RLcNcqHlRKA5u6P0yegQ8rCxdbcMSheOomL653ckGSTFNOzHqpy5433QznMFD0d0s SG4Vl25SsPuPDYNX7Vu1lACK7VrBPZjhEvrpe6m92J3FxWpURqZjGRS6H5sjWtjj/1 ylq9nFRnZtYiaHsdXB4uoKKC5ts1km/O1M/D3Nfc=
Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.com
Date: Tue, 02 Sep 2014 12:42:17 +0200
From: Steffen Nurpmeso <sdaoden@yandex.com>
To: endymail@ietf.org
Message-ID: <20140902114217.lp_a_yD8%sdaoden@yandex.com>
References: <CAHBU6iuxfqs9RszSaJLaTV_obKBCJ9Pzii+t9XANN3q+bJm-3Q@mail.gmail.com> <878um3prio.fsf@vigenere.g10code.de> <cddbc815-a98a-48e5-8dea-c3d8a68ca4d9@gulbrandsen.priv.no> <87y4u2laqh.fsf@vigenere.g10code.de>
In-Reply-To: <87y4u2laqh.fsf@vigenere.g10code.de>
User-Agent: s-nail v14.7.6-15-gc1887ab
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/OkedzQQpGjjjjhi7TEU5mdv9O3w
Cc: Werner Koch <wk@gnupg.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: Re: [Endymail] Another view of the problem and what the IETF could do
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Sep 2014 10:42:31 -0000

Werner Koch <wk@gnupg.org> wrote:
 |On Mon,  1 Sep 2014 12:48, arnt@gulbrandsen.priv.no said:
 |> The web of trust hasn't failed?
 |
 |The WoT is only a part of OpenPGP and actually never specified.
 |
 |Sure, mass-acceptance of encrypted mail failed but not due to the WoT.
 |If you ask OpenPGP users you will notice that most of them entirely
 |ignore the key validity issue and at best use local signature to mark
 |keys valid.  Does this help?  No, people still complain that encryption
 |looks too complicated and they turn over to the next hottest

If with introduction of the new german passport every receiver had
also obtained a set of usable PGP and OpenSSL S/MIME keys and/or
certificates -- at best with a small info flyer which would have
shown how to import those into the tools of the most widespread
operating systems -- the situation would surely be better in
Germany.

Not that this means that some kind of people won't go with hypes
anymore, but i am sure for most people, Germans that is, WoT had
to be something from the "ultimate" (or only real) authority, and
would then be used just the same way as one uses the passport.
Note that this would also cutdown the complexity of key handling,
the sheer amount of keys to be managed, which can be kind of
frightening if you're unlucky.

So unfortunately that didn't happen, and "ca-certificates" does no
longer include CACert.org because people are playing games or
misusing their anonymity for whatever reason, so where does
a normal person get their free S/MIME environment from (the list
already has seen those approaches that are not really usable for
a normal person).

Providers could include a free certificate with each account,
which would enable their users to choose security by themselves
(on a per-provider basis).
A SMTP-server-chain-of-trust can prevent STARTTLS MITM by simply
assuming TLS (which didn't become SMTPS via port 465 for reasons
that i don't know, yet NetBSD's /etc/services still lists this
relationship and my free mail provider offers the service as
such).
I personally never liked DNSSEC; UDP packet sizes can be
enlargened etc., but usage of TCP is in the protocol, and then
protected right away via TLS i would have preferred, and
ca-certificates are installed wherever i am.
Of course my opinion is rude and simple and doesn't deliver.

--steffen