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

Eric Rescorla <ekr@rtfm.com> Tue, 02 June 2020 12:45 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 61EF03A03FF for <lake@ietfa.amsl.com>; Tue, 2 Jun 2020 05:45:52 -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 wtKw_uyoKgyy for <lake@ietfa.amsl.com>; Tue, 2 Jun 2020 05:45:50 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 922CB3A083B for <lake@ietf.org>; Tue, 2 Jun 2020 05:45:33 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id j12so3354357lfh.0 for <lake@ietf.org>; Tue, 02 Jun 2020 05:45:33 -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=j3P5q/O7iLdPYvHOSKwXb9cEtPMLkjyUAyVT65W+50w=; b=Q1Q/SV9ZW9fC1RdIWK3Z+i/3dKR6C+SV64pi6sr+nt1W6peq8urt9cgBeoGMtqO91o QSPOFOnLDqkVcql+EQqWBA06REtBQJ4+JVJbTCnqROkj4onw9vfF5MJGHOr1EF8B9zeD qFq1ez8yxFo5xI35RhvKrBVM8q1LisIz/j3GViVCYZ1mW4h6ewWVHC0jEJFa52qbn5PR FGyrmNlW5mxsDBOwO/XyjAayWqbJBj3thkQ6Oivr4baoOTAc8Q81MudIHvdKGtfsEIm/ cGGS3kzO5TC7hGqd7Hfs3Zq++qf/++ioUC37aC7hxJx6IRX7ylY+AZ9GCNz6VT8OCS+7 ufIg==
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=j3P5q/O7iLdPYvHOSKwXb9cEtPMLkjyUAyVT65W+50w=; b=uf0mzqKjNbrAy3/HN58KCPRV1+dU1bKHOxS3SmdVE1Ses9/ihrLMrYN+ZXH7I+v1oq WQ2hoGfpo2v4WY78QoiS4zSETyNZBrjiw6QUuPYoBh8vb06swYeShj0cNf/dDjH8GeC5 nN/mE16IjfAd+h/tD1A+Csr9R/BVw80nSdnmJGDKylwYIDwRaZ8jT5nPPJD9VrCI3k1x ++WBKvLoKRGc1Z9cMhPy6akr42P+HWS+GSJ0OGdfJrGpJkJLJZNwMKRJcW/v6OM0taPR 61qdwK2PAQ5uo3Lo27a+DGB+RhsWuC/VO1ShOmZKrM3XF0Lq7NAIo/MNox20KAoLazZL /Rkw==
X-Gm-Message-State: AOAM531FuQ3NpS/vYq4vqWJL7R+/lGWKfggsYfqjcplxlTRHUPBcUwR9 hTq55EqF5BjIO92CgM06wm+3isVP42aakjZWjYjjuw==
X-Google-Smtp-Source: ABdhPJw+4pPzYoPnPxSyICeoRDJyzazRLyVb5HqGHEg2nvGocXtHi4F/Ctn/fBXbd7P2x06U731WtT6H+fzNFfWNGSg=
X-Received: by 2002:a19:5216:: with SMTP id m22mr13964328lfb.14.1591101931729; Tue, 02 Jun 2020 05:45:31 -0700 (PDT)
MIME-Version: 1.0
References: <3ca570db-8509-04cf-1878-291b28e00842@cs.tcd.ie> <CABcZeBMTQQkcXj+vpRZkZc1ZCpK+LfL_hG7-W2gNk+OFr-Q5Vw@mail.gmail.com> <47998971-8781-46E2-930E-21C2A774FA18@ericsson.com>
In-Reply-To: <47998971-8781-46E2-930E-21C2A774FA18@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 2 Jun 2020 05:44:55 -0700
Message-ID: <CABcZeBO9Gc=w9N3ziOrcwVAmg171LXMQ7EXWQHP5yAkKh6q3VA@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="00000000000071509805a7194992"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/rPciBQ6VDZDe0wLZTR51mjm2lqs>
Subject: Re: [Lake] FW: 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 12:45:52 -0000

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

>
>
>
>
> *From: *Lake <lake-bounces@ietf.org> on behalf of Eric Rescorla <
> ekr@rtfm.com>
> *Date: *Tuesday, 2 June 2020 at 03:19
> *To: *Stephen Farrell <stephen.farrell@cs.tcd.ie>
> *Cc: *"lake@ietf.org" <lake@ietf.org>
> *Subject: *Re: [Lake] 1 week 2nd WGLC on requirements and scoping text
>
>
>
>
>
>
>
> On Sun, May 24, 2020 at 2:08 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>
> Hi all,
>
> First: my apologies for taking so long on this. (I got
> sidetracked by an unexpected project.)
>
> ISTM we have pretty good, if rough, consensus on enough of
> the text to proceed, but with one important part that needs
> checking. (See below.)
>
> I'd like to start a 1 week 2nd WGLC with the main focus
> being to establish whether we have rough consensus on the
> scoping text below. (Which can be see in context at [2].)
> That text was the main outcome of our virtual meeting last
> month.
>
> So, please send mail to the list saying if you are happy
> enough to proceed on this basis. If you are not, then I'd
> appreciate if you could suggest alternate text with as
> few changes as possible.
>
> This 2nd WGLC closes on June 1st. If I see rough
> consensus to proceed at that point, I'll plan to start a
> call for adoption for the edhoc draft. If not, we'll have
> to discuss how to proceed with our AD, as I think that
> would mean that the WG is very badly stuck.
>
> 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?

-Ekr




>
>
> -Ekr
>
>
>
>
> Thanks,
> Stephen.
>
> [1] https://tools.ietf.org/html/draft-ietf-lake-reqs-03
> [2] https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2.1
>
> --
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake
>
>