From nobody Wed Aug 7 05:22:50 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88A12001B for ; Wed, 7 Aug 2019 05:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rJ-EJ-5cvDqr for ; Wed, 7 Aug 2019 05:22:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF53120090 for ; Wed, 7 Aug 2019 05:22:44 -0700 (PDT) Received: from [192.168.1.17] (ppp-94-69-228-26.home.otenet.gr [94.69.228.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EB8158513E; Wed, 7 Aug 2019 14:22:42 +0200 (CEST) References: <7973027D-7548-446D-9F88-D7863514C177@sinodun.com> To: IETF SecDispatch From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== X-Forwarded-Message-Id: <7973027D-7548-446D-9F88-D7863514C177@sinodun.com> Message-ID: <48be70b0-faea-6cf6-4593-a6f6cc158492@gont.com.ar> Date: Wed, 7 Aug 2019 15:09:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <7973027D-7548-446D-9F88-D7863514C177@sinodun.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Secdispatch] Fwd: [Pearg] Call for Adoption: Two drafts on Numeric IDs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 12:22:48 -0000 FYI -------- Forwarded Message -------- Subject: [Pearg] Call for Adoption: Two drafts on Numeric IDs Date: Wed, 7 Aug 2019 12:56:35 +0100 From: Sara Dickinson To: pearg@irtf.org Hi All, There are currently 3 drafts related to Numeric IDs that have been discussed on various IETF/IRTF lists: * https://tools.ietf.org/html/draft-gont-numeric-ids-history * https://tools.ietf.org/html/draft-gont-numeric-ids-generation * https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations This email starts a two week Call for Adoption for two of these drafts which have been proposed as suitable work for PEARG: 1) Unfortunate History of Transient Numeric Identifiers: https://tools.ietf.org/html/draft-gont-numeric-ids-history-05 2) On the Generation of Transient Numeric Identifiers: https://tools.ietf.org/html/draft-gont-numeric-ids-generation-04 Please review both these draft to see if you think they are suitable for adoption by PEARG and send comments to the list, clearly stating your view. ** Because they are so closely related, we are requesting that people send an initial single response to this email but state their opinion separately for each of the above drafts in that response ** Note that the third draft is currently in the IETF stream as an AD sponsored submisssion. This call for adoption ends on 21st August 2019. Sara. -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Aug 7 19:44:17 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B15120033 for ; Wed, 7 Aug 2019 19:44:16 -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 6JDzaIEl8D74 for ; Wed, 7 Aug 2019 19:44:13 -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 451E5120091 for ; Wed, 7 Aug 2019 19:44:13 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id AB69E3818D; Wed, 7 Aug 2019 22:43:33 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 05431479; Wed, 7 Aug 2019 22:44:11 -0400 (EDT) To: Kathleen Moriarty , secdispatch@ietf.org References: From: Michael Richardson Message-ID: Date: Wed, 7 Aug 2019 22:44:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.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: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 02:44:17 -0000 On 2019-07-22 10:28 a.m., Kathleen Moriarty wrote: > Hi David, > > Could you please explain how this is different from the adopted work in > I2NSF, > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ ? > > This is referenced in your draft along with one another, but there is no > analysis on why they don't fit the need.  The draft in I2NSF pulled in > the IPsecMe working group and underwent significant revisions as a > result to deal with several initial security issues.  If there 's a gap > that can be solved with that draft, could that be a way forward or is > this needed for some specific reason?  It would be helpful to understand > this. I read David's response. I'm still unclear if I2NSF turned down this work or what? Is there a conclusion from secdispatch at this point? From nobody Wed Aug 7 22:17:09 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C179A12004A for ; Wed, 7 Aug 2019 22:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VSxLod57o1Gl for ; Wed, 7 Aug 2019 22:17:05 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 3CAC112000E for ; Wed, 7 Aug 2019 22:17:05 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id n11so90878092qtl.5 for ; Wed, 07 Aug 2019 22:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=in-reply-to:references:thread-topic:user-agent:mime-version :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=V8gyVSE/65XmPq7pxZH1ORcytPjFZu6YsdrUXUwOkqc=; b=BmnzAP2W3ejnW2NAT8g7ODBi0WwoxVY5f2lBwZryUMDyeZ8MnPQqdsPEghwnjIFctn x6z1FN3W+F5pO/6/U5+/kHuRWjKbGwRktP97yZs7EpcfeEGMVsJqHaciiEvZhICU1FJW G8qG0+2yKpa/l3ynJHqAHB5halWLVVKiJ8mwxFap5xOMpkUk9gLJZfBneZ4vDtVZUCjK nsvyP6QjRQ1FwsWleCF1FzF6dJXNgT2Wer3sAJqjE31rR0rFMVgVlTd0RtaoRW+VxPtE 04ALEb+Fi4Kzt2mtY/FK7kVNIwlj6ZjGD3DiOmkbJMrq8IjFU0L/BYsEtc4+y83D1iJi BlEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:in-reply-to:references:thread-topic:user-agent :mime-version:content-transfer-encoding:subject:from:date:to:cc :message-id; bh=V8gyVSE/65XmPq7pxZH1ORcytPjFZu6YsdrUXUwOkqc=; b=aNvAYNfRo3G+5WA1A+zoacZY/U9Lm5fciwRdwDFdWd4O6gQ/B2BZpc+qNiATv7tAyE leSNhGTnV2WX9P+240OxtU4l226FqFmsCfJPwn4u24z8ANXXeCuBsupLgaGw8qCq6Jh+ s0sqMQ9dqgWNg89/7KjvaF2dnYBNdWWa3+tFeNL5CO5cYKhazxdDC1YxRJhMZWyfvkav s8Vhg80Hi2SxMsMMAEnZ3H6J2L35wQO8EAczWDYqNWwrSbvGiedKuvLhOiKPWx6bljz3 S4vgG4rjlymHivo08tjAxDf2Qzt8RemTmnI14vlgilMPvGjI33+ezfLIRi0uHQKOnWj9 DWeQ== X-Gm-Message-State: APjAAAUkLcuYrPYpSFPUnT9DocoLT9LzMagxXaZwTrl0wggMMQ7NyaI2 Ee8nhzAWdoCQkyIoaLtogL4= X-Google-Smtp-Source: APXvYqwlx7eCc1kVpjKtcIMdniU4TybY9qz8vtjWk9WYTrDO6ncBd39/LTfkewzL7uzCuWoltHgrnA== X-Received: by 2002:a0c:d0ab:: with SMTP id z40mr11831747qvg.216.1565241424230; Wed, 07 Aug 2019 22:17:04 -0700 (PDT) Received: from [10.41.8.158] ([147.178.6.137]) by smtp.gmail.com with ESMTPSA id p23sm41010529qke.44.2019.08.07.22.17.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 22:17:02 -0700 (PDT) In-Reply-To: References: X-Referenced-Uid: 67274 Thread-Topic: Re: [Secdispatch] Controller-IKE User-Agent: Android X-Is-Generated-Message-Id: true MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----K6I3GCZE17XLTPAN1CK461TDGLO7RL" Content-Transfer-Encoding: 7bit X-Local-Message-Id: From: Yoav Nir Date: Thu, 08 Aug 2019 08:16:58 +0300 To: Michael Richardson CC: Kathleen Moriarty ,secdispatch@ietf.org Message-ID: Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 05:17:08 -0000 ------K6I3GCZE17XLTPAN1CK461TDGLO7RL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi, Michael I2NSF did turn down this draft=2E Ultimately it just didn't= get enough support for adoption, but one of the arguments against it was t= hat it was a middle ground between the IKE and IKE-less cases=2E =E2=81= =A3Sent from my phone =E2=80=8B -------- Original Message -------- From: = Michael Richardson Sent: Thu Aug 08 05:44:10 GMT+= 03:00 2019 To: Kathleen Moriarty , = secdispatch@ietf=2Eorg Subject: Re: [Secdispatch] Controller-IKE On 2019-0= 7-22 10:28 a=2Em=2E, Kathleen Moriarty wrote: > Hi David, > > Could you pl= ease explain how this is different from the adopted work in > I2NSF, > ht= tps://datatracker=2Eietf=2Eorg/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/=C2=A0? > > This is referenced in your draft along with one another, bu= t there is no > analysis on why they don't fit the need=2E=C2=A0 The draft= in I2NSF pulled in > the IPsecMe working group and underwent significant = revisions as a > result to deal with several initial security issues=2E=C2= =A0 If there 's a gap > that can be solved with that draft, could that be = a way forward or is > this needed for some specific reason?=C2=A0 It would= be helpful to understand > this=2E I read David's response=2E I'm still = unclear if I2NSF turned down this work or what? Is there a conclusion from = secdispatch at this point? _______________________________________________= Secdispatch mailing list Secdispatch@ietf=2Eorg https://www=2Eietf=2Eorg/m= ailman/listinfo/secdispatch ------K6I3GCZE17XLTPAN1CK461TDGLO7RL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi, Michael

I2NSF did turn down this draft=2E

Ultimately it just didn't get enough support for adoption, but one of = the arguments against it was that it was a middle ground between the IKE an= d IKE-less cases=2E

= Sent from my phone
= From: Michael Richardson
Sent:= Thu Aug 08 05:44:10 GMT+03:00 2019
To: Kathleen Moriarty , secdispatch@ietf=2Eorg
Subject:<= /b> Re: [Secdispatch] Controller-IKE

On 2019-07=
-22 10:28 a=2Em=2E, Kathleen Moriarty wrote:
 Hi David,
 
 Could you please explain how this=
 is different from the adopted work in 
 I2NSF, 
 ht=
tps://datatracker=2Eietf=2Eorg/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti=
on/ ?
 
 This is referenced in your draft along with one ano=
ther, but there is no 
 analysis on why they don't fit the need=2E =
 The draft in I2NSF pulled in 
 the IPsecMe working group and underwent =
significant revisions as a 
 result to deal with several initial securit=
y issues=2E  If there 's a gap 
 that can be solved with that draft=
, could that be a way forward or is 
 this needed for some specific reas=
on?  It would be helpful to understand 
 this=2E
I read David's response=2E
I'm still unclear if I2NSF turned down this=
 work or what?
Is there a conclusion from secdispatch at this point?
=


Secdispatch mailing list
Secdispatch@ietf=2Eorg
https://www=2Eie=
tf=2Eorg/mailman/listinfo/secdispatch
------K6I3GCZE17XLTPAN1CK461TDGLO7RL-- From nobody Tue Aug 20 08:50:24 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7D120985; Tue, 20 Aug 2019 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 w5S5a0Hketqn; Tue, 20 Aug 2019 08:50:12 -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 793D3120986; Tue, 20 Aug 2019 08:50:12 -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 x7KFo7OC006446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Aug 2019 11:50:10 -0400 Date: Tue, 20 Aug 2019 10:50:07 -0500 From: Benjamin Kaduk To: lake@ietf.org Cc: secdispatch@ietf.org Message-ID: <20190820155006.GE60855@kduck.mit.edu> Reply-To: lake@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Secdispatch] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 15:50:16 -0000 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). From nobody Tue Aug 20 09:13:32 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD27D1200EB; Tue, 20 Aug 2019 09:13:23 -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 8HekehnDU98Z; Tue, 20 Aug 2019 09:13:22 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 E5DAC12095B; Tue, 20 Aug 2019 09:13:21 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id t6so13349951ios.7; Tue, 20 Aug 2019 09:13:21 -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=aPge+sF9H+Hd3mvf6hZb+KecI9yb8qJSxSMM5xnT+Qo=; b=aQPHY0vyz8Rrzceivc4blnucTpTuSg7SPA6tUbAU3wpuVX2Ea5HghXkk93gi4dSEMg gejCAIHAvmiwpoSvsxJ3y9hKKm0/vbQJgQr2IFQ7MLk0eWI6ClSmNWzmrGuTzTNCmGXq cvRtyRoRUGzt3mcNVFzSnxjELXG4i33lEQSFS2Nqz847fALaDinfF2DcpGqEzQ3EpboR 6osJzET+NTbB0/9+StKLTWrUxWY1M26sd5ahWPI54KzJWk8ux8Y/wecEZmy3dc5CKi6k mFrzGjhSmC9+E5W0WbmcfwDLQikLghC6nE8K7H/que6bNNFYq9vjxmi/a6yub94GVfIP 2RQA== 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=aPge+sF9H+Hd3mvf6hZb+KecI9yb8qJSxSMM5xnT+Qo=; b=Ny70cOwYqCtx3KzpnM84rpU4ecut2c7cle54c5XC0KPa04moNF3TIXEethzBJ3WTCz VmtjrB3M15gI2k6Z4gqyn5oZuA4e1hrctEJvAltxb5vbvnlo1AnJ7mpjdXA2yk/Fk/2m avoP/38E97mu803lrEkk/ax/H2B2bo0xOljIYR/V5MA7sPb5f6je7BS6bWaz6n/nibW4 oBgWIj6ZmM11JVgHLAOPIzxD++dss8fUa2lTSNZLo5hipEubif+tiXgudAtTh04piFen yVqTk7Gp5kB9Pf8W66E1VLtjBMvpkfpRIPV9EFn4MByh5cPycIH/Bec1NxE0DlRFtxyK R5/A== X-Gm-Message-State: APjAAAUoquk8c0qLfoVsXTN6WLbPQ3R4lSRtSTsK3Vybr3yj9NAuFyM/ 2ifobuUasRco/paNGyxJ50d9l5bc X-Google-Smtp-Source: APXvYqyJb3O7xb95XViI2CyM3srR9wxX9KpPQq1GYb/AfqYZP4yjB4xiaixRYP4yToGpOGV2b1o9vg== X-Received: by 2002:a6b:917:: with SMTP id t23mr25782809ioi.174.1566317600982; Tue, 20 Aug 2019 09:13:20 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id q12sm17173351ioh.8.2019.08.20.09.13.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Aug 2019 09:13:20 -0700 (PDT) To: lake@ietf.org, Benjamin Kaduk Cc: secdispatch@ietf.org References: <20190820155006.GE60855@kduck.mit.edu> From: Rene Struik Message-ID: <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> Date: Tue, 20 Aug 2019 12:13:18 -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: <20190820155006.GE60855@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 16:13:24 -0000 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".) Best regards, Rene [1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]): Is OSCORE Key exchange a ('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 On 8/20/2019 11:50 AM, Benjamin Kaduk 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). > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Aug 22 06:27:57 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E9120103; Thu, 22 Aug 2019 06:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ktFBi37nTwa2; Thu, 22 Aug 2019 06:27:51 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60051.outbound.protection.outlook.com [40.107.6.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7FD1200F8; Thu, 22 Aug 2019 06:27:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVFiPQMHPtmZAke93XPQJRdZL+h6YghZHNmYg3NYR+hrSlbH8iFthqMGyixeIbBZ3bjc6yOH89FC9ZnH067EPERXScV18ltdh/eATprf192f9qxnTAhKiWqG4S0NfAaFt3R70i33wLorFMsRd9JpdwAtE5rvwu+pEoGrRkIUtBYDTEvK+THEu/7QVPIeifum//baubJSB5juuCTRyGExs6BqQzQvzCwy9o4+MpqkY6ysI0qW40p8A01rTTjTyzcwYTC8bWV8lfPXUHSwRntB4Y3AH7KeXpTZ4poiGDDo9nxBTMGGVbJLCwmm7/XRThmyLrCJfYQ631KQH+L0ogAYVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dZQQsTpRTtgo4p1d7/P6MHF1wtgYlwC6sM+mCOBrD7c=; b=jhMlqaaGJ2CFdCvEDJ/l1NmkQNZKBfDin7Yj3JdriFJzJDGarl6KxoX0d5/WXxBm45RYG2DjyAxpHFjkAAYt9+gdm9B4PI2PS1aruERrKY07LF9hn7TIa5w1IwIkRkaufHS085uFbVIlmZFeiBrlLoDmEBrgraL8em6MJxp+ZJIF+qcmmN6GhrudNj+u0BJyEW5bGGORQ6OCucfHCVPncx0awiPHPbGaftfLrMds962tXZLM1AsKswiGkaIkS9LG7B/EjUo43ZUyc18qwkDw/EvLapUgblWMRbYqjp6kEKPyBaDYYTk8GFTQcq7ULlTcVY3cENcPGHiJWwf3ApRUFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dZQQsTpRTtgo4p1d7/P6MHF1wtgYlwC6sM+mCOBrD7c=; b=KdzRDMb7g6tXn7ieVfkkisyMghOQkyucSDDj8GNGqKSHyDVeGQEqy437mdjDR1s8cSAQIZEjtCACNjrzzGwCWmTK6QJE1CkuyHx0juMKXblCZyO069L26eyp+BuWCiCO7EwZfw0m7uKOx7W75uSfsZr3KSSfcX4gZJ7uhJKCpgM= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3177.eurprd07.prod.outlook.com (10.170.245.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.11; Thu, 22 Aug 2019 13:27:49 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d4e8:423d:955c:6a5e]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d4e8:423d:955c:6a5e%5]) with mapi id 15.20.2199.015; Thu, 22 Aug 2019 13:27:49 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "lake@ietf.org" CC: "secdispatch@ietf.org" Thread-Topic: [Lake] LAKE next steps Thread-Index: AQHVV27+G+o9nwDa0kKha2dOdkjTaKcHTXAA Date: Thu, 22 Aug 2019 13:27:49 +0000 Message-ID: References: <20190820155006.GE60855@kduck.mit.edu> In-Reply-To: <20190820155006.GE60855@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59e9009f-fe85-4fbe-7fd3-08d7270486e8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3177; x-ms-traffictypediagnostic: HE1PR07MB3177: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(189003)(199004)(14444005)(76176011)(316002)(33656002)(256004)(486006)(7736002)(305945005)(11346002)(446003)(71200400001)(85202003)(71190400001)(2351001)(5640700003)(6436002)(36756003)(4326008)(86362001)(2616005)(14454004)(450100002)(8936002)(85182001)(53936002)(6246003)(99286004)(25786009)(6306002)(6512007)(6486002)(6506007)(26005)(2501003)(66066001)(81156014)(81166006)(186003)(1730700003)(478600001)(8676002)(229853002)(6116002)(966005)(3846002)(2906002)(6916009)(64756008)(561944003)(66946007)(76116006)(66574012)(5660300002)(102836004)(66446008)(66556008)(476003)(58126008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3177; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DioXY6Eiq5otAnGBOjawkMIMVfeLDMEjCTNBpkeVeXDWExgFarp7iJDoJV7ZMVgnVpTjY++8Pouu0UQ9xmUZNJ/zZ2J4a88GNotqDtiGIwVkX/wMktDb0O/iDqNk9BCg9fu83sm9f7aON1ZvvEkFCJMtjys+fX6WCUA32VuNkiNJZ0VZXW6PupiWfn6o+Qpe5Cu1XyDo36ozEX7J8jcA8oH9Mb+fhknGZELpzxVHpIwCDIH6asE97pJqEx/9bIYxYGWTQw4yKcqKhn6ncXB93mshR4wpxJVu1eNIWldLaUmoa5eGE/NnU2t1MHZfZJl5nJtJsfezl2xcw/jrg0lVZ5nlsQ9/Li+fv0EsI9ACzmLZ5FcNz89F0/6xyrc4FZuStlgT6xN5mHkANjiJWMqV5igril4bl4RTKBn3dgsAqMo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2A123D0241221C4684D328395FB9326B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59e9009f-fe85-4fbe-7fd3-08d7270486e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 13:27:49.1863 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GY5toQUj2dp/x8NDHUyZUO8I+KPvgV5iwzza2xVUpmS1ddGDzGkR9GhTO1OtQIx017uzrYoRToM63V4lTT0N9zPNh4A8c+Jwh7fAxXGG+c4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3177 Archived-At: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 13:27:55 -0000 SGkgQmVuIGFuZCBSb21hbiwgDQoNCklmIEkgdW5kZXJzdGFuZCByaWdodCwgdGhlIHByb3Bvc2Fs IGlzIC0gaW4gb25lIHNlbnRlbmNlIC0gdG8gd29yayBib3RoIG9uIGEgbGlnaHR3ZWlnaHQgYXV0 aGVudGljYXRlZCBrZXkgZXhjaGFuZ2UgZm9yIE9TQ09SRSBpbiB0aGUgTEFLRSBXRywgYW5kIG9u IGEgY29tcGFjdCB2YXJpYW50IG9mIFRMUyBpbiB0aGUgVExTIFdHLiBUaGlzIHNvdW5kcyBsaWtl IGEgZ29vZCB3YXkgZm9yd2FyZCwgc2luY2UgYW4gb3B0aW1hbCBzb2x1dGlvbiB0byBvbmUgb2Yg dGhlIHByb2JsZW1zIGlzIG1vc3QgbGlrZWx5IG5vdCBvcHRpbWFsIChvciBldmVuIHN1aXRhYmxl KSBmb3IgdGhlIG90aGVyLCBhbmQgb3B0aW1pemF0aW9uIGlzIG9uZSBvZiB0aGUgcmVhc29ucyBm b3IgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KVGhlIHByb3Bvc2VkIGNo YXJ0ZXIgbG9va3MgZmluZSwgSSBvbmx5IGhhdmUgb25lIGNvbW1lbnQgb24gdGhlIHRleHQsIHNl ZSBiZWxvdy4gSW4gcGFydGljdWxhciBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBuZWVkIHRv IGZ1cnRoZXIgZGV0YWlsIHJlcXVpcmVtZW50cyBpbiB0aGUgY2hhcnRlciBzaW5jZSB0aG9zZSBj YW4gYmUgYWdyZWVkIHdpdGggdGhlIGxpc3RlZCBzdGFrZWhvbGRlcnMgYXMgcGFydCBvZiB0aGUg d29yay4NCg0KRXhjZXJwdCBmcm9tIHByb3Bvc2VkIGNoYXJ0ZXI6DQoNCidUaGUgd29ya2luZyBn cm91cCB3aWxsIGNvbGxhYm9yYXRlIGFuZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBXR3MN CnN1Y2ggYXMgQUNFLCBDT1JFLCA2VElTQ0gsIGFuZCBMUFdBTiB0byB1bmRlcnN0YW5kIGFuZCB2 YWxpZGF0ZSB0aGUNCnJlcXVpcmVtZW50cyBhbmQgc29sdXRpb24uICBUaGUgV0cgd2lsbCBhbHNv IGV2YWx1YXRlIHdvcmsgZnJvbQ0KdGhlIFRMUyBXRyBhbmQgZGVyaXZhdGl2ZXMgdGhlcmVvZiwg YW5kIGRyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlLicNCg0KTXkgY29tbWVudCBpcyBvbiB0 aGUgbGFzdCBzZW50ZW5jZSBhYm92ZS4gSSBhbHJlYWR5IGNvbW1lbnRlZCBvbiB0aGlzIHNlbnRl bmNlIGluIGEgcHJldmlvdXMgZHJhZnQgb2YgdGhlIGNoYXJ0ZXI6DQpodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoL3hKVGtPQTZ6ZlUwVGNRUE1ZZXZnOElC VVNWaw0KDQpBZGRpdGlvbmFsbHksIEkgZG9uJ3QgdGhpbmsgdGhpcyBzZW50ZW5jZSB3ZWxsIHJl ZmxlY3RzIHRoZSB0ZXh0IGluIHlvdXIgbWFpbDoNCg0KJ0Zyb20gd2XigJl2ZSBzZWVuIHNvIGZh ciwgRURIT0Mgc2VlbXMgbGlrZSB0aGUgbGVhZGluZyBjb250ZW5kZXIsIGVzcGVjaWFsbHkgd2l0 aCByZXNwZWN0IHRvIHRoZSDigJxyZXVzZSBvZiBDT1NFIGFsZ29yaXRobXPigJ0gcHJvcG9zZWQg cmVxdWlyZW1lbnQsIGJ1dCB3ZSBvZiBjb3Vyc2Ugd2VsY29tZSBmdXJ0aGVyIGRhdGEgKHN1Y2gg YXMgb24gdGhlIHJlbGF0aXZlIGNvZGUgZm9vdHByaW50IG9mIGNvcmUgY3J5cHRvZ3JhcGhpYyBw cmltaXRpdmVzIHZzLiBwcm90b2NvbCBpbnRlZ3JhdGlvbiBmb3IgQ09TRS9jVExTL2V0Yy4pLicN Cg0KRGV0YWlsZWQgY29tbWVudHM6DQoxLiBJdCBpcyBmaW5lIHRoYXQgdGhlIFdHIGFsc28gZXZh bHVhdGVzIHdvcmsgZnJvbSB0aGUgVExTIFdHLCB3aXRoIHRoZSBvYnZpb3VzIHJlc3RyaWN0aW9u IHRoYXQgb25seSBzb2x1dGlvbnMgdGhhdCBhcmUgcmVhZHkgYW5kIGNvbXBsaWVzIHdpdGggdGhl IHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIGV2YWx1YXRlZC4gQXMgbG9uZyBhcyB3ZSBhZ3JlZSBv biB0aGF0LCB0aGVyZSBpcyBubyBuZWVkIHRvIGNoYW5nZSB0aGUgY2hhcnRlciBvbiB0aGlzIHBv aW50LiANCjIuIFBsZWFzZSBtb3ZlICIsIGFuZCBkcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2Ro ZSIgZnJvbSB0aGlzIHNlbnRlbmNlIGFuZCBpbmNsdWRlIGl0IGluIGEgc2VudGVuY2UgYmVmb3Jl IHRoaXMgb25lIGluZGljYXRpbmcgdGhhdCBpdCBpcyBjdXJyZW50bHkgdGhlIG9ubHkgc3BlY2lm aWVkIEFLRSBmb3IgT1NDT1JFLiANCg0KVGhhbmtzDQpHw7ZyYW4NCg0KDQrvu79PbiAyMDE5LTA4 LTIwLCAxNzo1MCwgIkxha2Ugb24gYmVoYWxmIG9mIEJlbmphbWluIEthZHVrIiA8bGFrZS1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBrYWR1a0BtaXQuZWR1PiB3cm90ZToNCg0KICAgIFRo YW5rIHlvdSB0byBldmVyeW9uZSB3aG8gYXR0ZW5kZWQgdGhlIExBS0UgQm9GIHNlc3Npb24hIEl0 IHdhcyBhDQogICAgcHJvZHVjdGl2ZSBtZWV0aW5nIHRoYXQgaGlnaGxpZ2h0ZWQgdGhlIGNvbW11 bml0eeKAmXMgbmVlZHMgZm9yIHdvcmsgaW4gdGhpcw0KICAgIHNwYWNlLiAgQSBrZXkgaW5zaWdo dCB0aGF0IGVtZXJnZWQgZHVyaW5nIHRoZSBzZXNzaW9uIHdhcyB0aGF0IHRoZXJlIGlzIGENCiAg ICBmYWlybHkgY2xlYXIgc3BsaXQgYmV0d2VlbiB0aGUg4oCcQUtFIGZvciBPU0NPUkXigJ0gY2Fz ZSBhbmQg4oCcZ2VuZXJhbCBwdXJwb3NlDQogICAgbGlnaHR3ZWlnaHQgQUtF4oCdIGluIHRlcm1z IG9mIHRoZSBzZXQgb2YgcmVxdWlyZW1lbnRzLiAgV2UgYXJlIGhhcHB5IHRvIG5vdGUNCiAgICBh IHN0cm9uZyBsZXZlbCBvZiBpbnRlcmVzdCBpbiBhIFRMUy1iYXNlZCBzb2x1dGlvbiB0aGF0IHJl bW92ZXMgdW5uZWNlc3NhcnkNCiAgICBwcm90b2NvbCBmaWVsZHMgYW5kIGVuY29kaW5nIHJlZHVu ZGFuY3ksIHdoaWNoIGhhcyBzaWduaWZpY2FudCBwb3RlbnRpYWwNCiAgICBmb3IgdXNlIGluIHBy b3RvY29scyB0aGF0IGRvIG5vdCByZXF1aXJlIHRyYWRpdGlvbmFsIFRMUyBjcm9zcy12ZXJzaW9u DQogICAgY29tcGF0aWJpbGl0eSwgaW4gY29uc3RyYWluZWQgYW5kIGZ1bGwtZmVhdHVyZWQgZW52 aXJvbm1lbnRzIGFsaWtlLg0KICAgIExpa2V3aXNlLCB3ZSBzYXcgdGhhdCB0aGUgYWRkaXRpb25h bCBjb21tdW5pdHkgZW5nYWdlbWVudCBvZiBhIEJvRiB3YXMgYWJsZQ0KICAgIHRvIHByb3ZpZGUg bmV3IGluc2lnaHRzIGludG8gdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBhIExB S0UgWzBdLA0KICAgIGJvdGggaW4gdGhlIE9TQ09SRSBhbmQgdGhlIG1vcmUgZ2VuZXJhbCBjYXNl IC0tIHRoaXMgaXMgYSBncmVhdCBpbmRpY2F0aW9uDQogICAgb2YgdGhlIHZhbHVlIHByb3ZpZGVk IGJ5IHRoZSBicm9hZCBhbmQgY3Jvc3MtYXJlYSBJRVRGIHJldmlldyBwcm9jZXNzLg0KICAgIA0K ICAgIEJhc2VkIG9uIHRoZSBpbnB1dCByZWNlaXZlZCBhbmQgZW5lcmd5IGluIHRoZSByb29tLCB3 ZSBmZWVsIHRoYXQgaXTigJlzDQogICAgYXBwcm9wcmlhdGUgdG8gY2hhcnRlciBhIFdHIHRvIGZp bmlzaCBjb2FsZXNjaW5nIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0KICAgIE9TQ09SRSB1c2Ug Y2FzZSBhbmQgZXZhbHVhdGUgc29sdXRpb25zLiAgRnJvbSB3ZeKAmXZlIHNlZW4gc28gZmFyLCBF REhPQw0KICAgIHNlZW1zIGxpa2UgdGhlIGxlYWRpbmcgY29udGVuZGVyLCBlc3BlY2lhbGx5IHdp dGggcmVzcGVjdCB0byB0aGUg4oCccmV1c2Ugb2YNCiAgICBDT1NFIGFsZ29yaXRobXPigJ0gcHJv cG9zZWQgcmVxdWlyZW1lbnQsIGJ1dCB3ZSBvZiBjb3Vyc2Ugd2VsY29tZSBmdXJ0aGVyDQogICAg ZGF0YSAoc3VjaCBhcyBvbiB0aGUgcmVsYXRpdmUgY29kZSBmb290cHJpbnQgb2YgY29yZSBjcnlw dG9ncmFwaGljDQogICAgcHJpbWl0aXZlcyB2cy4gcHJvdG9jb2wgaW50ZWdyYXRpb24gZm9yIENP U0UvY1RMUy9ldGMuKS4NCiAgICANCiAgICBXZSBhbHNvIGZlZWwgdGhhdCBpdOKAmXMgYXBwcm9w cmlhdGUgdG8gZmluZCBhIGhvbWUgZm9yIHdvcmsgb24gY1RMUyB0byBjb21lDQogICAgdG8gZnJ1 aXRpb24uICBBcyBub3RlZCBkdXJpbmcgdGhlIEJvRiwgdGhpcyBwcmVzZW50cyBhIG11bHRpZmFj ZXRlZA0KICAgIHByb2JsZW0sIHdpdGggaW5wdXQgbmVlZGVkIGZyb20gVExTIGV4cGVydHMgYXMg dG8gd2hpY2ggcGFydHMgb2YgdGhlDQogICAgcHJvdG9jb2wgYXJlIGxlZ2FjeSBhcnRpZmFjdHMg dnMuIGNyeXB0b2dyYXBoaWNhbGx5IG5lY2Vzc2FyeSwgYW5kIGFsc28NCiAgICB3aXRoIGlucHV0 IG5lZWRlZCBmcm9tIGRvbWFpbiBleHBlcnRzIG9uIGNvbnN0cmFpbmVkIGRldmljZXMgYXMgdG8g d2hpY2gNCiAgICBwcm90b2NvbCBmZWF0dXJlcyBhcmUgbmVjZXNzYXJ5IGFuZCB3aGVyZSB0byBm YWxsIG9uIHRoZSBzcGVjdHJ1bSBvZg0KICAgIHRyYWRlb2ZmcyBiZXR3ZWVuIGZ1bGx5IGdlbmVy YWwvZnVsbC1mZWF0dXJlZCBhbmQgYSBzdHJpcHBlZC1kb3duLA0KICAgIGJhcmUtYm9uZXMgZmVh dHVyZSBzZXQuICBPbiB0aGUgYmFsYW5jZSwgdGhvdWdoLCBpdCBzZWVtcyB0aGF0IGRpc2N1c3Np b24NCiAgICBvZiBhIGdlbmVyYWwtcHVycG9zZS1idXQtY29tcGFjdCBUTFMgd291bGQgYmUgbW9z dCBlZmZlY3RpdmVseSBkb25lIGluIHRoZQ0KICAgIFRMUyBXRyB3aXRoIGFkZGl0aW9uYWwgaW5w dXQgYW5kIGNvbGxhYm9yYXRpb24gYXMgbmVlZGVkLiAgV2UgcGxhbiB0byBhc2sNCiAgICB0aGUg VExTIFdHIGlmIHRoZXJlIGlzIGludGVyZXN0IGluIHJlY2hhcnRlcmluZyB0byB0YWtlIG9uIHRo aXMNCiAgICDigJxjb25zdHJhaW5lZCBUTFPigJ0gd29yayBpdGVtIChhbmQgd2Ugbm90ZSB0aGF0 IHRoaXMgaW5jbHVkZXMgdGhpbmtpbmcgYWJvdXQNCiAgICB3aGV0aGVyIGl0IGlzIGJlc3QgZG9u ZSBhcyBhIHN0YW5kYWxvbmUgc3BlY2lmaWNhdGlvbiBvciBhIOKAnHBhdGNo4oCdIG9yDQogICAg 4oCcZmlsdGVy4oCdIHRvIHN0b2NrIFRMUyB0aGF0IGNvdWxkIGFwcGx5IHRvIG11bHRpcGxlIFRM UyB2ZXJzaW9ucykuDQogICAgDQogICAgRm9yIHRoZSBzYWtlIG9mIGZhY2lsaXRhdGluZyBkaXNj dXNzaW9uLCB3ZSBpbmNsdWRlIGRyYWZ0IGNoYXJ0ZXIgdGV4dCBmb3INCiAgICB0aGUgT1NDT1JF IGNhc2UsIG1vZGlmaWVkIGJhc2VkIG9uIGlucHV0IGZyb20gdGhlIEJvRiBmcm9tIHRoZSB2ZXJz aW9uIHRoYXQNCiAgICB3YXMgcHJldmlvdXNseSBzZW50IHRvIHNlY2Rpc3BhdGNoQGlldGY6DQog ICAgDQogICAgPT1bIENIQVJURVIgXT09DQogICAgUHJvYmxlbQ0KICAgIA0KICAgIENvbnN0cmFp bmVkIGVudmlyb25tZW50cyB1c2luZyBPU0NPUkUgaW4gbmV0d29yayBlbnZpcm9ubWVudHMgc3Vj aCBhcw0KICAgIE5CLUlvVCwgNlRpU0NILCBhbmQgTG9SYVdBTiBuZWVkIGEg4oCYbGlnaHR3ZWln aHTigJkgYXV0aGVudGljYXRlZCBrZXkNCiAgICBleGNoYW5nZSAoTEFLRSkgdGhhdCBlbmFibGVz IGZvcndhcmQgc2VjdXJpdHkuICAnTGlnaHR3ZWlnaHQnIHJlZmVycyB0bzoNCiAgICANCiAgICAg ICogcmVzb3VyY2UgY29uc3VtcHRpb24sIG1lYXN1cmVkIGJ5IGJ5dGVzIG9uIHRoZSB3aXJlLCB3 YWxsLWNsb2NrIHRpbWUgdG8NCiAgICAgICAgY29tcGxldGUsIG9yIHBvd2VyIGNvbnN1bXB0aW9u DQogICAgICAqIHRoZSBhbW91bnQgb2YgbmV3IGNvZGUgcmVxdWlyZWQgb24gZW5kIHN5c3RlbXMg d2hpY2ggYWxyZWFkeSBoYXZlIGFuDQogICAgICAgIE9TQ09SRSBzdGFjaw0KICAgIA0KICAgIEdv YWxzDQogICAgDQogICAgVGhpcyB3b3JraW5nIGdyb3VwIGlzIGludGVuZGVkIHRvIGJlIGEgbmFy cm93bHkgZm9jdXNlZCBhY3Rpdml0eQ0KICAgIGludGVuZGVkIHRvIHByb2R1Y2UgYXQgbW9zdCBv bmUgTEFLRSBmb3IgT1NDT1JFIHVzYWdlIGFuZCBjbG9zZS4NCiAgICANCiAgICBUaGUgd29ya2lu ZyBncm91cCB3aWxsIGNvbGxhYm9yYXRlIGFuZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBX R3MNCiAgICBzdWNoIGFzIEFDRSwgQ09SRSwgNlRJU0NILCBhbmQgTFBXQU4gdG8gdW5kZXJzdGFu ZCBhbmQgdmFsaWRhdGUgdGhlDQogICAgcmVxdWlyZW1lbnRzIGFuZCBzb2x1dGlvbi4gIFRoZSBX RyB3aWxsIGFsc28gZXZhbHVhdGUgd29yayBmcm9tDQogICAgdGhlIFRMUyBXRyBhbmQgZGVyaXZh dGl2ZXMgdGhlcmVvZiwgYW5kIGRyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlLg0KICAgIA0K ICAgIFByb2dyYW0gb2YgV29yaw0KICAgIA0KICAgIFRoZSBkZWxpdmVyYWJsZXMgb2YgdGhpcyBX RyBhcmU6DQogICAgDQogICAgMS4gRGVzaWduIHJlcXVpcmVtZW50cyBvZiB0aGUgbGlnaHR3ZWln aHQgYXV0aGVudGljYXRlZCBrZXkgZXhjaGFuZ2UNCiAgICBwcm90b2NvbCBmb3IgT1NDT1JFICh0 aGlzIGRyYWZ0IHdpbGwgbm90IGJlIHB1Ymxpc2hlZCBhcyBhbiBSRkMgYnV0IHdpbGwgYmUNCiAg ICB1c2VkIHRvIGRyaXZlIFdHIGNvbnNlbnN1cyBvbiB0aGUgZGVsaXZlcmFibGUgKDIpDQogICAg DQogICAgMi4gU3BlY2lmeSBhIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdl IHByb3RvY29sIHN1aXRhYmxlIGZvcg0KICAgIHVzZSBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMgdXNpbmcgT1NDT1JFDQogICAgPT1bIENIQVJURVIgXT09DQogICAgDQogICAgVGhhbmtzLA0K ICAgIA0KICAgIEJlbiBhbmQgUm9tYW4NCiAgICANCiAgICBbMF0gIEZvciBleGFtcGxlLCB0aGUg dG90YWwgbnVtYmVyIG9mIGtleSBleGNoYW5nZSBvcGVyYXRpb25zIGV4cGVjdGVkIHRvDQogICAg YmUgcGVyZm9ybWVkIG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBkZXZpY2UsIGFzIG1pZ2h0IGJl IGNvbXBhcmVkIGFnYWluc3QNCiAgICB0aGUgdG90YWwgbGlmZXRpbWUgZW5lcmd5IGJ1ZGdldDsg YW5kIGEgcmVxdWVzdCB0byBtYWtlIGV4cGxpY2l0IHdoYXQgaGFkDQogICAgcHJldmlvdXNseSBi ZWVuIGltcGxpY2l0IGFzc3VtcHRpb25zIGFib3V0IHRoZSBjb3N0IG9mIHZhcmlvdXMgb3BlcmF0 aW9ucw0KICAgIChvbiB2YXJpb3VzIGF4ZXMpLg0KICAgIA0KICAgIC0tIA0KICAgIExha2UgbWFp bGluZyBsaXN0DQogICAgTGFrZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbGFrZQ0KICAgIA0KDQo= From nobody Fri Aug 23 11:33:30 2019 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1BD120044; Fri, 23 Aug 2019 11:33:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, Kathleen.Moriarty.ietf@gmail.com, secdispatch@ietf.org, secdispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156658520888.25079.16236780863129175874.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2019 11:33:28 -0700 Archived-At: Subject: [Secdispatch] secdispatch - New Meeting Session Request for IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:33:29 -0000 A new meeting session request has just been submitted by Kathleen Moriarty, a Chair of the secdispatch working group. --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Kathleen Moriarty Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: SAAG Dispatch ace acme cose curdle dots i2nsf ipsecme lamps mile oauth rats sacm secevent suit teep tls tokbind Technology Overlap: httpbis People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 26 13:24:40 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CD912011C; Mon, 26 Aug 2019 13:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 ei6IATuE97_k; Mon, 26 Aug 2019 13:24:36 -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 97CA0120EE0; Mon, 26 Aug 2019 13:24:36 -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 x7QKOVpD007546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 16:24:34 -0400 Date: Mon, 26 Aug 2019 15:24:31 -0500 From: Benjamin Kaduk To: Rene Struik Cc: lake@ietf.org, secdispatch@ietf.org Message-ID: <20190826202430.GL84368@kduck.mit.edu> References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:24:38 -0000 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"? Thanks, Ben > Best regards, Rene > > [1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]): > Is OSCORE Key exchange a ('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 From nobody Mon Aug 26 20:21:33 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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 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 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: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. <> (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. < > 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 From nobody Tue Aug 27 09:46:12 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875171208F6; Tue, 27 Aug 2019 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 CyRYYOfHEUHo; Tue, 27 Aug 2019 09:46:08 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 20C1D120937; Tue, 27 Aug 2019 09:46:08 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id z11so19527315wrt.4; Tue, 27 Aug 2019 09:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AWjNH+nrWkkDWz+5UXFZ0HcHA+LhnY8XLo7JUz8h03w=; b=IajDV8nInaE27U3glYPWmpB+M0HhOhPaw6uOfQdJoeuvKe3cErTmnHIYncU7ooE6wy bTaEsODa6Yc/6U0fB42SNpMFJE1PEnsTNDYfdURfMgleE5LjIDUXXvLzjR445Jpkr4Hc xjgV4nTNP9VSuVulaAQuMP/xWB4sJK+DXB7vu/V8i+2AIqLTZT0uEgd7ne9K2p1R4UgR Hz3zVdkxh/TkA21XKV3I/ObY6TK+adWQv7eN9nN4G8KQZ6uE65PJ2tUozdbzjlVcwDIP Z5XcZfSEkEGVPzqGUN9HkTe4KCor20HhpSuguqbVUCBkGpS2OfHNSeFx/9H1S/On0Hd3 q9bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AWjNH+nrWkkDWz+5UXFZ0HcHA+LhnY8XLo7JUz8h03w=; b=IJnR7C2mGko3xYOZs+6MIIP8FiezWHlvnWB1aP7nWs1QasLVHjOJ3zK3dGUEbtcn1C Q+Vd5pY/LLi53C7Xmmbva8/WvCyRiNoVLb0IWzi5z527id+Kmad+alg3niyIBs+N8D+T w08pNKb4eyU44O+WVNyOOuTpxDQ1S35CKrSgE5yhZ6fA4jwMa+pnn84lnnyuPrO3GXAj eKlrOFkS/tPoCIl6oNiyk9/bbFii+cELT3J+c2vF44dUuFRtLEWj+07bf79DGiw9OtuY qzsm/v+azBcTGpoAoFiWgHTq7ZsSLgqH+HVB3gr44WEe2dlZ2ZoA7rfo0tZCYC9l1/tz ZVZA== X-Gm-Message-State: APjAAAXMRjks/HI+AOFrCyMvVIskJomtU5ibOsF2meZyxF3rka/scSXU CNXtl4f817QwoILZDGWE+/4= X-Google-Smtp-Source: APXvYqy7AZEeXBDcECJLAoXd89nk0s16tRTGwYF255Kwmcs27Le+hKupXNTHR11nhnwgVUm9FYe/JA== X-Received: by 2002:a05:6000:148:: with SMTP id r8mr31474706wrx.312.1566924366545; Tue, 27 Aug 2019 09:46:06 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id a141sm5301800wmd.0.2019.08.27.09.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 09:44:38 -0700 (PDT) From: Yoav Nir Message-Id: <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D109DE3D-3300-4376-B50B-62527A89871E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 27 Aug 2019 19:44:32 +0300 In-Reply-To: <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> Cc: Benjamin Kaduk , lake@ietf.org, secdispatch@ietf.org To: Rene Struik References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 16:46:11 -0000 --Apple-Mail=_D109DE3D-3300-4376-B50B-62527A89871E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Rene > On 27 Aug 2019, at 6:21, Rene Struik wrote: >=20 >=20 > 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).=20 I disagree with this. It is not the IETF that is putting many eggs in = one basket, but the market. It is the market that is protecting every = piece of privacy-sensitive information using TLS: financial transaction, = bank statements, credit cards, school transcripts, medical appointments = and test results, email in transit to name but a few. If TLS is compromised, all of that is compromised, and the fact that SSH = or IPsec or some new OSCORE thing exist does not help me or anyone else = whose personal information is now exposed. If TLS is compromised = we=E2=80=99ll have to fix TLS. So regardless of what we decide at the = IETF, a whole lot of our eggs are already in one basket. It=E2=80=99s a = better use of our resources to make sure that basket is protected than = to spend them on making a new basket that hardly anyone will use. Yoav --Apple-Mail=_D109DE3D-3300-4376-B50B-62527A89871E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Rene

On 27 Aug 2019, at 6:21, Rene Struik <rstruik.ext@gmail.com> wrote:


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). 

