Re: Security for various IETF services

Yoav Nir <> Wed, 09 April 2014 09:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9402E1A0178 for <>; Wed, 9 Apr 2014 02:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ABvzadqnl7wX for <>; Wed, 9 Apr 2014 02:12:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::22d]) by (Postfix) with ESMTP id 6DD671A07AB for <>; Wed, 9 Apr 2014 02:12:14 -0700 (PDT)
Received: by with SMTP id d17so1598008eek.18 for <>; Wed, 09 Apr 2014 02:12:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aYsj/Ua7O/5plsj8Th+KMB11WJ3PL2vOYLSFmlzrpgk=; b=P0lQR8PZjDQZ7LDG4K3EibwlUD55/xGeOx7oKGzqlVaqDql5BGrAOCrNskIsl35fkO FCEcdDqv9llojnpif1NokJqA8bwRy/2C3a9y4Griym+2sOa26dBY/TYd1El0KRW53DBJ dQpvZZ04582Oiz/Y8f+M/m3a2SIEMdoIvqmC046HEywRjmynq7ZG0EsPlaqSi+ahD3cM xbQzLi4vyclfXl/nFWuj+EcABwA7nJRta7MkjqN0J92sj6hAPuI+gPzeG77qPf/gLEHl nZXFA8yM66SvrwaPrLVu6QoH/nnuA0d8upSEApX2gkkqzg048BwXqAtODL8ifAwGlL9g e6kQ==
X-Received: by with SMTP id i2mr11226701eem.53.1397034733651; Wed, 09 Apr 2014 02:12:13 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id s46sm990653ees.3.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 02:12:13 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Security for various IETF services
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 9 Apr 2014 12:12:06 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <011301cf532a$b4cd02a0$> <>, <> <>
X-Mailer: Apple Mail (2.1874)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Apr 2014 09:12:24 -0000

I disagree that this is not conventional best practice.

Since I brought up soap making supplies, I typed that in google and the first result was That’s a very conventional web store. It has instructional videos, forums for exchanging advice and recipes, and of course, the supplies themselves (with user-generated comments on each of them). 

As soon as you log in (necessary for posting on the forums and commenting on the supplies), you’re at HTTPS. You can use HTTP for browsing the videos, forums and comments, but if you’ve logged in, you do that over HTTPS as well. I’m pretty sure the people behind that store aren’t following perpass.

How is the IETF different enough that it needs *less* encryption than this store? As long as we provide HTTP access to the I-D and RFC repository (our “supplies”), why doesn’t it make sense to use HTTPS for other things?


On Apr 9, 2014, at 11:54 AM, <> <> wrote:

> Yoav,
> the problem here is that the perpass work (also spearheaded by Stephen) has redefined what 'best practice' is.
> perpass gives the security contingent of the IETF no limit in mitigation of pervasive monitoring -
> which means making everything as secure and private as possible, even when common sense,
> threat analysis and conventional 'best practice' would say otherwise.
> perpass makes the IETF special.
> Lloyd Wood
> ________________________________________
> From: ietf [] On Behalf Of Yoav Nir []
> Sent: 09 April 2014 09:38
> To: Dick Franks
> Cc: IETF-Discussion
> Subject: Re: Security for various IETF services
> On Apr 9, 2014, at 3:02 AM, Dick Franks <<>> wrote:
> On 8 April 2014 09:32, t.p. <<>> wrote:
> The path that I have seen several Security ADs steer Working Groups down
> is to start with a threat analysis before deciding what counter measures
> are appropriate.
> Several contributors have been saying exactly that for almost a week.
> These suggestions have been answered by dismissive emails and a relentless bombardment of magic pixie dust.
> The thing is, the IETF websites are not that special. There’s a bunch of information, most of it public. The sites accept payments by credit card thrice a year. There’s a wiki. There’s some mailing lists with archives and registration pages, There’s content that can be edited by privileged users, and there’s other content that can be uploaded by anyone and viewed by anyone. Pretty much any corporate website has these parts.
> The point of having best practices is that we don’t need to think about a threat model for each website. It’s a set of practices that someone has called “best practices” because they protect against several common types of attack at a low enough cost, that many web sites can implement them without actually proving to management that each part is strictly necessary.
> Sure, we can have a debate here about the security needs of each service provided and have some of the most knowledgeable experts debate whether the<> should have HTTP access, while<> should have only HTTPS, and tools. should have both and HSTS and HPKP to boot. But that is not eating our own dog food, because the next “store that sells soap making supplies on the ‘net” will not have access to such expertise. Our dogfood should be implementable by people who don’t read these mailing lists - the web site developer that said store hires. Hence the need for “best practices” shortcuts, which are very much a part of all branches of engineering.
> That said, if there are security implications that are not common to regular websites, these should be considered and discussed. For example, if reading drafts and RFCs from the office might betray your company’s future plans, that is a good reason to allow encrypted access to RFCs. Or if reading certain articles on Wikipedia can get you in trouble in some countries, then encrypted access to those may be in order. And if having both encrypted and non-encrypted access results in encrypted access being red-flagged as subversive, that may be a good argument for encrypted access by default or even exclusively.
> But before diving into such a discussion we need to have a good argument for what makes us so special.
> Yoav