Re: [Lake] [Secdispatch] LAKE next steps

Benjamin Kaduk <kaduk@mit.edu> Wed, 28 August 2019 19:18 UTC

Return-Path: <kaduk@mit.edu>
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 0CDA2120857 for <lake@ietfa.amsl.com>; Wed, 28 Aug 2019 12:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GoybkhCKLIrb for <lake@ietfa.amsl.com>; Wed, 28 Aug 2019 12:18:26 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D510F120255 for <lake@ietf.org>; Wed, 28 Aug 2019 12:18:25 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7SJIJG2010675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 15:18:22 -0400
Date: Wed, 28 Aug 2019 14:18:19 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Göran Selander <goran.selander@ericsson.com>
Cc: "lake@ietf.org" <lake@ietf.org>
Message-ID: <20190828191818.GF84368@kduck.mit.edu>
References: <20190820155006.GE60855@kduck.mit.edu> <DED9B6C1-2E61-4C20-822D-4F22C848EC1E@ericsson.com> <20190826204642.GM84368@kduck.mit.edu> <9E33B44F-1364-40F0-AD8C-259108C4D2B9@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9E33B44F-1364-40F0-AD8C-259108C4D2B9@ericsson.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/T_gE8cZzo59P7jmBx2_rBdSiiZE>
Subject: Re: [Lake] [Secdispatch] LAKE next steps
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: Wed, 28 Aug 2019 19:18:37 -0000

On Tue, Aug 27, 2019 at 01:46:24PM +0000, Göran Selander wrote:
> Hi Ben,
> 
> On 2019-08-26, 22:46, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     > The proposed charter looks fine, I only have one comment on the text, see below. In particular I don't think there is any need to further detail requirements in the charter since those can be agreed with the listed stakeholders as part of the work.
>     > 
>     > Excerpt from proposed charter:
>     > 
>     > 'The working group will collaborate and coordinate with other IETF WGs
>     > such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the
>     > requirements and solution.  The WG will also evaluate work from
>     > the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.'
>     > 
>     > My comment is on the last sentence above. I already commented on this sentence in a previous draft of the charter:
>     > https://mailarchive.ietf.org/arch/msg/secdispatch/xJTkOA6zfU0TcQPMYevg8IBUSVk
>     
>     Oops, I'm sorry I didn't notice the comment from the previous round, when
>     preparing this draft text.  Are you proposing to just drop the "and
>     derivatives thereof"?  I believe that the intent last time around was to
>     include what became cTLS, though at that time it was unclear what home
>     could be found for it.  At this point it looks more likely like the TLS WG
>     could do it, though it's not decided for sure, so the cross-WG dependencies
>     remain a little annoying.  That said, I think that the proposed LAKE
>     charter should only consider output from the TLS WG, not
>     work-still-in-progress at the point when a decision is to be made.
> 
> [GS] Let me try to be more clear. I would like to make sure that LAKE is only tasked with evaluating candidates from the TLS WG that comply with the requirements at the time when the evaluation is done in the LAKE. If a protocol does not comply with all requirements it doesn't make sense to compare e.g. message sizes, since that is a function of the supported functionality. In other words, the LAKE WG should not be dependent on progress of drafts in the TLS WG, but only need to consider what is available at the time when the LAKE WG needs to make its choice. 

I think we're on the same page.  Though I will note that, if the current
draft charter is used, that choice would not be made until after
deliverable (1) is available.

> 
>     > Additionally, I don't think this sentence well reflects the text in your mail:
>     > 
>     > 'From we’ve seen so far, EDHOC seems like the leading contender, especially with respect to the “reuse of COSE algorithms” proposed requirement, but we of course welcome further data (such as on the relative code footprint of core cryptographic primitives vs. protocol integration for COSE/cTLS/etc.).'
>     
>     That was intended to be my personal take, not an attempt to judge community
>     consensus.  (Well, Roman seems to have signed off on it, too, but the two
>     of us do not a community make.)  So the draft charter text was
>     intentionally more open.
>     
>     > Detailed comments:
>     > 1. It is fine that the WG also evaluates work from the TLS WG, with the obvious restriction that only solutions that are ready and complies with the requirements need to be evaluated. As long as we agree on that, there is no need to change the charter on this point. 
>     
>     Right.  "Passed WGLC" is probably a usable threshold.
> 
> [GS] Sorry, this was not the threshold I had in mind, the word "ready" may have been misleading. I meant ready for evaluation in the sense that requirements are fulfilled and benchmarks can be compared, e.g. that message sizes have been calculated under uniform assumptions common to all protocols.

I'm not tied to "passed WGLC", it just has the advantage of being very easy
to observe/determine.  I'd be happy to hear alternative suggestions, as I
agree that it's not the greatest threshold (merely "usable", in the absence
of others) :)

>     
>     > 2. Please move ", and draft-selander-ace-cose-ecdhe" from this sentence and include it in a sentence before this one indicating that it is currently the only specified AKE for OSCORE. 
>     
>     Recent IESGs have been somewhat fussy about the language used to describe
>     individual drafts in WG charters -- language like "evaluate" or "use as a
>     starting point" tends to do better than "will adopt" or similar.  And of
>     course it would be good to get some more feedback from the group, since
>     you're an author :)
> 
> [GS] I'm fine with "starting point" as was used in your question to Secdispatch [1] which received 15+ individual positive answers and positive support from two 
> working groups (CoRE and 6TiSCH). Do we really need more feedback at this point? I think many of them who responded to that call believe they have already provided the necessary feedback for this process. 

