Re: [IAB] Mandatory encryption as part of HTTP2

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 17 November 2013 23:38 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 1C7DA11E8188 for <ietf@ietfa.amsl.com>; Sun, 17 Nov 2013 15:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.19
X-Spam-Level: *
X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 sG9RZashH+VZ for <ietf@ietfa.amsl.com>; Sun, 17 Nov 2013 15:38:22 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 9745311E81A5 for <ietf@ietf.org>; Sun, 17 Nov 2013 15:37:31 -0800 (PST)
Received: (qmail 89695 invoked from network); 17 Nov 2013 23:31:25 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 17 Nov 2013 23:31:25 -0000
Message-ID: <52895335.9010906@necom830.hpcl.titech.ac.jp>
Date: Mon, 18 Nov 2013 08:37:25 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Subject: Re: [IAB] Mandatory encryption as part of HTTP2
References: <946B0ADE-F03B-4249-9D74-904C4BF13632@muada.com> <290E20B455C66743BE178C5C84F1240847E5103781@EXMB01CMS.surrey.ac.uk> <CAP+FsNfJ7iP8FZqY=beKE_ZNfiwZYvMcwbU9VUXmD5x4vNg9Kw@mail.gmail.com> <290E20B455C66743BE178C5C84F1240847E5103783@EXMB01CMS.surrey.ac.uk> <52860201.8000001@gmx.net> <3B2983EA-4462-4398-B822-95437C664E2F@muada.com> <13cae6c747eb44eebb2664902df34855@exrad6.ad.rad.co.il> <5286331D.2080409@gmx.net> <9EBA4A37-12F1-4CBB-B416-FF9F8F10CE88@shinkuro.com> <20131116013231.GD16722@thunk.org> <52893F62.3010009@necom830.hpcl.titech.ac.jp> <528941CE.7030203@gmx.net> <52894680.8080505@necom830.hpcl.titech.ac.jp> <52894AC9.6020600@gmx.net>
In-Reply-To: <52894AC9.6020600@gmx.net>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: iab@iab.org, Theodore Ts'o <tytso@mit.edu>, "ietf@ietf.org list" <ietf@ietf.org>
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: Sun, 17 Nov 2013 23:38:24 -0000

Hannes Tschofenig wrote:

> The PKI concept by itself does not say how many trust anchors you need
> to use at your client. You are complaining about the way how the WebPKI
> looks like and how the CA/Browser Forum is handling their business.
> Allowing new trust anchors to be added means giving new CAs a chance to
> enter the market.

Why do you insist on counting the number of Angels so much?

> Let's say we only have one trust anchor.

A CA under US legislation, a CA key management hardware/software
is developed by a company under US legislation or a CA a few
key managing personnel of which are under US legislation is
a lot more than enough.

Note that root zone of DNSSEC is managed by ICANN/ISOC incorporated
in US.

> There have been various ideas on how to improve the PKI, and the IAB has
> a security program that aims to make some progress in that area.

I'm tired of reading lengthy abstract nonsenses.

A simple and concrete example could help you convince people.

> I am
> currently working on a draft update of
> http://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution based
> on the feedback I have received.

A draft with 19 pages is already too bad on such a simple
problem only to have obscurity instead of security.

> Finally, in your threat model, however, the use of a DH will also not
> help since you have, as stated, the MITM attack at the ISP.

As I wrote in a recent mail:

   the problem for PKI is that, assuming active
   MITM attacks both on ISP chains and CA chains, it offer no
   better security than DH,

my point is that complex PKI, which you are trying to make even
more complex, is no more secure than simple DH.

It does not mean DH is very secure.

						Masataka Ohta