[Lake] Additional key exchange draft

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 11 July 2019 02:50 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8526120019 for <lake@ietfa.amsl.com>; Wed, 10 Jul 2019 19:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.894
X-Spam-Level: ****
X-Spam-Status: No, score=4.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RZsW-MA1BquR for <lake@ietfa.amsl.com>; Wed, 10 Jul 2019 19:50:19 -0700 (PDT)
Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 A914212008F for <lake@ietf.org>; Wed, 10 Jul 2019 19:50:19 -0700 (PDT)
Received: by mail-oi1-f170.google.com with SMTP id w7so3324705oic.3 for <lake@ietf.org>; Wed, 10 Jul 2019 19:50:19 -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:from:date:message-id:subject:to; bh=FJ6RiIJlwvrOqdE69V9G4XpiZ6m2SvoAREKC6eOXDWc=; b=ZRh0eJfGy2ObLzqYxvR3eHsecmkZNvf5NY+AB44EY8Znp2CrsMdKkmgZD51Tnee8oi DDOSjYaeHNwi25qDiSNiSl6niD8Q+qtW60FmEaF/olel4jQA76uK9ZYHxkA38t5rBgGu aGD+bgaDw4ncjNGbAEtWHsexwoZQhis9g+9MNvc+KozPTnuAm4/NOAqHI3MJIc13oScF WWStMWXJ4DNkVywZDyB5qAuyxt10SBS7/NcAN7NeRReskS9WvzaCWjHIxDqACOPwTEZW sio6IKH5otrUp0FgcQBLYRWymAAFIawwev01wKaq/vMBHVnlqOOX+uaYwHapHv0ru/My frmQ==
X-Gm-Message-State: APjAAAX7woQicp/p7abv3tvsgq21kYzUjNhCWP0Q5/AHyR+kEV6s3Tdv 7StRuCVS9ccuwcucAUGmmVcqry5EwR8vbH5KNT8Vgpp3
X-Google-Smtp-Source: APXvYqyHpQZ/65lszqw8Y5kWy+ycqBuRyjkjBX93hx3jBOIGGYDaU4vl2p90P6Vvl0aCxqoaFdQNxEH7IeRMBDnT+W4=
X-Received: by 2002:aca:55c2:: with SMTP id j185mr1058510oib.100.1562813418436; Wed, 10 Jul 2019 19:50:18 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 10 Jul 2019 22:50:08 -0400
Message-ID: <CAMm+LwiT4U+d1HLF0xD5G6MrY1WKyfQ6dwk+iLrRjDatOp8+vw@mail.gmail.com>
To: lake@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a7fc95058d5eda2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/fDLe4VN7eSkAGDu7AiwXW_B77cI>
Subject: [Lake] Additional key exchange draft
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2019 02:50:22 -0000

Only just found out about the BOF.

I have a lightweight key exchange that I have been using for a while that
may be applicable to this problem area. People tell me that it is similar
to one that Sun proposed for IPSEC

It is submitted as an ID but my tools are targeting the new format which
allows superscripts and subscripts and that isn't accepted by the IETF
toolset for another couple of months.

The readable version is here:

http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html

There is a plaintext version if that is your bag:

https://tools.ietf.org/html/draft-hallambaker-mesh-cryptography-02

The observation here is that standard DH provides a key exchange with
mutual authentication. The only reason the authentication of the client is
lost is that we want forward secrecy.

But DH keys can be manipulated in interesting ways. For DH or ECDH
variants, I can tell you the public key that corresponds to the sum of two
private keys just by adding the private keys.

What this means is that if Alice and Bob have validated public keys, we can
do a key exchange that provides mutual authentication and forward secrecy
by generating an ephemeral key pair and adding it to the authenticated one.

Like I said, only just found out about the group. Would have made this
draft a higher priority if I had. I have code but I didn't get round to
putting the data from the examples into this particular draft. I got up to
part IV before the cutoff and the crypto is part IIV.


One point I feel is very important here is that using a key exchange
algorithm to achieve a key exchange is much better than the schemes we
currently use in TLS where data ends up being encrypted or worse, signed.
These provide side channel attacks or proof of a party having been in the
communication. That is not something I feel is acceptable for a transport
layer communication.

I can produce a version of the draft with examples if it will help. This is
a BOF though and I am sure I am not going to be the only person thinking on
these lines.