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
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Yoav Nir
[ynir(_dot_)ietf(_at_)gmail(_dot_)com]
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
<rwfranks(_at_)acm(_dot_)org<mailto:rwfranks(_at_)acm(_dot_)org>> wrote:
On 8 April 2014 09:32, t.p.
<daedulus(_at_)btconnect(_dot_)com<mailto:daedulus(_at_)btconnect(_dot_)com>>
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
www.ietf.org<http://www.ietf.org> should have HTTP access, while
datatracker.ietf.org<http://datatracker.ietf.org> 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