Re: [Lake] LAKE next steps
Rene Struik <rstruik.ext@gmail.com> Tue, 27 August 2019 03:21 UTC
Return-Path: <rstruik.ext@gmail.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 3B1E81200F9; Mon, 26 Aug 2019 20:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RLLtDIEfSrkD; Mon, 26 Aug 2019 20:21:15 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 2487F1200C4; Mon, 26 Aug 2019 20:21:15 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id o9so42819582iom.3; Mon, 26 Aug 2019 20:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=iomDelqHriRuTCFkrUv4NLPM1mkve6YwECWc5zC3HJw=; b=Z0SRXem2Jq0ehB0/NCiWrdNBDgVxWwSMMd80N24itdpy2m7lSrxG4e05c63YPw0bn7 VbvULbmV0QK3RKbaVjVywyE+AhsE7LaKldfSzIrMkoXVovZVQ1vjK42qNVRn2bcqF2tK iKv6SgD73tlWaDsP0g3thbrSK+FDjPT4LzQyThTwRpGVMmk/g1Vy7zkpvHcKnVYpyvWq 8Las4M0My5D/MORelTEIBJDyBu6gbROhounlZ44JQV4DxafcjzG/sSQcUneKr6rdYRAX ggO80+BNRzzF5+Iom2YpkI2XuA+JR2Pa7zD6H9zduSSirsYvTd5yW34+bQ6VlJraVTTl MWjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iomDelqHriRuTCFkrUv4NLPM1mkve6YwECWc5zC3HJw=; b=gNiZ1ps2OfNKWzKkw9PQBWlF4VQI4I08DOb2Ks5j7XJlnIsUxCtGTGsOmgFg3ykuM0 NrHo3A1L9INK2W/MfBnNq0nGjbrsTaZXsHby9LV5KpPz1d/uDEMQXDCZ6b8qH4eCbYu7 g2djq2fSrRL7utaeIAjAzVfkm6wFORuM+9ueErgq+qx4AbPfOUzJk3v8ptX542HHGxE1 zXA/lTRD/JYL3oi4YchVx499TX4R1XiaKz2oEGeaaAmujp6TN0cd/3d3GQmN81xoYwqm tq9PXIopURJUhK7UEqGdyOOQpnEtJa/ogT5z/v/jMWI2rBg8NJdf4UDbtifWu5tn6Kuu dHqQ==
X-Gm-Message-State: APjAAAXPBgNmp/iefwFYSciSS2De2DsceAhvBqHEWhGWdelzwBtgM+at 1N8cvxysVv2AcTLdm10aUswK8IWw
X-Google-Smtp-Source: APXvYqwQsPJwfo5W9GAwZ1aCqTTcucUNVJJo7EKuCorPb+yzvS068s9xpe8v5ds2Zq5Pc0VzW0ZrrQ==
X-Received: by 2002:a02:3004:: with SMTP id q4mr20972376jaq.55.1566876074244; Mon, 26 Aug 2019 20:21:14 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:e464:d5e4:bbba:7a41? ([2607:fea8:69f:f5eb:e464:d5e4:bbba:7a41]) by smtp.gmail.com with ESMTPSA id h3sm16976228iof.65.2019.08.26.20.21.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 20:21:09 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: lake@ietf.org, secdispatch@ietf.org
References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com>
Date: Mon, 26 Aug 2019 23:21:06 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190826202430.GL84368@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/FcW1jen-gRaU_ZeON7B_6-wL5XI>
Subject: Re: [Lake] 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: Tue, 27 Aug 2019 03:21:17 -0000
On 8/26/2019 4:24 PM, Benjamin Kaduk wrote: > On Tue, Aug 20, 2019 at 12:13:18PM -0400, Rene Struik wrote: >> Hi Ben: >> >> From the discussion at the LAKE BoF, it seemed there was strong support >> [1] for also tackling the broader scenario (triggered by David Thaler's >> suggested dichotomy at the microphone). >> >> I have some trouble seeing suggested next steps on tackling this broader >> problem in you email below. If you could elaborate on how you see this >> broader topic ("general purpose lightweight AKE") find a home in terms >> of next steps, that would be great. (In my mind, this is not simply "TLS >> with compressed representation".) > I think we also heard, in addition to the generic "broader problem" hum, > several explicit statements at the mic about how a reduced-encoding > "compact TLS" was a good thing, and that having the LAKE discussions may > have been the trigger needed to make that happen. So yes, my thinking was > mostly "TLS with compressed representation" and possibly some additional > tweaks that are TBD. Could you elaborate on your thinking for how the > general-purpose lightweight AKE would differ from "TLS with compressed > representation"? RS>> (Procedural.) I reread the draft minutes of the LAKE BoF and found 15-17 hands for OSCORE and 10-11 for the general case (i.e., both have sufficient critical mass). Enthusiasm for other options was not polled in the room; hence, my question. You seem to quote Carsten Bormann's remark at the mic (according to minutes), but there were many other remarks as well, and - arguably - one can cherry-pick any set of remarks to arrive at different conclusions. The chartering discussion itself, though, did focus on the "narrow" vs. "general" notion David Thaler brought to the table and which was discussed in the latter part of the BoF meeting. BTW - I still do not understand how TLS with a compressed encoding scheme could be considered general. <<RS RS>> (Technical.) It would be prudent for IETF not to put too many eggs in the same basket and, thereby, not have most protocols share the same crypto design philosophy, protocol flow framework, and instantiation. While arguably convenient, this is contrary to algorithm agility requirements (since results in in-tandem vulnerabilities and easily ossified code). Hence, my case for not loosing sight of addressing the more general problem, with an open mind. I am willing to contribute to this and so are 10 others (according to the hum). Arguably, this general case cannot presume the Client/Server model, nor semi-infinite resources on one of the entities. This being said, this is not a blank slate area and closure on fundamental design can be reached in a reasonable, limited time frame by experienced people. <<RS > > Thanks, > > Ben > >> Best regards, Rene >> >> [1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]): >> Is OSCORE Key exchange a ('15-the narrow') problem that needs being solved? >> strong on yes, none on negative question >> Is broader constrained scenario a problem that needs solving? >> strong on yes, low on no [added from minutes] Willing to work on documents - comment, review, etc. - 15-17 hands for OSCORE - 10-11 hands for the general case - Few overlapping. -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [Lake] LAKE chartering discussion Michael Richardson
- [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] LAKE next steps Rene Struik
- Re: [Lake] LAKE next steps Martin Thomson
- Re: [Lake] LAKE chartering discussion Benjamin Kaduk
- Re: [Lake] LAKE next steps Göran Selander
- Re: [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Eric Rescorla
- Re: [Lake] LAKE next steps Rene Struik
- Re: [Lake] [Secdispatch] LAKE next steps Göran Selander
- Re: [Lake] LAKE next steps Yoav Nir
- Re: [Lake] [Secdispatch] LAKE next steps Phillip Hallam-Baker
- Re: [Lake] LAKE next steps Rene Struik
- Re: [Lake] [Secdispatch] LAKE next steps Benjamin Kaduk
- Re: [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Göran Selander
- Re: [Lake] [Secdispatch] LAKE next steps Michael Richardson