Re: Security for various IETF services

Dave Cridland <dave@cridland.net> Wed, 09 April 2014 20:36 UTC

Return-Path: <dave@cridland.net>
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 537061A0256 for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 13:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_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 u-8H4bxCypH2 for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 13:36:16 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBF51A02B0 for <ietf@ietf.org>; Wed, 9 Apr 2014 13:36:16 -0700 (PDT)
Received: by mail-ob0-f178.google.com with SMTP id wp18so3314160obc.37 for <ietf@ietf.org>; Wed, 09 Apr 2014 13:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9u53Z39C7LZbgsYBkxUSKc8wKcrCOFR9r/e/SbW6J7c=; b=BLhFwWQFM+oUUViiF8oCIuxeXXpAAvQXmPmpYbjYB0OG/L/zTERfT5oA533H/anWnf TPLbV6Xi4XJ2ibW5UVwmZ5T2WoY3rd7n5rjYc/7ATeNrXhyGuD8lFtUJneq6ugIbEpY8 8nIzMNGhXM0tFh4Z5TmQvt+maNenC/QZ+RiYk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9u53Z39C7LZbgsYBkxUSKc8wKcrCOFR9r/e/SbW6J7c=; b=ZJ9yoDHA8rF38VlbVPKMQ7H3HtG8/weKeY/iaEpqjwBOrLhCZyQ77DJD4RtKnBbuIf 4vjwrXFbENgxotBGv8TpLIRKo/JxvPDyJMuc6RBU349VN5aas9M6aboXqyFcvE7knjun P6AwgjXOTYipAUvUr6id9MbqOYLKRQ34LUN+0yaI76rbxp6owa6o+ch1CseZE8UAqWat kS/+ip3NqxMWi9xt6y6aglBkX/8xoc/NnREVdURK3yB2EtAp9u/zgsE+C0xiQNgun3SX 5lU/7vbG4VTSthFJpmasrquzqBz18Zazyr/gNtJQkqqnNmATk1XV+7jfxoVaA74Ii9t/ 0cTg==
X-Gm-Message-State: ALoCoQn+L5feLl+15fG1a8xu9ZUOGYWqB/vHLDTWjtCwqrtq/mTFO1bOzo5g7LPB46i9scz1VA0V
MIME-Version: 1.0
X-Received: by 10.60.103.210 with SMTP id fy18mr2251660oeb.75.1397075775807; Wed, 09 Apr 2014 13:36:15 -0700 (PDT)
Received: by 10.60.93.6 with HTTP; Wed, 9 Apr 2014 13:36:15 -0700 (PDT)
In-Reply-To: <3C46B827-BFFC-4A9E-B600-A1E79C839970@shinkuro.com>
References: <20140409154919.11E6118C106@mercury.lcs.mit.edu> <534580AF.4080602@dcrocker.net> <20140409200814.GA15303@thunk.org> <3C46B827-BFFC-4A9E-B600-A1E79C839970@shinkuro.com>
Date: Wed, 09 Apr 2014 21:36:15 +0100
Message-ID: <CAKHUCzymXu0TGEYD6dQj9OVhGn2pgE9nPqDG6guV+RS+L8XTow@mail.gmail.com>
Subject: Re: Security for various IETF services
From: Dave Cridland <dave@cridland.net>
To: Steve Crocker <steve@shinkuro.com>
Content-Type: multipart/alternative; boundary="089e0115ee7c57765504f6a20d5e"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/aiTUIJ4xMC4JL7jpATuEWNuyP8Q
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, Theodore Ts'o <tytso@mit.edu>, "ietf@ietf.org Discussion" <ietf@ietf.org>, David Crocker <dcrocker@bbiw.net>
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: Wed, 09 Apr 2014 20:36:21 -0000

On 9 April 2014 21:15, Steve Crocker <steve@shinkuro.com> wrote:

> My own opinion is related but not identical.  I agree solutions 1 and 3
> are failures; 1 doesn't provide the trust and 3 doesn't scale.  Solution 2
> is also problematic because the government tends to overreach and there
> isn't a single government.
>
> DNSSEC provides a base platform to build upon.  It doesn't claim to
> provide the level of trust the CA system tried to provide.  That's a key
> strength, not a weakness.
>

DNSSEC, and DANE, allow you to provide a "Domain Validated" public key,
much like the cheap/free certificates currently available from CAs, but
more reliably and simply. I think the same level of trust is there either
way, except that the cheap/free CA certs are very weakly validated in
practise.

CAs can provide actual identity assertions, and in private situations
authorization information.

I suspect that if we can get DANE deployed, we'll see most of the cheap and
somewhat useless CAs vanish, and only those with reasonable tust remaining
survive on fully validated, EV et al, certs, actually, but that's besides
the point.

I wonder if we can't use DANE, S/MIME, WebFinger and a little
sensibly-applied PKI, so that:

1) You could find out assertions of what CA (if any) users of a particular
domain use for end-user client certificates via a TLSA record. Say _users
IN TLSA ...

2) We can use WebFinger to find the certificate itself, and therefore a
possibly signed assertion of actual identity, both WebFinger and this
certificate protected currently by stock PKIX (and in the future, DANE).

I think this gives you essentially everything anyone might want, but for
added bonuses, we could do a web-of-trust thing hanging off WebFinger
(publish any signatures anyone else is prepared to give you) or via public
services.

However, it's probably been suggested before and shot down before, so feel
free to point me to its death notice. :-)

Dave.