Re: Security for various IETF services

t.p. <daedulus@btconnect.com> Tue, 08 April 2014 13:03 UTC

Return-Path: <daedulus@btconnect.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 C51971A03AB for <ietf@ietfa.amsl.com>; Tue, 8 Apr 2014 06:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.691
X-Spam-Level: *
X-Spam-Status: No, score=1.691 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 kkQXCMibzsxw for <ietf@ietfa.amsl.com>; Tue, 8 Apr 2014 06:03:34 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) by ietfa.amsl.com (Postfix) with ESMTP id C3EC71A03A5 for <ietf@ietf.org>; Tue, 8 Apr 2014 06:03:33 -0700 (PDT)
Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by DB4PR07MB251.eurprd07.prod.outlook.com (10.242.231.151) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 13:03:32 +0000
Message-ID: <011301cf532a$b4cd02a0$4001a8c0@gateway.2wire.net>
From: t.p. <daedulus@btconnect.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
References: <533D8A90.60309@cs.tcd.ie> <533EEF35.7070901@isdg.net> <27993A73-491B-4590-9F37-0C0D369B4C6F@cisco.com> <CAHBU6iuX8Y8VCgkY1Qk+DEPEgN2=DWbNEWVffyVmmP_3qmmmig@mail.gmail.com> <53427277.30707@cisco.com> <B275762E-3A1A-44A3-80BE-67F4C8B115B2@trammell.ch> <53428593.3020707@cs.tcd.ie> <A33A3F1E-8F6D-4BD9-8D1B-B24FBCD74D8D@nominum.com> <5342B26B.5020704@gmail.com>
Subject: Re: Security for various IETF services
Date: Tue, 8 Apr 2014 09:32:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.165]
X-ClientProxiedBy: DB4PR07CA040.eurprd07.prod.outlook.com (10.242.229.50) To DB4PR07MB251.eurprd07.prod.outlook.com (10.242.231.151)
X-Forefront-PRVS: 017589626D
X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(199002)?= =?iso-8859-1?Q?(189002)(51704005)(13464003)(479174003)(377454003)(6223600?= =?iso-8859-1?Q?2)(44716002)(44736004)(4396001)(59766001)(77982001)(956660?= =?iso-8859-1?Q?03)(49866001)(47736001)(90146001)(79102001)(47976001)(5098?= =?iso-8859-1?Q?6001)(51856001)(42186004)(19580395003)(88136002)(62966002)?= =?iso-8859-1?Q?(50466002)(56776001)(87286001)(87266001)(14496001)(7470600?= =?iso-8859-1?Q?1)(15975445006)(56816005)(15202345003)(89996001)(94946001)?= =?iso-8859-1?Q?(66066001)(83322001)(93136001)(81342001)(80022001)(1958040?= =?iso-8859-1?Q?5001)(65816001)(87976001)(81542001)(86362001)(551544002)(9?= =?iso-8859-1?Q?3916002)(74366001)(92726001)(33646001)(47776003)(95416001)?= =?iso-8859-1?Q?(50226001)(23756003)(74876001)(63696002)(76482001)(9733600?= =?iso-8859-1?Q?1)(93516002)(80976001)(84392001)(69226001)(53806001)(76786?= =?iso-8859-1?Q?001)(31966008)(77156001)(94316002)(61296002)(74502001)(474?= =?iso-8859-1?Q?46002)(74662001)(46102001)(99396002)(76796001)(54316002)(9?= =?iso-8859-1?Q?2566001)(20776003)(97186001)(85852003)(77096001)(85306002)?= =?iso-8859-1?Q?(98676001)(83072002)(74416001)(7726001); DIR:OUT; SFP:1101; S?= =?iso-8859-1?Q?CL:1; SRVR:DB4PR07MB251; H:DBXPRD0510HT002.eurprd05.prod.out?= =?iso-8859-1?Q?look.com; FPR:FCDCC0D9.8EEA77FA.3DD9917F.8BE65339.20363; MLV?= =?iso-8859-1?Q?:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; ?=
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/L_LsIwzCyVq4ogmhDmIMKF0GgrM
Cc: IETF-Discussion <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: Tue, 08 Apr 2014 13:03:37 -0000

----- Original Message -----
From: "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>
To: "Ted Lemon" <ted.lemon@nominum.com>om>; "Stephen Farrell"
<stephen.farrell@cs.tcd.ie>
Sent: Monday, April 07, 2014 3:12 PM
> On 04/07/2014 08:03 AM, Ted Lemon wrote:
> > On Apr 7, 2014, at 7:01 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> >> Yes, we ought move away from passwords if/when we ever find an
> >> acceptably better solution, and yes, people ought manage their
> >> passwords well, but neither are today's reality more's the pity.
> > Perhaps it would be worth setting up support for client certs as a
way to log in to IETF services.   If we won't start, why would someone
else?
>
> (Speaking as 1/15th, but only 1/15th, of the IESG that's asking for
> community input on this topic)
>
> For me, "If we won't start, why would someone else?" was a significant
> consideration. I'm not locked in on any particular path, but I thought
> it was useful to ask about this was that if the IETF can't make an
> improved security environment work, that's not a good sign
> (http://en.wikipedia.org/wiki/Eating_your_own_dog_food).

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.

Here, we seem to be following a path of 'We have got TLS with server
certs (which is pretty useless against most threats) so we will impose
that on everyone and call it an improved security environment'.

Solution first, requirements ignored.  This is not what I think of as
engineering.

Tom Petch

> We can spin up new working groups to address problems we encounter.
Most
> communities seeking to improve their security environment can't do
that.
>
> So, from my own perspective, on-by-default would be sufficient to find
> out what I'd like to find out ... but I'd love to find out at least
part
> of what we'd like to know, in a post-Snowdon world.
>
> We could find out something, without making Stewart run a
> state-of-the-art secure environment on his IoT device to FTP Internet
> Drafts.
>
> Spencer