I = disagree with this.  It is not the IETF that is putting many eggs = in one basket, but the market. It is the market that is protecting every = piece of privacy-sensitive information using TLS: financial transaction, = bank statements, credit cards, school transcripts, medical appointments = and test results, email in transit to name but a few.

If TLS is compromised, all of that is compromised, = and the fact that SSH or IPsec or some new OSCORE thing exist does not = help me or anyone else whose personal information is now exposed. =  If TLS is compromised we=E2=80=99ll have to fix TLS.  So = regardless of what we decide at the IETF, a whole lot of our eggs are = already in one basket. It=E2=80=99s a better use of our resources to = make sure that basket is protected than to spend them on making a new = basket that hardly anyone will use.

Yoav


= --Apple-Mail=_D109DE3D-3300-4376-B50B-62527A89871E-- From nobody Tue Aug 27 13:23:19 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827C2120129; Tue, 27 Aug 2019 13:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 Irzkd0m5g89a; Tue, 27 Aug 2019 13:23:08 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 F12FB1200DE; Tue, 27 Aug 2019 13:23:07 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id p23so485841oto.0; Tue, 27 Aug 2019 13:23:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2IZBtl3JbKpyWVg2eAwnY2e34foPJIal/OkoVxOuiGs=; b=D3TrZcwLv6qDj+M2DpqZY2lAq6bTeEYly0MZupvVKpCC2dujyGwzB3lHzFn1AwWSs/ QwKqaGozRKb7XOb65+ryCSO3v7RgoE14V7Pd1os3/AEB13GfF4OUpkESc2zq0ixHcaau nYWERHkbq44q3vPXeQ2F3cO+dmzkvYJ4ZhVxDjSFLsZI1zkixi6X0Pq8PB5YskluIsFf ehCMmr76qoQLeSHwOeHPYWiBVsKNP5hs0QCEx0lzbBnK3zpf3aAkaKY8Z5+3ez8DElom SZFGYhspe2BWHg4a2lpQqt6llufiFCG9Z7ddqmDj/MyPVS8SnX7Na6F2+e76MHHfZIbM +YUQ== X-Gm-Message-State: APjAAAWgL55bjGYBoeVdWw3mZDYhkKQTrYU1fOVN7bbV+zIKPMk+wXDu 2ly1ZL08s9Yg8LIsYzaRnc3EGJyZxvKmtzlmKBs= X-Google-Smtp-Source: APXvYqxVpXQRX2OYGSnNVEmwZx1CM7zKW7yaMGWNyfid08nPTt8hOBojVXLVkqazBiQOY3CC/2wUS04QbHgncr+OHDg= X-Received: by 2002:a9d:4a3:: with SMTP id 32mr376753otm.37.1566937387253; Tue, 27 Aug 2019 13:23:07 -0700 (PDT) MIME-Version: 1.0 References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com> In-Reply-To: <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com> From: Phillip Hallam-Baker Date: Tue, 27 Aug 2019 16:22:55 -0400 Message-ID: To: Yoav Nir Cc: Rene Struik , lake@ietf.org, IETF SecDispatch , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000005a4dcf05911f0ae4" Archived-At: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:23:10 -0000 --0000000000005a4dcf05911f0ae4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 27, 2019 at 12:46 PM Yoav Nir wrote: > Hi, Rene > > On 27 Aug 2019, at 6:21, Rene Struik wrote: > > > RS>> (Technical.) It would be prudent for IETF not to put too many eggs i= n > the same basket and, thereby, not have most protocols share the same cryp= to > 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). > > > I disagree with this. It is not the IETF that is putting many eggs in on= e > basket, but the market. It is the market that is protecting every piece o= f > privacy-sensitive information using TLS: financial transaction, bank > statements, credit cards, school transcripts, medical appointments and te= st > results, email in transit to name but a few. > > If TLS is compromised, all of that is compromised, and the fact that SSH > or IPsec or some new OSCORE thing exist does not help me or anyone else > whose personal information is now exposed. If TLS is compromised we=E2= =80=99ll > have to fix TLS. So regardless of what we decide at the IETF, a whole lo= t > of our eggs are already in one basket. It=E2=80=99s a better use of our r= esources > to make sure that basket is protected than to spend them on making a new > basket that hardly anyone will use. > My problem with using the TLS exchange is that we are still doing key exchange using a signature for authentication like we did in SSL when the whole protocol was predicated on use of RSA. We have got rid of the RSA but we still demand that we use a signature to authenticate the exchange which means that we leave non-repudiable evidence that an exchange took place. Maybe not significant in TLS (I think it is though) but certainly a concern in other areas. There is another approach which is to make the exchanged secret dependent on the supplemental information that we want to authenticate. So that the key exchange will succeed if and only if both sides get the same information. I believe this is what is done in Signal. --0000000000005a4dcf05911f0ae4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 27, 2019 at 12:46 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
<= div class=3D"gmail_quote">
Hi, Rene