I'll try to see if I can switch this to "starting point" for a future rev
of the draft charter text (barring objections, of course).

-Ben

> 
> 
> [1] "Conclusion
> 
> There appears to be an understood and scoped problem that is feasible to engineer.  Among the available starting points to address the problem defined in question #1, EDHOC presents a viable choice.  
> 
> Chartering a narrowly scoped, short-lived WG in this space with EDHOC as a starting point seems to be an attractive path forward, but we would like to receive community feedback on the degree of support for this approach."
> 
> (Excerpt from https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c)
> 
> 
>     > 
>     > 
>     > On 2019-08-20, 17:50, "Lake on behalf of Benjamin Kaduk" <lake-bounces@ietf.org on behalf of kaduk@mit.edu> wrote:
>     > 
>     >     Thank you to everyone who attended the LAKE BoF session! It was a
>     >     productive meeting that highlighted the community’s needs for work in this
>     >     space.  A key insight that emerged during the session was that there is a
>     >     fairly clear split between the “AKE for OSCORE” case and “general purpose
>     >     lightweight AKE” in terms of the set of requirements.  We are happy to note
>     >     a strong level of interest in a TLS-based solution that removes unnecessary
>     >     protocol fields and encoding redundancy, which has significant potential
>     >     for use in protocols that do not require traditional TLS cross-version
>     >     compatibility, in constrained and full-featured environments alike.
>     >     Likewise, we saw that the additional community engagement of a BoF was able
>     >     to provide new insights into the use cases and requirements for a LAKE [0],
>     >     both in the OSCORE and the more general case -- this is a great indication
>     >     of the value provided by the broad and cross-area IETF review process.
>     >     
>     >     Based on the input received and energy in the room, we feel that it’s
>     >     appropriate to charter a WG to finish coalescing the requirements for the
>     >     OSCORE use case and evaluate solutions.  From we’ve seen so far, EDHOC
>     >     seems like the leading contender, especially with respect to the “reuse of
>     >     COSE algorithms” proposed requirement, but we of course welcome further
>     >     data (such as on the relative code footprint of core cryptographic
>     >     primitives vs. protocol integration for COSE/cTLS/etc.).
>     >     
>     >     We also feel that it’s appropriate to find a home for work on cTLS to come
>     >     to fruition.  As noted during the BoF, this presents a multifaceted
>     >     problem, with input needed from TLS experts as to which parts of the
>     >     protocol are legacy artifacts vs. cryptographically necessary, and also
>     >     with input needed from domain experts on constrained devices as to which
>     >     protocol features are necessary and where to fall on the spectrum of
>     >     tradeoffs between fully general/full-featured and a stripped-down,
>     >     bare-bones feature set.  On the balance, though, it seems that discussion
>     >     of a general-purpose-but-compact TLS would be most effectively done in the
>     >     TLS WG with additional input and collaboration as needed.  We plan to ask
>     >     the TLS WG if there is interest in rechartering to take on this
>     >     “constrained TLS” work item (and we note that this includes thinking about
>     >     whether it is best done as a standalone specification or a “patch” or
>     >     “filter” to stock TLS that could apply to multiple TLS versions).
>     >     
>     >     For the sake of facilitating discussion, we include draft charter text for
>     >     the OSCORE case, modified based on input from the BoF from the version that
>     >     was previously sent to secdispatch@ietf:
>     >     
>     >     ==[ CHARTER ]==
>     >     Problem
>     >     
>     >     Constrained environments using OSCORE in network environments such as
>     >     NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key
>     >     exchange (LAKE) that enables forward security.  'Lightweight' refers to:
>     >     
>     >       * resource consumption, measured by bytes on the wire, wall-clock time to
>     >         complete, or power consumption
>     >       * the amount of new code required on end systems which already have an
>     >         OSCORE stack
>     >     
>     >     Goals
>     >     
>     >     This working group is intended to be a narrowly focused activity
>     >     intended to produce at most one LAKE for OSCORE usage and close.
>     >     
>     >     The working group will collaborate and coordinate with other IETF WGs
>     >     such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the
>     >     requirements and solution.  The WG will also evaluate work from
>     >     the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.
>     >     
>     >     Program of Work
>     >     
>     >     The deliverables of this WG are:
>     >     
>     >     1. Design requirements of the lightweight authenticated key exchange
>     >     protocol for OSCORE (this draft will not be published as an RFC but will be
>     >     used to drive WG consensus on the deliverable (2)
>     >     
>     >     2. Specify a lightweight authenticated key exchange protocol suitable for
>     >     use in constrained environments using OSCORE
>     >     ==[ CHARTER ]==
>     >     
>     >     Thanks,
>     >     
>     >     Ben and Roman
>     >     
>     >     [0]  For example, the total number of key exchange operations expected to
>     >     be performed over the lifetime of the device, as might be compared against
>     >     the total lifetime energy budget; and a request to make explicit what had
>     >     previously been implicit assumptions about the cost of various operations
>     >     (on various axes).
>     >     
>     >     -- 
>     >     Lake mailing list
>     >     Lake@ietf.org
>     >     https://www.ietf.org/mailman/listinfo/lake
>     >     
>     > 
>     > _______________________________________________
>     > Secdispatch mailing list
>     > Secdispatch@ietf.org
>     > https://www.ietf.org/mailman/listinfo/secdispatch
>     
>