From nobody Fri Jan 24 04:45:16 2020 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE22120044; Fri, 24 Jan 2020 04:45:14 -0800 (PST) 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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 Qvehosd0RsNL; Fri, 24 Jan 2020 04:45:13 -0800 (PST) Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) (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 E1907120052; Fri, 24 Jan 2020 04:45:12 -0800 (PST) Received: by mail-ua1-f41.google.com with SMTP id z24so723526uam.7; Fri, 24 Jan 2020 04:45:12 -0800 (PST) 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=Ry2UI3ZP/7EgdDKdp26uQ2P9tfBblbUk3r1ZENTpHjE=; b=PcCJ4Inzz56hZGvntMxm14026hiuH/zto6UkOFlONYYdbRsdHPk3i2biirU8naZnz7 4eOBYG7qQkqoJrWqMSn6hgeyyksXDNoOjscCQ1CZczbtdO/csEB2HODcnRdxITjptLlz YUR0/6pfaH9RotsGFP5DmE5Q2Fng8bjNOe1W4GwJhNVOFXNSnxRLpzKgTe7igakmI0Mb BJS5+o7+qexmQkgsUoXKacOSFk4cdrqjpc+kaNBQ78nbtpayvK2I4N8VNNrgFjyBhBHz F0hkfqVHGl8pBxACCvWDe2zkFUJ6ZQJ9SHkFvtZQYBNlLSxN8egauKZSz2mXpExu41t2 RcuA== X-Gm-Message-State: APjAAAXIj9q6Hgc/S2OXDfJQ+VlPKx0Zp/aKM8UgqhhnhPgYPK806ISB Mfy7RP7FIJAT4KpPcLq9PoAFHpdLy3hY+iDrIkVQuqbWWSQ= X-Google-Smtp-Source: APXvYqy00RsiKJsZSpkuTRR9YTzsISKvSasYyyU6RyDtty3ZN2tA3otRE/fmEEmq4mPQYU98/Uj/VwEtB5gRSyrh3Q0= X-Received: by 2002:ab0:6881:: with SMTP id t1mr1526868uar.88.1579869911907; Fri, 24 Jan 2020 04:45:11 -0800 (PST) MIME-Version: 1.0 References: <157979422864.22806.5435940336310786424.idtracker@ietfa.amsl.com> <2e4a29e3-e4ca-22f4-ec50-105e53359b41@labs.htt-consult.com> In-Reply-To: <2e4a29e3-e4ca-22f4-ec50-105e53359b41@labs.htt-consult.com> From: Daniel Migault Date: Fri, 24 Jan 2020 07:45:01 -0500 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" , hipsec@ietf.org Content-Type: multipart/alternative; boundary="000000000000e40082059ce22012" Archived-At: Subject: Re: [Hipsec] [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 12:45:14 -0000 --000000000000e40082059ce22012 Content-Type: text/plain; charset="UTF-8" Hi, Thanks Robert for the update. I would like to get feed backs from the tmrid and especially hip WG of their thoughts regarding this new proposal. Bob, could you updates the WGs on the maturity level of your proposal as well as the next (technical) steps to complete that work. Yours, Daniel On Thu, Jan 23, 2020 at 10:47 AM Robert Moskowitz wrote: > I have added sec 8.2, discussing the security of using KMAC as a KDF. > This is based on a conversation I had with the Keccak team at the IACR > conference at Columbia U earlier this month. > > Basically the KMAC output is a PRF and as such can be directly divided > into multiple keys. No need for a compress and expand process on the > output of ECDH; this is done implicitly in the sponge. > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-hip-new-crypto-04.txt > Date: Thu, 23 Jan 2020 07:43:48 -0800 > From: internet-drafts@ietf.org > To: Stuart Card , > Adam Wiethuechter > , Robert Moskowitz > , Stuart W. Card > > > > A new version of I-D, draft-moskowitz-hip-new-crypto-04.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-hip-new-crypto > Revision: 04 > Title: New Cryptographic Algorithms for HIP > Document date: 2020-01-23 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-04.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto > Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-04 > > Abstract: > This document provides new cryptographic algorithms to be used with > HIP. The Edwards Elliptic Curve and the Keccak sponge functions are > the main focus. The HIP parameters and processing instructions > impacted by these algorithms are defined. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --000000000000e40082059ce22012 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Thanks Robert for the update.= I would=C2=A0like to get feed backs from the tmrid and especially hip WG o= f their thoughts regarding this new proposal.

Bob,= could you updates the WGs on the maturity level of your proposal as well a= s the next (technical) steps to complete that work.=C2=A0

Yours,=C2=A0
Daniel

On Thu, Jan 23, 2020 at 10:47 AM= Robert Moskowitz <rgm@labs.= htt-consult.com> wrote:
=20 =20 =20
I have added sec 8.2, discussing the security of using KMAC as a KDF.=C2=A0 This is based on a conversation I had with the Keccak team a= t the IACR conference at Columbia U earlier this month.

Basically the KMAC output is a PRF and as such can be directly divided into multiple keys.=C2=A0 No need for a compress and expand process on the output of ECDH; this is done implicitly in the sponge.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt
Date: Thu, 23 Jan 2020 07:43:48 -0800
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-04.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 04
Title: New Cryptographic Algorithms for HIP
Document date: 2020-01-23
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-mo= skowitz-hip-new-crypto-04.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-= hip-new-crypto/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-= crypto-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-m= oskowitz-hip-new-crypto
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mo= skowitz-hip-new-crypto-04

Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid
--000000000000e40082059ce22012-- From nobody Fri Jan 24 05:41:48 2020 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EDB12008B; Fri, 24 Jan 2020 05:41:42 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Bx-7H9MfPfJI; Fri, 24 Jan 2020 05:41:39 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 BF4BB120052; Fri, 24 Jan 2020 05:41:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8780162162; Fri, 24 Jan 2020 08:41:36 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tT822QNNWMUW; Fri, 24 Jan 2020 08:41:25 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 55C0B6211C; Fri, 24 Jan 2020 08:41:22 -0500 (EST) To: Daniel Migault Cc: "tm-rid@ietf.org" , hipsec@ietf.org References: <157979422864.22806.5435940336310786424.idtracker@ietfa.amsl.com> <2e4a29e3-e4ca-22f4-ec50-105e53359b41@labs.htt-consult.com> From: Robert Moskowitz Message-ID: <0c9949d8-2d37-b1f7-eb53-84f200897ebe@labs.htt-consult.com> Date: Fri, 24 Jan 2020 08:41:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BBB26A04AA57AF358C77262" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 13:41:43 -0000 This is a multi-part message in MIME format. --------------5BBB26A04AA57AF358C77262 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I would actually like to make a presentation at SAAG about KMAC as a KDF and why the IETF should incorporate it. SP 800-185 was published back in Dec 2016.  This clearly shows how to use KMAC as a replacement for HMAC.  Many in the security community 'rejected' SHA3 as only marginally faster than SHA256. They missed that thus KMAC is 2x as fast as HMAC-SHA256! SP 800-56Cr1 was published in Apr 2018.  Here it was NOT as clear that KMAC as a KDF was a clean replacement for HKDF when the source was an ECDH derive secret.  SP 800-108 has not been updated since 1st published in Oct 2009.  So there was a reasonable question as to KMAC being equal to HKDF for an ECDH derived secret. But, "anyone skilled in the arts" of understanding crypto algorithms (not necessarily at the level to create them) could see from FIPS 202 (Aug 2015) that the sponge function in the form of SHAKE directly performs both processes in HKDF - Extract and Expand.  But it took until 800-185 for the "approved" method to add keying material into SHAKE. Thus KMAC as defined in 800-56Cr1 is cryptographically equivalent to HKDF and MANY fewer hash operations. So the standard has been around for some years.  The cryptoanalysis is that of the sponge function being a PRF; there is no practical limit on how much you can squeeze out of the sponge.  Well there is a limit of 2^(n-1) bits, I believe.  It has been us crypto-plumbers that have not been paying attention. On 1/24/20 7:45 AM, Daniel Migault wrote: > Hi, > > Thanks Robert for the update. I would like to get feed backs from the > tmrid and especially hip WG of their thoughts regarding this new proposal. > > Bob, could you updates the WGs on the maturity level of your proposal > as well as the next (technical) steps to complete that work. > > Yours, > Daniel > > On Thu, Jan 23, 2020 at 10:47 AM Robert Moskowitz > > wrote: > > I have added sec 8.2, discussing the security of using KMAC as a > KDF.  This is based on a conversation I had with the Keccak team > at the IACR conference at Columbia U earlier this month. > > Basically the KMAC output is a PRF and as such can be directly > divided into multiple keys.  No need for a compress and expand > process on the output of ECDH; this is done implicitly in the sponge. > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-hip-new-crypto-04.txt > Date: Thu, 23 Jan 2020 07:43:48 -0800 > From: internet-drafts@ietf.org > To: Stuart Card > , Adam Wiethuechter > > , Robert Moskowitz > , > Stuart W. Card > > > > > > A new version of I-D, draft-moskowitz-hip-new-crypto-04.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-hip-new-crypto > Revision: 04 > Title: New Cryptographic Algorithms for HIP > Document date: 2020-01-23 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-04.txt > Status: > https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ > Htmlized: > https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto > Diff: > https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-04 > > Abstract: > This document provides new cryptographic algorithms to be used with > HIP. The Edwards Elliptic Curve and the Keccak sponge functions are > the main focus. The HIP parameters and processing instructions > impacted by these algorithms are defined. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at > tools.ietf.org . > > The IETF Secretariat > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------5BBB26A04AA57AF358C77262 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I would actually like to make a presentation at SAAG about KMAC as a KDF and why the IETF should incorporate it.

SP 800-185 was published back in Dec 2016.  This clearly shows how to use KMAC as a replacement for HMAC.  Many in the security community 'rejected' SHA3 as only marginally faster than SHA256.  They missed that thus KMAC is 2x as fast as HMAC-SHA256!

SP 800-56Cr1 was published in Apr 2018.  Here it was NOT as clear that KMAC as a KDF was a clean replacement for HKDF when the source was an ECDH derive secret.  SP 800-108 has not been updated since 1st published in Oct 2009.  So there was a reasonable question as to KMAC being equal to HKDF for an ECDH derived secret.

But, "anyone skilled in the arts" of understanding crypto algorithms (not necessarily at the level to create them) could see from FIPS 202 (Aug 2015) that the sponge function in the form of SHAKE directly performs both processes in HKDF - Extract and Expand.  But it took until 800-185 for the "approved" method to add keying material into SHAKE.

Thus KMAC as defined in 800-56Cr1 is cryptographically equivalent to HKDF and MANY fewer hash operations.

So the standard has been around for some years.  The cryptoanalysis is that of the sponge function being a PRF; there is no practical limit on how much you can squeeze out of the sponge.  Well there is a limit of 2^(n-1) bits, I believe.  It has been us crypto-plumbers that have not been paying attention.



On 1/24/20 7:45 AM, Daniel Migault wrote:
Hi, 

Thanks Robert for the update. I would like to get feed backs from the tmrid and especially hip WG of their thoughts regarding this new proposal.

Bob, could you updates the WGs on the maturity level of your proposal as well as the next (technical) steps to complete that work. 

Yours, 
Daniel

On Thu, Jan 23, 2020 at 10:47 AM Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
I have added sec 8.2, discussing the security of using KMAC as a KDF.  This is based on a conversation I had with the Keccak team at the IACR conference at Columbia U earlier this month.

Basically the KMAC output is a PRF and as such can be directly divided into multiple keys.  No need for a compress and expand process on the output of ECDH; this is done implicitly in the sponge.




-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt
Date: Thu, 23 Jan 2020 07:43:48 -0800
From: internet-drafts@ietf.org
To: Stuart Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-04.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 04
Title: New Cryptographic Algorithms for HIP
Document date: 2020-01-23
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-04.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-04

Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Tm-rid mailing list
Tm-rid@ietf.org
https://www.ietf.org/mailman/listinfo/tm-rid

--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------5BBB26A04AA57AF358C77262-- From nobody Fri Jan 24 10:41:53 2020 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257FB12004C; Fri, 24 Jan 2020 10:41:52 -0800 (PST) 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 txse4mxaQV0A; Fri, 24 Jan 2020 10:41:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8095612001E; Fri, 24 Jan 2020 10:41:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 861BE38982; Fri, 24 Jan 2020 13:41:15 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A8B2F60A; Fri, 24 Jan 2020 13:41:49 -0500 (EST) From: Michael Richardson To: hipsec@ietf.org, "tm-rid\@ietf.org" In-Reply-To: <0c9949d8-2d37-b1f7-eb53-84f200897ebe@labs.htt-consult.com> References: <157979422864.22806.5435940336310786424.idtracker@ietfa.amsl.com> <2e4a29e3-e4ca-22f4-ec50-105e53359b41@labs.htt-consult.com> <0c9949d8-2d37-b1f7-eb53-84f200897ebe@labs.htt-consult.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Hipsec] [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 18:41:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > I would actually like to make a presentation at SAAG about KMAC as a = KDF and > why the IETF should incorporate it. > SP 800-185 was published back in Dec 2016.=C2=A0 This clearly shows h= ow to use > KMAC as a replacement for HMAC.=C2=A0 Many in the security community = 'rejected' > SHA3 as only marginally faster than SHA256. They missed that thus KMA= C is 2x > as fast as HMAC-SHA256! I guess you saying that KMAC does not require two passes of the underlying hash when used with SHA3? Or is it in general? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4rOm0ACgkQgItw+93Q 3WVmWggAucF2JugkSui6vQ8suxS/wT7eyAjz8S47WWiNzWYbIUiejJFEf+C37P2h yKasf3B4OAFcpBHDWytiClqnyo2pujT0bB0gKbypG5ofEk8ixMFGyunM8ofEY3QA ITHlw6ZOBVhj5RLnRSKEl+mrmclAHsNMy/7iZFSQ3Gz0YttshzQDNvkuuyE/oBXc L5DIBWd13UpyDqsZvKiTLEaRXddAcAzg0cV6+84KTW5/zSP9+qUs2J1nSudchqkn lL9uMpa0WhXMcFPkbc6lPDJEgxaxa5g9+3NQyzsozbr1IJE0pDiUSFIJ8Sdsot30 dw7kPWLzE8pBwKvcZNOVW49AszHE3g== =vDw5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 24 11:54:51 2020 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8512087B; Fri, 24 Jan 2020 11:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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] 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 KOWmx0UbW2AP; Fri, 24 Jan 2020 11:54:44 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 4042612011E; Fri, 24 Jan 2020 11:54:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C9E066211C; Fri, 24 Jan 2020 14:54:42 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7BZfUdFym79R; Fri, 24 Jan 2020 14:54:35 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7BF5860029; Fri, 24 Jan 2020 14:54:33 -0500 (EST) To: Michael Richardson , hipsec@ietf.org, "tm-rid@ietf.org" References: <157979422864.22806.5435940336310786424.idtracker@ietfa.amsl.com> <2e4a29e3-e4ca-22f4-ec50-105e53359b41@labs.htt-consult.com> <0c9949d8-2d37-b1f7-eb53-84f200897ebe@labs.htt-consult.com> <20397.1579891309@localhost> From: Robert Moskowitz Message-ID: <6151332c-8575-384b-b007-9c517d0e3f1d@labs.htt-consult.com> Date: Fri, 24 Jan 2020 14:54:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20397.1579891309@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 19:54:46 -0000 On 1/24/20 1:41 PM, Michael Richardson wrote: > Robert Moskowitz wrote: > > I would actually like to make a presentation at SAAG about KMAC as a KDF and > > why the IETF should incorporate it. > > > SP 800-185 was published back in Dec 2016.  This clearly shows how to use > > KMAC as a replacement for HMAC.  Many in the security community 'rejected' > > SHA3 as only marginally faster than SHA256. They missed that thus KMAC is 2x > > as fast as HMAC-SHA256! > > I guess you saying that KMAC does not require two passes of the underlying > hash when used with SHA3? Or is it in general? KMAC **IS** SHA3. Or rather both are based on the same Keccak function. First look at FIPS 202, sec 6.2, for how SHAKE is constructed compared to SHA3. Then 800-185 and how cSHAKE and KMAC are functions built on SHAKE. So in terms of computational costs KMAC and SHA3 are very close.  It is really a more a question of how the bit stream is fed into the sponge and then how bits are squeezed out of the sponge. And that is why not needing two distinct passes. The sponge is inherently two passes.  First the sponge absorbs your bit stream, then squeeze out bits as you need them.  See figure 7 in FIPS 202 on this. Perhaps the difference between HKDF and KMAC as a KDF is how other info is fed into the process.  In HKDF, there is other info in each step of the process.  In KMAC all bits are absorbed before any squeezing.  And you squeeze out all you want before using it. See fig 1 in Sec 5 of 800-56Cr1 and compare it to the above fig 7. Hope this helps. Bob From nobody Wed Jan 29 06:22:00 2020 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A2B12011A for ; Wed, 29 Jan 2020 06:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7CRixX2miKms for ; Wed, 29 Jan 2020 06:21:56 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 017CC120088 for ; Wed, 29 Jan 2020 06:21:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id F036C62133 for ; Wed, 29 Jan 2020 09:21:54 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id P9cgYo-3DlWW for ; Wed, 29 Jan 2020 09:21:41 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 63FEE6212E for ; Wed, 29 Jan 2020 09:21:41 -0500 (EST) To: HIP From: Robert Moskowitz Message-ID: Date: Wed, 29 Jan 2020 09:21:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CAC10BB72A8F58FA785F33B2" Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Last Call comments on draft-ietf-hip-dex-11 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 14:21:59 -0000 This is a multi-part message in MIME format. --------------CAC10BB72A8F58FA785F33B2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Eric, I thank you for your review.  There are some really good insights within it.  I will provide my comments here on how I plan to handle them. On 11/3/19 3:31 PM, Eric Rescorla wrote: > Sorry for the standalone message. I don't seem to be subscribed to > ietf-announce, so can't reply. > > I do not believe that this meets the security standards that we > currently use for designing protocols at IETF. As a general matterE, > this document seems to cut a large number of corners in the service of > some unspecified "overhead" goal, yet it never describes what the > targets are (though presumably this is somehow about computation and > bandwidth), and so it is not possible to evaluate the document against > them. At present, I am unable to say whether it's necessary to do a > new document at all. > > The rest of this message details specific deficiencies of this > protocol which should be addressed. Aside from these, it's fairly > unfortunate to see a design for a protocol that uses such an unusual > cryptographic core for no obvious reason. This makes it very hard to > analyze. It would be far better to use SIGMA or some other > well-analyzed construction. > > > LACK OF PFS > The most serious concern here is the lack of Forward Secrecy. This is > a straightforward static-static DH exchange, but it is not possible to > provide FS in that scenario, as S 1 acknowledges. I have two concerns > here: First, FS is simply table stakes in a modern AKE protocol, so I > don't think we should be publishing a document that doesn't have it > on the standards track. > > Second, even if we were to concede that FS might be optional, the > design choices here don't make any sense. There are two major costs to > DH: the cost of doing the DH computations and the bandwidth of sending > the keys. However, given the wide range of the curves permitted here > (X25519 to P521), even a full triple-DH protocol will be far more > efficient on both counts than the existing protocol with P521 (indeed, > it's probably as or more efficient than the existing protocol with > P256). > > Proposed action: This protocol needs to be revised to have forward > security. dex-12.txt will have an applicability statement.  You will see text there that cover work on an 8501 chip with the timings and thus why the design. > HIT GENERATION > Previous versions of HIP generated HITs from HIs by computing a secure > hash on the HI. This document converts them by a novel folding > procedure. There is no good reason to believe that it is hard to > generate a key that has a given HIT (indeed there are good reasons to > believe it *is* reasonably efficient for non-EC algorithms). The > document sort-of-acknowledges this in Section 9: > >    o  The HIP DEX HIT generation may present new attack opportunities. >       Hence, HIP DEX HITs MUST NOT be used as the only means to identify >       a peer in an ACL.  Instead, the use of the peer's HI is >       recommended as explained in Section 3. > > However, it's not clear it's sufficient, because nothing strongly > binds the HI (as opposed to the HIT) to the handshake, so attacks > may still be possible if the HI is used (via UKS-like attacks). In > any case, this is a regression from HIPv2. > > It's not even clear why this change was made: given that you > have CMAC, you should be able to use this to produce a hash of > the key. > > Proposed action: generate HITs from HIs securely. First point, the HIs are contained in the R1 and I2 packets.  Thus they are bound to the handshake.  The HIT is an index to the ACL (or other lookup mechanism) and duplicates are not allowed.  So it is a 'first come, first allowed' process for HIT to HI mappings. We have always recognized the risk of duplicates, even with the probability being very low with a 96 bit truncation of the hash in HIP-BEX. That said, I considered your recommendation to use CMAC rather than my novel FOLD operation that I got from another security source. From my original notes, I remembered that the challenge in using CMAC for HIT generation is what to use for the key.  Should I just use ZERO or some published random value.  So I asked NIST and here is the official response: "We cannot endorse either choice.  The function you describe--CMAC with a published key--is not an approved cryptographic hash function.  Indeed, It is straightforward to demonstrate that this function is not collision-resistant for any choice of the key." So the only reason to switch to CMAC is to satisfy some thought that it would less likely cause a problem than the FOLD function. Either way there is need for explaining the need to defend against duplicate HITs, both 'natural' and forced.  And CMAC has a higher computing cost than FOLD. Right now I feel that I should leave it as is and that the text is adequate to describe the risk.  If you feel I need more warnings, I will write up text for the security section.  If you feel that CMAC should be used just because, we can discuss it further. > WEAK EC GROUPS > This document specifies the use of SECP160R1. This is not an acceptably > secure group. > > Proposed action: REmove support for SECP160R1. SECP160R1 is carried over from RFC 7401.  At the time, there were participants that wanted something for those really limited CPUs (like the 8501). Now we have EC25519 and it can be argued that its performance and transmitted key size (for constrained networks) meets the needs for those that wanted SECP160R1.  My concern is I have no data on the CPU cost on a 8501 for SECP160R1 to make a valid comparison to EC25519. Further the adding of EC25519 does not replace SECP160R1 in HIP-BEX (RFC 7401), so at best, all I could do is not include it in HIP-DEX, it still would be valid for HIP-BEX. For now I am leaving SECP160R1 in unless I get feedback that we can deprecate it for EC25519.  Note that a separate draft, draft-moskowitz-hip-new-crypto, is adding EDDSA25519 for HIP-BEX and there we can deprecate SECP160R1. > FAILURE TO VALIDATE PUBLIC KEYS > This document does not require that implementations validate > the remote public key. With the NIST curves specified here, > this leads to straightforward key extraction attacks, which > is a very serious problem when you have a static key. > > Proposed action: Require point validation. The TLS 1.3 has > text you can borrow. I am assuming you mean sec 4.2.8.2 of RFC8446? I am shocked that we have to tell implementers to test that the EC PK is a valid point.  Not. I will use this text as the basis for an addition subsection in Security Considerations. > AEAD > This document makes use of non-AEAD symmetric algorithms. This has been > found to be hazardous in practice. > > Proposed action: use only AEAD algorithms. All HIP payloads that occur after there are agreed keys, are authenticated (MACed).  Few payloads have encrypted parameters. Further the way parameters are organized within the payload it is possible that the encrypted parameters would not be adjacent, making further complications.   It does not make sense to switch to an AEAD with this design.  Plus an AEAD adds processing overhead.  IF NIST had completed the lightweight crypto competition at design time, then AEAD may have been given closer study. > REPLAY ATTACK ON AKE > The only entropy provided to the AKE is the puzzle, which means > that it's possible for an attacker to replay the responder's > messages, leaving the initiator believing that he has created > a connection when in fact he has not. The attacker will not > be able to send data messages because the initiator contributes > data to the eventual keys, but we generally try to avoid this > property. > > More importantly, this is unnecessary, and can be resolved > by changing the odd "encrypt half the key" mechanism used here > with a conventional nonce structure in which each side sends > a random value and then you HKDF it with the DH shared secret. > This would have the effect of removing the replay attack > and be easier to analyze. > > Proposed action: restructure the AKE to mix nonces + DH > into the key schedule. This is a good suggestion.  I am still studying it for the best way to implement it.  I do expect to have something done for a dex-13.txt draft. > > -Ekr > Robert Moskowitz --------------CAC10BB72A8F58FA785F33B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Eric,

