Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Michael Richardson <> Mon, 30 March 2020 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A68C3A15D7 for <>; Mon, 30 Mar 2020 16:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y5uEarVaq5qI for <>; Mon, 30 Mar 2020 16:50:07 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 119643A15D4 for <>; Mon, 30 Mar 2020 16:50:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EDE423897A for <>; Mon, 30 Mar 2020 19:48:30 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id C12AE451 for <>; Mon, 30 Mar 2020 19:49:59 -0400 (EDT)
References: <> <> <> <>
From: Michael Richardson <>
Message-ID: <>
Date: Mon, 30 Mar 2020 19:49:59 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Mar 2020 23:50:09 -0000

On 2020-03-24 12:42 p.m., Göran Selander wrote:
>     The main objective with this work is to create a simple yet secure
>     AKE.  The AKE should avoid having multiple ways to express the same
>     thing.  When the underlying encodings offered by CBOR offer multiple
>     possibility the AKE should be strongly opinioniated, and clearly
>     specify which one will be used.
> This seems to assume that CBOR will be used, but that's not decided.
> GS: This text was suggested by Michael. Changed “when” to “if”.
>     While remaining extensible, the AKE should avoid optional mechanisms
>     which introduce code paths that are less well tested.
> I don't think this is a requirement that is actionable.
> GS: Michael?

I basically don't want us to include extension mechanisms that we don't 
know how we will use.

>     The AKE should avoid mechanisms where an initiator takes a guess at
>     the policy, and when it receives a negative response, must guess,
>     based upon what it has tried, what to do next.
> I don't agree with this at all, and I'm not sure why this is
> here. There are good reasons to do this. In fact, it's the main way to
> get a three message protocol with confidentiality for the server's
> first flight.
> GS: This text was suggested by Michael. Just noting a potential 
> difference in what you say: Michael’s text speaks about initiator 
> guessing twice. In your example that is not the case, right?

If the initiator guesses wrong, then the responder should say what they 
support.  Contrast IKEv1 "aggressive mode".