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

Nico Williams <nico@cryptonector.com> Mon, 01 June 2015 21:03 UTC

Return-Path: <nico@cryptonector.com>
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 168CE1B2CD0 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 14:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 mBLBL0zrc6Nv for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 14:03:23 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 300A31B2C47 for <ietf@ietf.org>; Mon, 1 Jun 2015 14:03:23 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id E69E51E076; Mon, 1 Jun 2015 14:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZQwC/R/K5zzkew YH39uSGYxul0g=; b=NvZ9rWt9GANGoQKLO9KmObpt9OKk6LwVlSl4mKWbxqujko hmvJNrMtrP1bnPMUInjRufgmky9CoGxjfdgnDLOB1MF2IMFFay3VfXrzpbcuSoAf 9RYSd6ovi5eYuiCRDpOeTf93jkE3T/XwMRBNTGjW7uRqqV2UgRxGkRRcTBnlU=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 3780D1E071; Mon, 1 Jun 2015 14:03:22 -0700 (PDT)
Date: Mon, 01 Jun 2015 16:03:21 -0500
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Message-ID: <20150601210320.GL600@localhost>
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <556CBD4A.9030708@gmail.com> <CAMm+LwguFiH1Nz-DZznck--_OWbt49uFES+recJViYrC8X2W+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+LwguFiH1Nz-DZznck--_OWbt49uFES+recJViYrC8X2W+w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/xt27CyCSXfOub8xzgOpyeO9Qk4E>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
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: Mon, 01 Jun 2015 21:03:24 -0000

On Mon, Jun 01, 2015 at 04:58:07PM -0400, Phillip Hallam-Baker wrote:
> On Mon, Jun 1, 2015 at 4:15 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
> > Hi,
> >
> > I think this is reasonable. However, it seems necessary to qualify it
> > by pointing out that users of HTTPS remain exposed to traffic analysis
> > (e.g. see https://arxiv.org/pdf/1403.0297).
> >
> 
> Agreed.
> 
> But I would add a note to say that blocking traffic analysis is something
> that requires link layer encryption. I don't think we can do much to
> prevent that type of attack in IETF but we could stir IEEE to do something
> useful.

Traffic analysis might be happening far from the client, and might be
happening on middle boxes controlled by the attacker.  (Which is not to
say that we shouldn't bother with link-layer encryption in addition to
end-to-end encryption.)

There are many traffic analysis considerations.  For this particular
purpose it should suffice to refer to traffic analysis in general.
Though it might be useful to add recommendations about things like
length masking (since otherwise even just the lengths of packets might
suffice to identify the resources a user is accessing).

Nico
--