I thank you for your review.  There are some really good insights within it.  I will provide my comments here on how I plan to handle them.

On 11/3/19 3:31 PM, Eric Rescorla wrote:
Sorry for the standalone message. I don't seem to be subscribed to
ietf-announce, so can't reply.

I do not believe that this meets the security standards that we
currently use for designing protocols at IETF. As a general matterE,
this document seems to cut a large number of corners in the service of
some unspecified "overhead" goal, yet it never describes what the
targets are (though presumably this is somehow about computation and
bandwidth), and so it is not possible to evaluate the document against
them. At present, I am unable to say whether it's necessary to do a
new document at all.

The rest of this message details specific deficiencies of this
protocol which should be addressed. Aside from these, it's fairly
unfortunate to see a design for a protocol that uses such an unusual
cryptographic core for no obvious reason. This makes it very hard to
analyze. It would be far better to use SIGMA or some other
well-analyzed construction.


LACK OF PFS
The most serious concern here is the lack of Forward Secrecy. This is
a straightforward static-static DH exchange, but it is not possible to
provide FS in that scenario, as S 1 acknowledges. I have two concerns
here: First, FS is simply table stakes in a modern AKE protocol, so I
don't think we should be publishing a document that doesn't have it
on the standards track.

Second, even if we were to concede that FS might be optional, the
design choices here don't make any sense. There are two major costs to
DH: the cost of doing the DH computations and the bandwidth of sending
the keys. However, given the wide range of the curves permitted here
(X25519 to P521), even a full triple-DH protocol will be far more
efficient on both counts than the existing protocol with P521 (indeed,
it's probably as or more efficient than the existing protocol with
P256).