On 27 Aug 2019, at 6:21, Rene Struik <rstruik.ext@gmail.com> = wrote:


My problem with using the TLS exchan= ge is that we are still doing key exchange using a signature for authentica= tion like we did in SSL when the whole protocol was predicated on use of RS= A.

We have got rid of the= RSA but we still demand that we use a signature to authenticate the exchan= ge which means that we leave non-repudiable evidence that an exchange took = place. Maybe not significant in TLS (I think it is though) but certainly a = concern in other areas.

T= here is another approach which is to make the exchanged secret dependent on= the supplemental information that we want to authenticate. So that the key= exchange will succeed if and only if both sides get the same information. = I believe this is what is done in Signal.




=C2=A0
--0000000000005a4dcf05911f0ae4-- From nobody Tue Aug 27 14:32:48 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91678120145; Tue, 27 Aug 2019 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 gFho9lI1wJ9G; Tue, 27 Aug 2019 14:32:38 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 6AC8A120113; Tue, 27 Aug 2019 14:32:38 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id s21so1649316ioa.1; Tue, 27 Aug 2019 14:32:38 -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-language; bh=7h0HS1hTKGooszKnB/sx9XEHSwTBx/fBlr4sJFVCawI=; b=cO1nrSnZZeQXwu8I57GxLILwSXXjjrtl5nJ243pYZjFu/wTeqkHOSM9c1VIV6wLSKs ZyMag4gQTHtyNEeWlI8LRm6QcPYH/1qnkUjnGmSaxpkF71cudUjGszSGkKKhl81si/2j AFe990zaQQvSGa/pd9VOVF68j8DjSdYz6p3/umHY+Zz7VKa0oMibmOxE4MB9YMtNFFQD VKpNplf3QKQ8LR5nLfZPbLrO4wEPklyUnryxZfyHUkvuH4X0csYiWDg/p2kornP6F2s+ rIRJNNLLU9SLmetDA4WvCry6yTabWk2g/MmQLMnYQQkcVZ5F2lsooO0nF4CbbiklLk2d yWyw== 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-language; bh=7h0HS1hTKGooszKnB/sx9XEHSwTBx/fBlr4sJFVCawI=; b=OwqTjtRe17drsaJdP0d96dH2HKrYxYnn11ENUHzi4Ce2sdJ+svI3sBgageB2RvlVe+ qWOTCRSCT28SHUbrICbtiuDnUQUGXhANsZ3SlGSJwnrthpKcT0FJc95c75scGkOfwCs/ q4mJA6mpPYlGBdfEjotaT7dS1rqkuvpNsBPi4S7WA92V90qkrELoNjrE0FPur55kYEr6 oyQKm68McfKSWvdYYXYBse3Vebkw++J9wRTdJwwO9K5RY3VwNC0ut8BPVOiNp3c5FUqv BQgUt1tvmJydR07+zYbFkT6Dj66ixS9QI3fV/d666ATmMOgQLt+TcTh1hd6fcHFsRrvV eBnA== X-Gm-Message-State: APjAAAVRSMTXPIv4qVB32bN6iHNLCz9V7717We7Wzp6a/uk63PQde0y9 5JnaINMymFbTAHwtUYe+3HGtORa5 X-Google-Smtp-Source: APXvYqzS8ZOFp/XDd3LwyhST6JjyqGEP6kbpH+TRLKyhLFEj7wA+BqVVu8hoTk3ZJlaLfmKL42n1fA== X-Received: by 2002:a5e:cb0a:: with SMTP id p10mr480474iom.133.1566941557064; Tue, 27 Aug 2019 14:32:37 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:85d:3155:fbab:8b69? ([2607:fea8:69f:f5eb:85d:3155:fbab:8b69]) by smtp.gmail.com with ESMTPSA id z19sm260299ioh.12.2019.08.27.14.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 14:32:36 -0700 (PDT) To: Yoav Nir Cc: Benjamin Kaduk , lake@ietf.org, secdispatch@ietf.org References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com> From: Rene Struik Message-ID: <0db24e86-fda9-63f8-feee-d24006252542@gmail.com> Date: Tue, 27 Aug 2019 17:32:31 -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: <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com> Content-Type: multipart/alternative; boundary="------------72CD670AF6B7C059D6097063" Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:32:41 -0000 This is a multi-part message in MIME format. --------------72CD670AF6B7C059D6097063 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yoav: To my knowledge, IETF prides itself of acting through the efforts of gifted individuals, who contribute their expertise and insights, and (hopefully) act in the interest of the [admittedly abstract notion of] the common good, and not with malicious intent. Mr. Market (whoever he or she is) does not sign blue sheets or stand at the mike; nor does the "invisible hand" show up in the authors' list or can it be held accountable for its actions. People do. The point of my comment on agility was not so much that one could not end up with a TLS-like protocol (this is indeed possible and it is clear that some actors have ideas here), but that it should not be the pre-condition, esp. since the characteristics of lightweight applications might very well be different than those of TLS (e.g., with respect to real-life attacks, privacy, deployment, and control). The main point, thus, was to keep an open mind. I am happy to accept a friendly amendment of my note and remove [for IETF] from the phrase "It would be prudent [for IETF] not to put many eggs in the same basket". I hope that helps and makes this a statement that should be obvious to anyone with technical inclinations (but nevertheless worth repeating). Best regards, Rene On 8/27/2019 12:44 PM, Yoav Nir wrote: > Hi, Rene > >> On 27 Aug 2019, at 6:21, Rene Struik > > wrote: >> >> >> 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). > > I disagree with this.  It is not the IETF that is putting many eggs in > one basket, but the market. It is the market that is protecting every > piece of privacy-sensitive information using TLS: financial > transaction, bank statements, credit cards, school transcripts, > medical appointments and test results, email in transit to name but a few. > > If TLS is compromised, all of that is compromised, and the fact that > SSH or IPsec or some new OSCORE thing exist does not help me or anyone > else whose personal information is now exposed.  If TLS is compromised > we’ll have to fix TLS.  So regardless of what we decide at the IETF, a > whole lot of our eggs are already in one basket. It’s a better use of > our resources to make sure that basket is protected than to spend them > on making a new basket that hardly anyone will use. > > Yoav > > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------72CD670AF6B7C059D6097063 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Yoav:

To my knowledge, IETF prides itself of acting through the efforts of gifted individuals, who contribute their expertise and insights, and (hopefully) act in the interest of the [admittedly abstract notion of] the common good, and not with malicious intent. Mr. Market (whoever he or she is) does not sign blue sheets or stand at the mike; nor does the "invisible hand" show up in the authors' list or can it be held accountable for its actions. People do.

The point of my comment on agility was not so much that one could not end up with a TLS-like protocol (this is indeed possible and it is clear that some actors have ideas here), but that it should not be the pre-condition, esp. since the characteristics of lightweight applications might very well be different than those of TLS (e.g., with respect to real-life attacks, privacy, deployment, and control). The main point, thus, was to keep an open mind.

I am happy to accept a friendly amendment of my note and remove [for IETF] from the phrase "It would be prudent [for IETF] not to put many eggs in the same basket". I hope that helps and makes this a statement that should be obvious to anyone with technical inclinations (but nevertheless worth repeating).

Best regards, Rene

On 8/27/2019 12:44 PM, Yoav Nir wrote:
Hi, Rene

On 27 Aug 2019, at 6:21, Rene Struik <rstruik.ext@gmail.com> wrote:


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). 

I disagree with this.  It is not the IETF that is putting many eggs in one basket, but the market. It is the market that is protecting every piece of privacy-sensitive information using TLS: financial transaction, bank statements, credit cards, school transcripts, medical appointments and test results, email in transit to name but a few.

