Re: Security for various IETF services

John C Klensin <john-ietf@jck.com> Mon, 07 April 2014 14:02 UTC

Return-Path: <john-ietf@jck.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 59D031A0424; Mon, 7 Apr 2014 07:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 GX0KxVvsF6Uv; Mon, 7 Apr 2014 07:02:41 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA3D1A070C; Mon, 7 Apr 2014 07:02:41 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WXA83-000IsB-NH; Mon, 07 Apr 2014 10:02:27 -0400
Date: Mon, 07 Apr 2014 10:02:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ted Lemon <ted.lemon@nominum.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: Security for various IETF services
Message-ID: <DC23F34E807E77F8C4C095C3@JcK-HP8200.jck.com>
In-Reply-To: <A33A3F1E-8F6D-4BD9-8D1B-B24FBCD74D8D@nominum.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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/KoD-e-O3vzUuNqYBjMLe2wPtKJM
Cc: Stewart Bryant <stbryant@cisco.com>, Tim Bray <tbray@textuality.com>, IETF-Discussion <ietf@ietf.org>, The IESG <iesg@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, 07 Apr 2014 14:02:46 -0000

--On Monday, April 07, 2014 09:03 -0400 Ted Lemon
<ted.lemon@nominum.com> 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?

If we are really serious about promoting/ encouraging security,
I'd really like to see this as an option.  Not only would it be
responsive to Ted's question, but, if we made it available and
almost no one used it, it would give us a lot of information
about the course we are on.

As to the core proposal, unlike SM, I would like to see each new
application that someone proposes to be accessible through
"secure" means only discussed one at a time.  My fear of the
whole Prepass effort was that it would be used in "we approved
that, therefore we can and should do this without further
discussion" arguments.  I just thought it would take a few years
to get to that point.

Finally, if the IETF effectively declares HTTP obsolete for
anything but legacy applications, I think it is logically
necessary that we create an applicability statement deprecating
HTTP and approve it.  Anyone really, seriously, want to go there
or think that would could without losing all credibility in the
vendor and user communities?

   john