Re: [Lake] edhoc end game: detailed plan

Sean Turner <> Thu, 01 December 2022 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9505AC14F722 for <>; Thu, 1 Dec 2022 09:00:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vNEduQ_b_EzY for <>; Thu, 1 Dec 2022 09:00:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id D350BC14F6E5 for <>; Thu, 1 Dec 2022 09:00:13 -0800 (PST)
Received: by with SMTP id u10so1743159qvp.4 for <>; Thu, 01 Dec 2022 09:00:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xiMc5MIJrEPBXuigN5d/NgOmFUYNBJYAxatWuqnQFf4=; b=LlqWUOlPXGosQ8QJ3ydHsC2ag0hsGSgB5t7lAX5hPQof+I7t4VZMsp4udLkoi43+yL h4C9j8H4SLS0ago6PQe7WRvaMotKdeg3blz5hMfcX4koEXfOu/szUefFRc9L2eVZHtYs iMTjv5gu/XKzWRJCjaMElvY7XQ3mtcidV6onE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xiMc5MIJrEPBXuigN5d/NgOmFUYNBJYAxatWuqnQFf4=; b=a1L3uG8cv0iX3VVFGog7NWvAFY+fhu9lBV9XHWP12sJ2J3s7TzaK10n6Qcbi23iFUV b2ETG2g1VxeasUG8HL0igTJETZGGjltbxSVEeP95sgLDRBO2IjnsqVZ2aK5bvsJydIqr bNxBnqmMNhtuKTUUGUFKvZ9lYj2GOqHrvHRzzo6ySayKrsy860t2gTikDjWxMJdvBvaM vmEaB4FAKCXYn3JDHFdhHelnE3SfT48M+ljJMBboczNsP/XCNjJW3i7TUlP3r+4u/cdR nf/XDymgfMyKS83QqOBUR2qfJ4M6aIIJ7ZSM6m2tvREfanQjVw6+5Cm07qW4Fi+fV7bf BopQ==
X-Gm-Message-State: ANoB5plR3BhGr5THBpaEGkUGqWqsxIw9awROeOygiKs6PUmycjNT3HaU 6ItU4Fkc5QnRmh7inviR3Jh06mRqcLJibA==
X-Google-Smtp-Source: AA0mqf6oWVvitG5xYOfBWGL7wG1/l4JxnFSzRJYXYxX79nMDj7VMDEcTqYDFMppFNAixtO1OcG1zSg==
X-Received: by 2002:a0c:c705:0:b0:4bb:615d:7237 with SMTP id w5-20020a0cc705000000b004bb615d7237mr52746699qvi.21.1669914012597; Thu, 01 Dec 2022 09:00:12 -0800 (PST)
Received: from ([2600:4040:253b:7300:b489:5535:66:d52]) by with ESMTPSA id bs21-20020ac86f15000000b003a5c6ad428asm2786581qtb.92.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2022 09:00:12 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Sean Turner <>
In-Reply-To: <>
Date: Thu, 01 Dec 2022 12:00:11 -0500
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lake] edhoc end game: detailed plan
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2022 17:00:17 -0000

Sorry if I’ve missed this in another email, but is the plan to close the WG (not the list) once EDHOC is published as an RFC?


> On Nov 29, 2022, at 16:43, Stephen Farrell <> wrote:
> Signed PGP part
> Hi all,
> This is to confirm the plan for finishing edhoc as was agreed
> at IETF 115, but now with a few more concrete steps having
> been taken, so more detail "filled in"...
> Just to reprise the overall process here:
> - We're done with WGLC but have a few things to finalise (see
>  below); once those are handled (hopefully by Monday) the
>  chairs plan to hit the "publication requested" button which
>  means asking our area director (AD) to proceed towards an
>  IETF last call
> - Our AD (Paul) will likely want to do his own review as well
>  before he starts that IETF last call, and there can be a
>  bit of delay on that depending how busy the AD happens to
>  be at the time (they really do lead busy lives:-)
> - IETF last call (LC) is a two week period where IETF
>  participants who've not been engaged with the WG are
>  invited to comment. (Such comments are a good thing that
>  often improve drafts a lot or catch non-obvious things)
> - When IETF LC spans a holiday period, those are often
>  extended to 4 weeks or so (because we do want to get those
>  comments)
> - In parallel, we'll start getting directorate reviews (i.e.
>  secdir review etc)
> - Once all IETF LC comments etc are handled then we'll be
>  asking our AD to put the draft on an IESG agenda for
>  approval, generating more IESG comments we'll need to
>  handle, after which it'll head to the RFC editor queue
>  and then it'll pop out as an RFC a couple of months
>  later
> So there's a way to go, but we're near the end of the WG's
> work on edhoc nonetheless as all those steps tend to take
> a *lot* less time than things have taken so far.
> So, the immediate specifics:
> Draft-18 [1] should include all the WGLC comment resolutions
> as agreed at IETF 115 and/or discussed subsequently on the
> list or in github. Please review the diff [2] to check that
> the editors have done that correctly in your view.
> We also agreed at IETF 115 to give some people a chance to
> propose a PR with a state machine description. We now have
> that at [3] and need to decide to include it as an appendix
> (so that'd go in a draft-19) or to leave that out for now
> and maybe include it in another draft (such as [4]). The
> sense of the WG I think was to include it if it's clearly
> correct but leave it out for now if we're not sure. Let's
> try decide that by the end of week, (before the end of
> Dec 4th), so please say if you'd like that PR merged or not.
> (If there's ambiguity that'd take a while to fix, I'd ask
> you to consider suggesting we omit it rather than wait,
> my reasoning for that being that if we wait, other stuff
> will turn up that needs more discussing...;-)
> Meanwhile, please do also take the opportunity to do more
> reviews of [1] - we can still treat any/all suggestions as
> IETF last call comments. (But please don't re-raise any
> issues already resolved in the WG.)
> Mališa will be acting as document shepherd, so he'll be
> helping our capable authors negotiate the above steps. I'll
> be doing another chair-review of the draft before Monday
> as well. (Any nits from that can be handled during or
> after IETF LC though.)
> With a bit of luck we may get IETF LC done by the very
> early new year, but that depends on our AD's queue and
> his doing his own review of the draft, so we'll have to
> wait and see how the timing goes.
> Now... isn't that all very simple? :-)
> Cheers,
> Stephen.
> [1]
> [2]
> [3]
> [4]
> <OpenPGP_0x5AB2FAF17B172BEA.asc>