If TLS is compromised, all of that is compromised, and the fact that SSH or IPsec or some new OSCORE thing exist does not help me or anyone else whose personal information is now exposed.  If TLS is compromised we’ll have to fix TLS.  So regardless of what we decide at the IETF, a whole lot of our eggs are already in one basket. It’s a better use of our resources to make sure that basket is protected than to spend them on making a new basket that hardly anyone will use.

Yoav



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------72CD670AF6B7C059D6097063-- From nobody Wed Aug 28 10:08:33 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3908120FC6; Mon, 26 Aug 2019 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 idwTcgv-tVHk; Mon, 26 Aug 2019 13:46:50 -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 26777120F90; Mon, 26 Aug 2019 13:46:50 -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 x7QKkhXf014647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 16:46:45 -0400 Date: Mon, 26 Aug 2019 15:46:42 -0500 From: Benjamin Kaduk To: =?iso-8859-1?Q?G=F6ran?= Selander Cc: "lake@ietf.org" Message-ID: <20190826204642.GM84368@kduck.mit.edu> References: <20190820155006.GE60855@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-Mailman-Approved-At: Wed, 28 Aug 2019 10:08:27 -0700 Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:47:00 -0000 [Note: secdispatch@ to bcc] Hi Göran, On Thu, Aug 22, 2019 at 01:27:49PM +0000, Göran Selander wrote: > Hi Ben and Roman, > > If I understand right, the proposal is - in one sentence - to work both on a lightweight authenticated key exchange for OSCORE in the LAKE WG, and on a compact variant of TLS in the TLS WG. This sounds like a good way forward, since an optimal solution to one of the problems is most likely not optimal (or even suitable) for the other, and optimization is one of the reasons for doing this work in the first place. > > 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. > 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. > 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 :) Thanks, Ben > > > On 2019-08-20, 17:50, "Lake on behalf of Benjamin Kaduk" 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 From nobody Wed Aug 28 10:08:40 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D003F120232; Wed, 28 Aug 2019 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 dJnaKcSF-Upq; Wed, 28 Aug 2019 09:50:29 -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 882E01200B2; Wed, 28 Aug 2019 09:50:29 -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 x7SGoOOt012419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 12:50:26 -0400 Date: Wed, 28 Aug 2019 11:50:23 -0500 From: Benjamin Kaduk To: Rene Struik Cc: lake@ietf.org Message-ID: <20190828165023.GE84368@kduck.mit.edu> References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-Mailman-Approved-At: Wed, 28 Aug 2019 10:08:27 -0700 Subject: Re: [Secdispatch] [Lake] LAKE next steps X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:50:32 -0000 [secdispatch@ again to bcc] Hi Rene, On Mon, Aug 26, 2019 at 11:21:06PM -0400, Rene Struik wrote: > 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>> (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. <