Re: Security for various IETF services

t.p. <> Tue, 08 April 2014 13:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C51971A03AB for <>; Tue, 8 Apr 2014 06:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kkQXCMibzsxw for <>; Tue, 8 Apr 2014 06:03:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C3EC71A03A5 for <>; Tue, 8 Apr 2014 06:03:33 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 13:03:32 +0000
Message-ID: <011301cf532a$b4cd02a0$>
From: t.p. <>
To: Spencer Dawkins <>
References: <> <> <> <> <> <> <> <> <>
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: []
X-ClientProxiedBy: ( To (
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; =?iso-8859-1?Q?; FPR:FCDCC0D9.8EEA77FA.3DD9917F.8BE65339.20363; MLV?= =?iso-8859-1?Q?:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; ?=
Received-SPF: None (: does not designate permitted sender hosts)
Cc: IETF-Discussion <>
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: Tue, 08 Apr 2014 13:03:37 -0000

----- Original Message -----
From: "Spencer Dawkins" <>
To: "Ted Lemon" <>om>; "Stephen Farrell"
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
<> 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
> (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
> (

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

Tom Petch

> We can spin up new working groups to address problems we encounter.
> communities seeking to improve their security environment can't do
> 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
> 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