Re: Proposed Statement on "HTTPS everywhere for the IETF"

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 02 June 2015 06:45 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998ED1A871F for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 23:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.299
X-Spam-Level: ***
X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 o0pwxZLq5npk for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 23:45:04 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 2E4F91A8714 for <ietf@ietf.org>; Mon, 1 Jun 2015 23:45:04 -0700 (PDT)
Received: (qmail 63383 invoked from network); 2 Jun 2015 06:30:29 -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; 2 Jun 2015 06:30:29 -0000
Message-ID: <556D50EC.2030705@necom830.hpcl.titech.ac.jp>
Date: Tue, 02 Jun 2015 15:45:00 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com>
In-Reply-To: <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/0K-n1UFY__5doKucrJ1fxeCFBcE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 02 Jun 2015 06:45:05 -0000

Hi,

Though the proposal relies on BCP195, I'm afraid there is a serious
contradiction between the following statements in BCP195:

   o  Ticket keys MUST be changed regularly, e.g., once every week, so
                                                   ^^^^^^^^^^^^^^^
      as not to negate the benefits of forward secrecy (see Section 6.3
      for details on forward secrecy).

and

   o  If exponents are reused for too long (e.g., even more than a few
                                                  ^^^^^^^^^^^^^^^^^^^^
      hours), an attacker who gains access to the host can decrypt
      ^^^^^
      previous connections.  In other words, exponent reuse negates the
      effects of forward secrecy.

that it must be revised to shorten the duration of the former
statement before being used for the real world security.

Also, it should be honest to state that HTTPS for IETF may be
useless against USG surveillance.

							Masataka Ohta