Re: [VoT] Vectors of Trust I-D feedback

Rainer Hoerbe <rainer@hoerbe.at> Tue, 04 August 2015 06:12 UTC

Return-Path: <rainer@hoerbe.at>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA51E1B3637 for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 23:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 YZ7Y_1gYXmCM for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 23:12:32 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF811B361D for <vot@ietf.org>; Mon, 3 Aug 2015 23:12:31 -0700 (PDT)
Received: from [81.217.70.83] (helo=[192.168.1.33]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from <rainer@hoerbe.at>) id 1ZMVSh-0008Nv-1r; Tue, 04 Aug 2015 08:12:31 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Rainer Hoerbe <rainer@hoerbe.at>
In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net>
Date: Tue, 04 Aug 2015 08:12:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at>
References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <C9563753-E9E2-4990-9B7C-3AFEE232BD01@hoerbe.at> <CABzCy2AUA4ycTcj0-kgu_YaceduJRJYjruXs=X2zE1nowryGEQ@mail.gmail.com> <55BFEBC2.7070209@bluepopcorn.net>
To: Fenton Jim <fenton@bluepopcorn.net>
X-Mailer: Apple Mail (2.2102)
X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/QgHQxjIBw-CTC35H-C43mTz8XS8>
Cc: "vot@ietf.org" <vot@ietf.org>
Subject: Re: [VoT] Vectors of Trust I-D feedback
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 06:12:33 -0000

Am 04.08.2015 um 00:31 schrieb Jim Fenton <fenton@bluepopcorn.net>:
> 
> To be entirely consistent with ISO/IEC 29115, we would need to rename Identity Proofing as Enrolment, and Credential Usage as Authentication.
> 
> But ISO/IEC 29115 refers to these as phases: they occur at different times (or, in the case of Credential Management, over a long period of time) and have different threat models. But I would like to ask under which circumstances a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Authentication.
For a targeted attack the weak credential recovery will lower the adversary’s effort significantly, whereas in large numbers a 2F AuthN combined will still reduce the overall risk.

> There are credential management practices that would make a credential unsuitable for highly secure authentication, but why not just represent that as less secure authentication? VoT should be only as complex as required; it should not represent aspects of the process that the relying party does not need.

+1. However, I remember a discussion at IIW where someone argued that an important use case for VoT is the combination of C4 (U2F) with  P1 (self-asserted) for social ids. But social networks are prioritizing usability over security with a weak recovery mechanism.

- Rainer