Proposed action: This protocol needs to be revised to have forward
security.

dex-12.txt will have an applicability statement.  You will see text there that cover work on an 8501 chip with the timings and thus why the design.

HIT GENERATION
Previous versions of HIP generated HITs from HIs by computing a secure
hash on the HI. This document converts them by a novel folding
procedure. There is no good reason to believe that it is hard to
generate a key that has a given HIT (indeed there are good reasons to
believe it *is* reasonably efficient for non-EC algorithms). The
document sort-of-acknowledges this in Section 9:

   o  The HIP DEX HIT generation may present new attack opportunities.
      Hence, HIP DEX HITs MUST NOT be used as the only means to identify
      a peer in an ACL.  Instead, the use of the peer's HI is
      recommended as explained in Section 3.

However, it's not clear it's sufficient, because nothing strongly
binds the HI (as opposed to the HIT) to the handshake, so attacks
may still be possible if the HI is used (via UKS-like attacks). In
any case, this is a regression from HIPv2.

It's not even clear why this change was made: given that you
have CMAC, you should be able to use this to produce a hash of
the key.

Proposed action: generate HITs from HIs securely.

First point, the HIs are contained in the R1 and I2 packets.  Thus they are bound to the handshake.  The HIT is an index to the ACL (or other lookup mechanism) and duplicates are not allowed.  So it is a 'first come, first allowed' process for HIT to HI mappings.  We have always recognized the risk of duplicates, even with the probability being very low with a 96 bit truncation of the hash in HIP-BEX.

