Re: [Lake] 1 week 2nd WGLC on requirements and scoping text

Eric Rescorla <ekr@rtfm.com> Tue, 02 June 2020 16:37 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E303F3A0C9F for <lake@ietfa.amsl.com>; Tue, 2 Jun 2020 09:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 Z_5FNRJvjHae for <lake@ietfa.amsl.com>; Tue, 2 Jun 2020 09:37:36 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6CA3A0C87 for <lake@ietf.org>; Tue, 2 Jun 2020 09:37:36 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id 82so6570959lfh.2 for <lake@ietf.org>; Tue, 02 Jun 2020 09:37:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TPYeq6lL/UCKdn8qwY0SRboJUKn+eHVWtf92SNXLt24=; b=Qlm+UtOXcJr/QxQoBi4Qbf+c1XiIX9nNVsyNnPuHt3b74bzldrNG0wJK84kRprY4Lg sTuBmAt7B7HK3ike9LGCi0QnwdErynT/fVXBdf2PokbW9xTdK1BX0QIHsLxXHVYNCksT T6N+r5KpUbTkp+9Fwjfif0TCnwh2Zsy98mtrFlFh1dDifyXIil0U9ckkED73tRHpC1pY Pbx4qh5x6YLjaLCLEN55hLc+QGKZBzZFJon1niNzDXzImeynPX6GLBCi0OF1/oEPGEyu jeFSF5g+t0FQmZa4qttX0cLHbqB074o1nZ5kJCM24fq4eq71XO2VATZ4fwwFlLtY7LZr XzjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TPYeq6lL/UCKdn8qwY0SRboJUKn+eHVWtf92SNXLt24=; b=l0Fz9gGxG5wzO+vHyqdrzO/285IQPXCqxJeb0taH49klUJLqkU1P/x551iqTIkgE9b aSYiJvNPRqQqi8YriCKqfbYaBPEMjyXzd5BmQdmac070pfPXX+c19BGWb/xlovD5+3hh LvNLP9/wb6Vg5cF8GerHcW275xLcxpy96mCNDNRjhuPAmBGve9dcXwoAcWKDMSfKUIv9 I/133St1ZL04sQ7+qGXiTwXtIrUs3H22+zHsA74d/FUW+j+0UtRY1gOOQECmwByKCrDq m5m1+yhtI5OdNtIcGAmHLAyy2XSHPN/reExy9zAC+0vtVeLovLHu/PXeFff+1r3Nyd2T WMwA==
X-Gm-Message-State: AOAM530yjmg1lH+5XBiFivU77KFfwkq+5LIrzoFHhhe00s+ew0teZANU wEen8vEcpblS0vKP5F4N3YTLXEcmDDuyL4dDz46b4w==
X-Google-Smtp-Source: ABdhPJxkAK/Zy+5j78jH/SQAMwX55J5U1NYy8qfP7TRFrJiNt1D2m7CQYpuGVSBXHqTLdq6/q5FWnZCd2Z3VeAjo2tA=
X-Received: by 2002:a19:c505:: with SMTP id w5mr116726lfe.201.1591115854669; Tue, 02 Jun 2020 09:37:34 -0700 (PDT)
MIME-Version: 1.0
References: <10CCD348-10E6-400A-81E3-253475C97250@ericsson.com>
In-Reply-To: <10CCD348-10E6-400A-81E3-253475C97250@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 2 Jun 2020 09:36:58 -0700
Message-ID: <CABcZeBNUZYjqQmFNuucGGPBLNYFWNxGzWdDvf0oPkJdRLHhh1A@mail.gmail.com>
To: =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "lake@ietf.org" <lake@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000507c1605a71c87e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/6_6I0wKwx-ZSL7lf71Mj-TqYnBI>
Subject: Re: [Lake] 1 week 2nd WGLC on requirements and scoping text
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 16:37:39 -0000

On Tue, Jun 2, 2020 at 6:48 AM Göran Selander <goran.selander@ericsson.com>
wrote:

>
>
> *From: *Eric Rescorla <ekr@rtfm.com>
>
>
> The scoping text added was:
>
>    As illustrated above, the setting is much more diverse
>    in terms of credentials and trust anchors than that of
>    the unconstrained web.  In order to deliver a timely
>    result, there is a need to initially focus on what is
>    considered most important at the time of writing: RPK
>    (by reference and value) and certificate by reference.
>    Information about validity of a certificate may be
>    omitted from the AKE if available over unconstrained
>    links.  The case of transporting certificate validation
>    information over the AKE may be specified in the initial
>    phase if there is a lightweight solution that matches
>    existing standards and tools.
>
>    A subsequent extension beyond the initial focus may be
>    inevitable to maintain a homogenous deployment without
>    having to implement a mix of AKE protocols, for example,
>    to support the migration path described above.  The AKE
>    needs to make clear the scope of cases analysed in the
>    initial phase, and that a new analysis is required for
>    additional cases.
>
>
>
> Stephen
>
>
>
> It's not clear how to read this in the context of other parts of
>
> the document, for instance:
> https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2
>
> which says:
>
>
>
>    In order to allow for these different schemes, the AKE must support
>
>    PSK- (shared between two nodes), RPK- and certificate-based
>
>    authentication.  These are also the schemes for which CoAP is
>
>    designed (see Section 9 of [RFC7252] <https://tools.ietf.org/html/rfc7252#section-9>).
>
> How is one supposed to interpret this text?
>
>
>
>
>
> [GS] Since OSCORE is an extension to CoAP it is expected to support the schemes for which CoAP is designed. But in the discussion following the virtual IETF 107 LAKE WG meeting we restricted the initial focus, leading to the addition of section 2.2.1 and the following text in the paragraph after the one you quoted:
>
>
>
> ”In order to provide a clear initial effort, Section 2.2.1
> <https://www.ietf.org/id/draft-ietf-lake-reqs-03.html#initial-focus>
> lists a set of credential types of immediate relevance; the mechanism for
> selecting credential scheme is presumed to enable future extensibility if
> needed.”
>
>
>
> The ability to extend beyond the initial focus is also repeated in the
> text from Section 2.2.1 which Stephen quoted in his mail:
>
>
>
> ”A subsequent extension beyond the initial focus may be inevitable to
> maintain a homogenous deployment without having to implement a mix of AKE
> protocols, for example, to support the migration path described above.”
>
>
>
> Yes, my point is that these three paragraphs together contradict each
> other. One says the AKE MUST support PSK and the other says it's not part
> of the initial focus. Does that mean that the AKE as published will or will
> not support PSK?
>
>
>
>
>
> [GS] The AKE which we will start work on will not include the PSK ECHDE
> variant.
>

I don't think this answers my question, which is not about where we start
work, but what is an acceptable output of this WG.

To restate it more crisply: would an AKE which was extensible but did not
include PSK be conformant with the requirements? It seems to me that the
document is unclear on this point.

-Ekr

The process for how to include that variant is as far as I know not
> defined, but it must be possible to extend to that variant at a later stage
> given that the appropriate analysis etc. is made.
>
>
>
>
>
> Göran
>
>
>
>
>
>
>
>
>
>
>