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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 30 March 2020 23:50 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 3A68C3A15D7 for <lake@ietfa.amsl.com>; Mon, 30 Mar 2020 16:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5uEarVaq5qI for <lake@ietfa.amsl.com>; Mon, 30 Mar 2020 16:50:07 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id 119643A15D4 for <lake@ietf.org>; Mon, 30 Mar 2020 16:50:06 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EDE423897A for <lake@ietf.org>; Mon, 30 Mar 2020 19:48:30 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C12AE451 for <lake@ietf.org>; Mon, 30 Mar 2020 19:49:59 -0400 (EDT)
To: lake@ietf.org
References: <b7c084b0-8489-5c05-046d-33aa70c85b94@cs.tcd.ie> <191b7e3c-4453-a60c-7d5d-07a051e8b85e@cs.tcd.ie> <CABcZeBNNaXTwLufkECD33X=XVz3PQ=of8uiCgfE1bQAZYhW9_A@mail.gmail.com> <F573B01F-9E0C-4CCB-B555-4FFE84F30A49@ericsson.com>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <5bad9e82-c25f-dc3d-a99b-e32228d2ac06@sandelman.ca>
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: <F573B01F-9E0C-4CCB-B555-4FFE84F30A49@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/-gAsgNFdTbkNJhdHkArfUU924-0>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01
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: 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".