That said, I considered your recommendation to use CMAC rather than my novel FOLD operation that I got from another security source. From my original notes, I remembered that the challenge in using CMAC for HIT generation is what to use for the key.  Should I just use ZERO or some published random value.  So I asked NIST and here is the official response:

"We cannot endorse either choice.  The function you describe--CMAC with a published key--is not an approved cryptographic hash function.  Indeed, It is straightforward to demonstrate that this function is not collision-resistant for any choice of the key."

So the only reason to switch to CMAC is to satisfy some thought that it would less likely cause a problem than the FOLD function.  Either way there is need for explaining the need to defend against duplicate HITs, both 'natural' and forced.  And CMAC has a higher computing cost than FOLD.

Right now I feel that I should leave it as is and that the text is adequate to describe the risk.  If you feel I need more warnings, I will write up text for the security section.  If you feel that CMAC should be used just because, we can discuss it further.

WEAK EC GROUPS
This document specifies the use of SECP160R1. This is not an acceptably
secure group.

Proposed action: REmove support for SECP160R1.

SECP160R1 is carried over from RFC 7401.  At the time, there were participants that wanted something for those really limited CPUs (like the 8501).

Now we have EC25519 and it can be argued that its performance and transmitted key size (for constrained networks) meets the needs for those that wanted SECP160R1.  My concern is I have no data on the CPU cost on a 8501 for SECP160R1 to make a valid comparison to EC25519.

Further the adding of EC25519 does not replace SECP160R1 in HIP-BEX (RFC 7401), so at best, all I could do is not include it in HIP-DEX, it still would be valid for HIP-BEX.

For now I am leaving SECP160R1 in unless I get feedback that we can deprecate it for EC25519.  Note that a separate draft, draft-moskowitz-hip-new-crypto, is adding EDDSA25519 for HIP-BEX and there we can deprecate SECP160R1.


FAILURE TO VALIDATE PUBLIC KEYS
This document does not require that implementations validate
the remote public key. With the NIST curves specified here,
this leads to straightforward key extraction attacks, which
is a very serious problem when you have a static key.

Proposed action: Require point validation. The TLS 1.3 has
text you can borrow.

I am assuming you mean sec 4.2.8.2 of RFC8446?

I am shocked that we have to tell implementers to test that the EC PK is a valid point.  Not.

I will use this text as the basis for an addition subsection in Security Considerations.

AEAD
This document makes use of non-AEAD symmetric algorithms. This has been
found to be hazardous in practice.

Proposed action: use only AEAD algorithms.

All HIP payloads that occur after there are agreed keys, are authenticated (MACed).  Few payloads have encrypted parameters. Further the way parameters are organized within the payload it is possible that the encrypted parameters would not be adjacent, making further complications.   It does not make sense to switch to an AEAD with this design.  Plus an AEAD adds processing overhead.  IF NIST had completed the lightweight crypto competition at design time, then AEAD may have been given closer study.

REPLAY ATTACK ON AKE
The only entropy provided to the AKE is the puzzle, which means
that it's possible for an attacker to replay the responder's
messages, leaving the initiator believing that he has created
a connection when in fact he has not. The attacker will not
be able to send data messages because the initiator contributes
data to the eventual keys, but we generally try to avoid this
property.

More importantly, this is unnecessary, and can be resolved
by changing the odd "encrypt half the key" mechanism used here
with a conventional nonce structure in which each side sends
a random value and then you HKDF it with the DH shared secret.
This would have the effect of removing the replay attack
and be easier to analyze.

Proposed action: restructure the AKE to mix nonces + DH
into the key schedule.

This is a good suggestion.  I am still studying it for the best way to implement it.  I do expect to have something done for a dex-13.txt draft.



-Ekr


Robert Moskowitz

--------------CAC10BB72A8F58FA785F33B2-- From nobody Thu Jan 30 05:02:23 2020 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC3C1200DF; Thu, 30 Jan 2020 05:02:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: hipsec@ietf.org, evyncke@cisco.com, hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158038934112.10210.14742624703480559294.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2020 05:02:21 -0800 Archived-At: Subject: [Hipsec] hip - Not having a session at IETF 107 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 13:02:21 -0000 Gonzalo Camarillo, a chair of the hip working group, indicated that the hip working group does not plan to hold a session at IETF 107. This message was generated and sent by the IETF Meeting Session Request Tool.