From nobody Mon Sep 2 14:21:01 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645701201A3 for ; Mon, 2 Sep 2019 14:20:41 -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 3kXXTbIqqyrw for ; Mon, 2 Sep 2019 14:20:40 -0700 (PDT) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (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 0193112021C for ; Mon, 2 Sep 2019 14:20:39 -0700 (PDT) Received: by mail-oi1-f169.google.com with SMTP id v12so11225153oic.12 for ; Mon, 02 Sep 2019 14:20:39 -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=o0plS9kcB0EyY+Q2aGR7HN/2gyh28jQNqomQTolsBcc=; b=UjjJSx92MZllet6+Slso5Rt+pML19LfRqDWqD/Wo7IP8MdtYNr28gLGpAmfFT+hA01 c1f/+RFmWPMIwh+bjjBbm4xzB3d4My3GTlxzHgwOZZMTlkHVavYu/k99Ep1u/8J2CLsZ z+2SZ8nZ2i2CB4eSNCa6XTGdbYPpBzjoulkswPlTd5Fgkwm5ctrHsGGEjG8FndJBKujZ HvE87wpLuART0JeTprBi8SaiDG+28QuGJx6VmM7hX6/4r8FdxRYRxTcsKNxXSRtFLJ0o vGoY6WpAj6x/1SjP/KTy/hB6cgZzue2MQblxVZ0uzNGb0iXx+GXIb+kLPbZNbh6y4ECh SG+g== X-Gm-Message-State: APjAAAWI/20Hw086lfThmSUFrrA4lDcFa78BRR4rONHC8YlkurSfdMUB fIO8bbLJmk1O1Lvc6P9AmbILekPFrDawc5qvdS81aeI1 X-Google-Smtp-Source: APXvYqwMnqqKkDdxZEYHdmN1heZrXBpO/tz56BNAOCjP6trlNBQboIkSCkDW7BjKhg9o8H0dEJirAeTowvyddMsEOzc= X-Received: by 2002:aca:782:: with SMTP id 124mr20768285oih.95.1567459239076; Mon, 02 Sep 2019 14:20:39 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Mon, 2 Sep 2019 17:20:30 -0400 Message-ID: To: mathmesh@ietf.org, cfrg@irtf.org Content-Type: multipart/alternative; boundary="000000000000252a0c0591988bd2" Archived-At: Subject: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:20:52 -0000 --000000000000252a0c0591988bd2 Content-Type: text/plain; charset="UTF-8" [ccd to CFRG for comment] At the moment, the approach used to escrow Mesh keys is * Generate a master secret of at least 128 bits * Use the master secret to derive an AES 256 encryption key and initialization vector under which the private key information is encrypted. * Use a content digest of the master secret as the identifier under which the escrow record is stored on some sort of service (TBS). * Use Shamir secret sharing to split the master secret n out of m ways This works with any public key algorithm but it requires a service. It has since occurred to me that I may have gone down a blind alley because I designed this part of the system back when RSA was still the default algorithm (we were discussing the CFRG curves at the time). I am now thinking about using this approach: * Generate a master secret of at least 128 bits * Use a KDF to generate the master key pairs for Encryption and Signature from the master secret * Use Shamir secret sharing to split the master secret n out of m ways Thoughts? One side benefit of this approach is that it becomes quite easy to give test vectors, just give the master secret used to generate the key pairs. I know 128 bits is short, my preference is for 256 bits. But given the number of times this ends up going through SHA-2-512, I am not really worried. --000000000000252a0c0591988bd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[cc= d to CFRG for comment]

At= the moment, the approach used to escrow Mesh keys is

* Generate a master secret of at least 128 bit= s=C2=A0=C2=A0
* Use the master secret to derive an AES 256 encryption key and initiali= zation vector under which the private key information is encrypted.
* Use a content digest= of the master secret as the identifier under which the escrow record is st= ored on some sort of service (TBS).
* Use Shamir secret sharing to split the=C2=A0master s= ecret=C2=A0 n out of m ways

This works with any public key algorithm but it requires a service. It h= as since occurred to me that I may have gone down a blind alley because I d= esigned this part of the system back when RSA was still the default algorit= hm (we were discussing the CFRG curves at the time). I am now thinking abou= t using this approach:

* = Generate a master secret of at least 128 bits=C2=A0=C2=A0=C2=A0=C2=A0
* Use a KDF to g= enerate the master key pairs for Encryption and Signature from the master s= ecret
* Use= Shamir secret sharing to split the=C2=A0master secret=C2=A0 n out of m way= s=C2=A0=C2=A0

Thought= s?

One side benefit of th= is approach is that it becomes quite easy to give test vectors, just give t= he master secret used to generate the key pairs.

I know 128 bits is short, my preference is for 256 = bits. But given the number of times this ends up going through SHA-2-512, I= am not really worried.=C2=A0
--000000000000252a0c0591988bd2-- From nobody Mon Sep 2 22:08:04 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174FD1201AA for ; Mon, 2 Sep 2019 22:08:03 -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 LqUdtzw4XKbB for ; Mon, 2 Sep 2019 22:08:01 -0700 (PDT) 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 3C666120020 for ; Mon, 2 Sep 2019 22:08:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 55D8E3818E; Tue, 3 Sep 2019 01:06:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0373EC5E; Tue, 3 Sep 2019 01:08:00 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: mathmesh@ietf.org, cfrg@irtf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 05:08:03 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > This works with any public key algorithm but it requires a service. ... > * Generate a master secret of at least 128 bits > * Use a KDF to generate the master key pairs for Encryption and Signature > from the master secret > * Use Shamir secret sharing to split the master secret n out of m ways > Thoughts? I don't understand how the need for the service is different. > One side benefit of this approach is that it becomes quite easy to give > test vectors, just give the master secret used to generate the key > pairs. please expand. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1t9S8ACgkQgItw+93Q 3WXXjAf/UEH9y3IWuDsKxYDd1ZRsBP+cy0ks2eMFkvo7xE+hnMEkG2XOJdgVvuY+ GeSd28h7jKhM3NXn8DKsuVfiIIQDkc1CgOkdCcu7VlHu7F2vG6X2GTh1bNTXN9of Lv24WX27GAtShSQpM0BotbLUtzoRQk4Dlhj9H0InQ3R20I76jqOAKx/rmkSdp5oM Q5XGzJCTRvmnidk4Ld3jSB7/K5cMqB9xQEdfg/kf9/G9axMBSOtINI6zDrgG38kn yMNcDjGpicPrUrfTzhGEZ8LL2rsrYV3hCgPIYefRhm4FZGnGRfZA+12dZTI8Rm+9 /PkyXDDT02i0qROXzFVqQnq0g6X/CQ== =RRO0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 3 07:51:33 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B431208D4 for ; Tue, 3 Sep 2019 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, 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 8UBhlzTJwLcu for ; Tue, 3 Sep 2019 07:51:23 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.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 547621208AF for ; Tue, 3 Sep 2019 07:51:23 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id p23so17043126oto.0 for ; Tue, 03 Sep 2019 07:51:23 -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=gSOp/ald9IkSR811vnV6O+bm5gaZL0C6YCgf2HZHUwo=; b=fIW4sWOrKSeLYJ43NhAW4+zPsWIyR1HYVkTFc1a8YtWModQzO4nUL95OSZxmobNgKa v9qUK/cvEAeUfu7E40YmWvCGhoWc2fiDbR99NL2DYLAIbUwbQouurE2Pbeuu2HmCMOtO PPfF284N8JD0tjSa8y4ec+LzQ+QW5xOpkYkojSz/OPcc24nmLwcEJUrp7rMWwQYLszJo /FrlflkURYgYzr8SLxyS7juLHcUqi3/tPxQUXOKnRDP1qEpr1UiGiL+zf0BmkcoDEHUH moLcKM6aAdXEN5HCsIwCH34mCuEe+mxX3EvFGdCV0hJD6fT+oJWdOucION4JfB5GCk1L IPjQ== X-Gm-Message-State: APjAAAWfggOuASXYcx//SBqewWdrMgLjNEVmd2Me+CqMyk2DZK5Gihpy m3TjhpRMe96tRveF1OURNZyJyBOKSyZYhz/78RDNkrE5 X-Google-Smtp-Source: APXvYqyXPv98pVmOR+GkiTxA38uMCjEk/i83Zt0PvYqQygJVcY1pE/7bvACYQQTB5lRMLiOc86pu8MM/8TGftvY96j8= X-Received: by 2002:a9d:4e97:: with SMTP id v23mr5232228otk.112.1567522282538; Tue, 03 Sep 2019 07:51:22 -0700 (PDT) MIME-Version: 1.0 References: <6241.1567487279@localhost> In-Reply-To: <6241.1567487279@localhost> From: Phillip Hallam-Baker Date: Tue, 3 Sep 2019 10:51:11 -0400 Message-ID: To: Michael Richardson Cc: mathmesh@ietf.org, cfrg@irtf.org Content-Type: multipart/alternative; boundary="000000000000d40d720591a7388c" Archived-At: Subject: Re: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 14:51:26 -0000 --000000000000d40d720591a7388c Content-Type: text/plain; charset="UTF-8" OK so here is the difference. In each case Alice's master secret is 97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0 This has the UDF representation: ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA We can split that using shamir secret sharing: f(1) = SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I f(2) = SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A f(3) = SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C f(4) = SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U f(5) = SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q The difference is how we generate the private key pairs. What is done now is that the Master Profile key pairs for encryption and signature are generated in the normal way. The private keys are wrtiten out to an escrow record that is encrypted under ECL3-5Q4M... So recovery requires at least three of the key shares plus the encrypted escrow record. The other way to go about it is to use a KDF to generate the private keys for the master profile: Signing Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0], "mmm/mesh-signature/Ed448". 448) Escrow Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0], "mmm/mesh-escrow/X448", 448) So now recovery of the escrow record ONLY requires the master secret ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record. Pros: More convenient. Cons: The private keys have less ergodicity and are related by means of the HMAC function. If we are confident of our algorithms being secure, 2^128 is an infeasible work factor. And if you look into how the scheme is implemented, we are not talking about SHA-2-512 (x), we are talking about SHA-2-512 ( SHA-2-512 ( SHA-2-512 ( SHA-2-512 (x) ) ) ). If we are not confident of our algorithms being secure, we can use any size work factor we like up to the size of our private key size. The recovery shares just get a bit larger. What I like about this is that I can easily specify an example key set just by giving the master secret. On Tue, Sep 3, 2019 at 1:08 AM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > This works with any public key algorithm but it requires a service. > > .... > > > * Generate a master secret of at least 128 bits > > * Use a KDF to generate the master key pairs for Encryption and > Signature > > from the master secret > > * Use Shamir secret sharing to split the master secret n out of m > ways > > > Thoughts? > > I don't understand how the need for the service is different. > > > One side benefit of this approach is that it becomes quite easy to > give > > test vectors, just give the master secret used to generate the key > > pairs. > > please expand. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- > Mathmesh mailing list > Mathmesh@ietf.org > https://www.ietf.org/mailman/listinfo/mathmesh > --000000000000d40d720591a7388c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK = so here is the difference.=C2=A0

In each case
Alice's maste=
r secret is
     97 BE C3 8C  EC 32 E3 A8  14 BE 38 AC  49 B3 58 D0
This has the UDF representation:
   ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA

We can split that using shamir secret sharing:
   f(1) =3D SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I
   f(2) =3D SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A
   f(3) =3D SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C
   f(4) =3D SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U
   f(5) =3D SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q

The difference is how we generate the private= key pairs.
What is done = now is that the Master Profile key pairs for encryption and signature are g= enerated in the normal way. The private keys are wrtiten out to an escrow r= ecord that is encrypted under=C2=A0ECL3-5Q4M...

So recovery requires at least three of the key shares plus the encr= ypted escrow record.


=
The other way = to go about it is to use a KDF to generate the private keys for the master = profile:

Signing Key =3D = HKDF ( [97 BE C3 8C E= C 32 E3 A8 14 BE 38 AC 49 B3 58 D0], "mmm/mesh-signature/Ed448"= . 448)
Escrow Key =3D HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0], "mmm/mesh-escrow= /X448", 448)=C2=A0=C2=A0

So now recovery of the escrow record ONLY requires the mast= er secret=C2=A0ECL3-5Q= 4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record.

Pros: More convenient.
Cons: The private k= eys have less ergodicity and are related by means of the HMAC function.

If we are confident of our a= lgorithms being secure, 2^128 is an infeasible work factor. And if you look= into how the scheme is implemented, we are not talking about SHA-2-512 (x)= , we are talking about SHA-2-512 ( SHA-2-512 ( SHA-2-512 ( SHA-2-512 (x)=C2=A0 )=C2=A0 )=C2=A0 ).

If we are not confident of our algorithms being secure, we ca= n use any size work factor we like up to the size of our private key size. = The recovery shares just get a bit larger.


What I like about this is that I can easily specify an example = key set just by giving the master secret.=C2=A0


On Tue, Sep 3, 2019 at 1:08 AM M= ichael Richardson <mcr+ietf@s= andelman.ca> wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > This works with any public key algorithm but it requires= a service.

....

=C2=A0 =C2=A0 > * Generate a master secret of at least 128 bits
=C2=A0 =C2=A0 > * Use a KDF to generate the master key pairs for Encrypt= ion and Signature
=C2=A0 =C2=A0 > from the master secret
=C2=A0 =C2=A0 > * Use Shamir secret sharing to split the master secret= =C2=A0 n out of m ways

=C2=A0 =C2=A0 > Thoughts?

I don't understand how the need for the service is different.

=C2=A0 =C2=A0 > One side benefit of this approach is that it becomes qui= te easy to give
=C2=A0 =C2=A0 > test vectors, just give the master secret used to genera= te the key
=C2=A0 =C2=A0 > pairs.

please expand.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--
Mathmesh mailing list
Mathmesh@ietf.org
https://www.ietf.org/mailman/listinfo/mathmesh
--000000000000d40d720591a7388c-- From nobody Tue Sep 3 11:07:45 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E0E12006F for ; Tue, 3 Sep 2019 11:07:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cryptonector.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 S6xLeXWsGHRV for ; Tue, 3 Sep 2019 11:07:42 -0700 (PDT) Received: from cadetblue.birch.relay.mailchannels.net (cadetblue.birch.relay.mailchannels.net [23.83.209.28]) (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 AFC2F12013A for ; Tue, 3 Sep 2019 11:07:42 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DA3C320FC7; Tue, 3 Sep 2019 18:07:41 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-168-83.trex.outbound.svc.cluster.local [100.96.168.83]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B9C5021CBD; Tue, 3 Sep 2019 18:07:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a94.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Tue, 03 Sep 2019 18:07:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Chief-Abortive: 6a2b3752748f4f63_1567534061176_1320022940 X-MC-Loop-Signature: 1567534061176:4214927047 X-MC-Ingress-Time: 1567534061175 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 503E280764; Tue, 3 Sep 2019 11:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QZW30cTlLZXq3C 2ssT0qd5uF8l8=; b=QhxjMBOlhhlbNioF2fxfeU/JMMVK0akKG88ELaJ9+ZlZ88 vf0vRFnMQn67U5IyLKwgt3eX2S3Oe3F86TCHeAe6TiCNU0y/u1nXIhTcs+1dH8aL s3N2yJEOa1LMIMeKb66nrKxC+pYBuChcCr5mwr3dNNHlhcVlIf2+AWaXdWXpM= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 022A48076A; Tue, 3 Sep 2019 11:07:32 -0700 (PDT) Date: Tue, 3 Sep 2019 13:07:30 -0500 X-DH-BACKEND: pdx1-sub0-mail-a94 From: Nico Williams To: Phillip Hallam-Baker Cc: mathmesh@ietf.org Message-ID: <20190903180729.GF7920@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudejfedgledvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Mathmesh] [Cfrg] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 18:07:45 -0000 On Mon, Sep 02, 2019 at 05:20:30PM -0400, Phillip Hallam-Baker wrote: > At the moment, the approach used to escrow Mesh keys is > > * Generate a master secret of at least 128 bits > * Use the master secret to derive an AES 256 encryption key and > initialization vector under which the private key information is encrypted. > * Use a content digest of the master secret as the identifier under which > the escrow record is stored on some sort of service (TBS). > * Use Shamir secret sharing to split the master secret n out of m ways > > This works with any public key algorithm but it requires a service. It has > since occurred to me that I may have gone down a blind alley because I > designed this part of the system back when RSA was still the default > algorithm (we were discussing the CFRG curves at the time). I am now > thinking about using this approach: > > * Generate a master secret of at least 128 bits > * Use a KDF to generate the master key pairs for Encryption and Signature > from the master secret > * Use Shamir secret sharing to split the master secret n out of m ways > > Thoughts? I don't see why in the first case you'd need a separate service to store the private keys encrypted in the master secret. All the entities that hold secret shares can also hold copies of the encrypted record along with the secret shares. In any case, both of these approaches have similar security properties. Most importantly, compromise of a master secret compromises all the private keys it protects. However, you might find it difficult to generate key pairs from a master secret, especially if you ever need to generate keys on a hardware token. If you won't have that requirement, and if you're willing to have that as an anti-requirement, then the second scheme is simpler, indeed, and the entities that store key shares will need to store smaller records. > One side benefit of this approach is that it becomes quite easy to give > test vectors, just give the master secret used to generate the key pairs. > > I know 128 bits is short, my preference is for 256 bits. But given the > number of times this ends up going through SHA-2-512, I am not really > worried. In a PQ world you want 256 bits of entropy, otherwise 128 bits is sufficient. Nico -- From nobody Tue Sep 3 23:46:40 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72C11200CE for ; Tue, 3 Sep 2019 23:46:37 -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, 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 F5cG9Iksk-mO for ; Tue, 3 Sep 2019 23:46:35 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975C81200C3 for ; Tue, 3 Sep 2019 23:46:35 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [89.248.140.11]) by relay.sandelman.ca (Postfix) with ESMTPS id A92711F45A; Wed, 4 Sep 2019 06:46:33 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 61688FE9; Wed, 4 Sep 2019 02:47:07 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: mathmesh@ietf.org, cfrg@irtf.org In-reply-to: References: <6241.1567487279@localhost> Comments: In-reply-to Phillip Hallam-Baker message dated "Tue, 03 Sep 2019 10:51:11 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 04 Sep 2019 02:47:07 -0400 Message-ID: <14973.1567579627@dooku.sandelman.ca> Archived-At: Subject: Re: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 06:46:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > OK so here is the difference. okay, thank you. I didn't realize the "done now" version encrypted the private keys like tha= t. I assumed in my brain that it would always be the KDF version :-) > Escrow Key =3D HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0], > "mmm/mesh-escrow/X448", 448)=20 > >So now recovery of the escrow record ONLY requires the master secret >ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record. I'm confused here. Isn't the private key is deterministically created from= the master key, why do we need an escrow key? Won't the key need to be number= ed so that one knows which of potentially many pieces are generated? Or is there a master key for each key that Alice needs to generate? > Pros: More convenient. Cons: The private keys have less ergodicity a= nd > are related by means of the HMAC function. I think that it's okay for the reasons you gave. Nico Williams wrote: > I don't see why in the first case you'd need a separate service to > store the private keys encrypted in the master secret. All the > entities that hold secret shares can also hold copies of the encrypted > record along with the secret shares. This allows the secrets to split and sent to appropriate entities once at t= he beginning of the process, and they never need to be updated again. Alice can generate as many keys (and as frequently) as she wishes, interacting on= ly with the escrow service. Assuming that I understand correctly. > However, you might find it difficult to generate key pairs from a > master secret, especially if you ever need to generate keys on a > hardware token. If you won't have that requirement, and if you're > willing to have that as an anti-requirement, then the second scheme is > simpler, indeed, and the entities that store key shares will need to > store smaller records. You are saying: If you use a hardware token, then you need the escrow servi= ce. Isn't it the case that some hardware tokens have no mechanism to get the private key out? I guess they are SOL regardless of scheme. Couldn't we generate per-key escrow keys from the master key using the same KDF mechanism? Doesn't that get us the best of both worlds, with the confusion as to how the different=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1vXeoACgkQlUzhVv38 QpD+YAf9F8qTqnnrULYBraCixjH2lA8whQm+guEQcVMA5DAVBQYRmluld2ncnRgM KzyjQ5P/myp8eu0dZlRa5UZT1Y+sqIbvxiCP0qaFlU+3YYOf0tRVAQpMpL5C1d1b pahaCCDfhMe1AnDEMzwCmNEJNhOWz2AbtjIGydJEEJ7RAg45mAjNa/yWmdeXUaM3 XXVkjCIYN0U5bF1Hu7pJBqhu/oG5iPv1Io/W/2sLaV2Hz4oycd4mImSM/9rh5vBv gzLYOqIxLaZ5YzFOhWXtaZOzvyaRBDxdPGHgZxyoN0aUuquGRIOvoefXkaxdmFVS 2gWKu3F6qXl5rcX/uXEs6fcY7oyrZg== =Yexj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 5 19:26:46 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2398C12011C for ; Thu, 5 Sep 2019 19:26:37 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 v9RxDHD4Obos for ; Thu, 5 Sep 2019 19:26:35 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 07860120043 for ; Thu, 5 Sep 2019 19:26:35 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id h4so3697069oih.8 for ; Thu, 05 Sep 2019 19:26:34 -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=OK0fXHI0UHMdmaZE4f1ZRpFc1BqpJBPFkO8mwvO7LTw=; b=VPqttkeYxPz804pqVfxacwNLgocay6wq7zZW1DUN2cch6X7TCkslAltgGP7WRacCBw TzmMtJUaN70AhNSALW9DBcTgvAxzfmcNjg2T7W+CM5yaOs9E/DOpCCLgi5jI5Xa+ZiZk 1MV/9kIR0md13qea3UTf0DnyRiQ7AupAorl3Wfhiy28u4YjyLapDJUBSRaFwJPyQDuFT IJwvHlZTnscNfIqFogS0YRaq8Fa9Ft+waR2NzV3oPVzU81bCtaXNjlJZYKfSEbWxzaJ6 DbX+K17RpxKanfrPoGqI0HzA4e+5d80GocklAnOngWEi8EOnY3vvw43Ljykh6jVIvlc0 yUBg== X-Gm-Message-State: APjAAAWEispcgQhTtOGU/WycsEggk7uXJjCqXKWdiwenz9nw5kWSzXI6 0MWl2dZYDdljQbM31UT610xLU2YeHxfjd2YeZP+pdJT+ X-Google-Smtp-Source: APXvYqx7zryw23CRAPxLrk3701Km7IuZeXrk83gpy33v7tymA4B+2X5fRy+tpyR42nRp+R+7/49SpSVvF6gvCyVLaXE= X-Received: by 2002:a05:6808:296:: with SMTP id z22mr638416oic.6.1567736794145; Thu, 05 Sep 2019 19:26:34 -0700 (PDT) MIME-Version: 1.0 References: <6241.1567487279@localhost> <14973.1567579627@dooku.sandelman.ca> In-Reply-To: <14973.1567579627@dooku.sandelman.ca> From: Phillip Hallam-Baker Date: Thu, 5 Sep 2019 22:26:22 -0400 Message-ID: To: Michael Richardson Cc: mathmesh@ietf.org, cfrg@irtf.org Content-Type: multipart/alternative; boundary="000000000000b767e10591d92ac4" Archived-At: Subject: Re: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 02:26:37 -0000 --000000000000b767e10591d92ac4 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > OK so here is the difference. > > okay, thank you. > I didn't realize the "done now" version encrypted the private keys like > that. > I assumed in my brain that it would always be the KDF version :-) > > > Escrow Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0], > > "mmm/mesh-escrow/X448", 448) > > > >So now recovery of the escrow record ONLY requires the master secret > >ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record. > > I'm confused here. Isn't the private key is deterministically created > from the > master key, why do we need an escrow key? Won't the key need to be > numbered > so that one knows which of potentially many pieces are generated? Or is > there a master key for each key that Alice needs to generate? > Ah, the escrow key is the 'master escrow key' that may be used to create an escrow record for the user's application keys should they choose. So let us imagine that I am using OpenPGP and disk level encryption. I will have an encryption key for both applications. I might not want to escrow the encryption keys for the applications at all but it I did, I could create key shares for those applications as for my mesh signature key or I could just escrow them to my mesh escrow key. Sorry for the confusion. There are two different levels of encryption going on. > > Pros: More convenient. Cons: The private keys have less ergodicity > and > > are related by means of the HMAC function. > > I think that it's okay for the reasons you gave. > > Nico Williams wrote: > > I don't see why in the first case you'd need a separate service to > > store the private keys encrypted in the master secret. All the > > entities that hold secret shares can also hold copies of the > encrypted > > record along with the secret shares. > > This allows the secrets to split and sent to appropriate entities once at > the > beginning of the process, and they never need to be updated again. Alice > can generate as many keys (and as frequently) as she wishes, interacting > only > with the escrow service. Assuming that I understand correctly. > Allowing escrow of the secrets alone allows them to be protected using steganographic techniques. For example, let us say we want to hide the secret SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I So lets render it in Base-32768-English which uses a dictionary of 32678 words to represent the code points. It (might) now become Marmalade Snorkel Tuna Smoked Perambulate Throat Wombat Perfume Dredging Tufted That is something I can read to someone over a (secure) telephone line or write down in a book > > However, you might find it difficult to generate key pairs from a > > master secret, especially if you ever need to generate keys on a > > hardware token. If you won't have that requirement, and if you're > > willing to have that as an anti-requirement, then the second scheme > is > > simpler, indeed, and the entities that store key shares will need to > > store smaller records. > > You are saying: If you use a hardware token, then you need the escrow > service. > Isn't it the case that some hardware tokens have no mechanism to get the > private key out? I guess they are SOL regardless of scheme. > I agree. If someone is using a hardware token, the hardware token needs to manage the escrow mechanism itself (e.g. like the way Luna cards do). But it will in any case need a way to import a private master key generated elsewhere. > Couldn't we generate per-key escrow keys from the master key using > the same KDF mechanism? Doesn't that get us the best of both worlds, > with the confusion as to how the different > Hmm... that might be the way to do it. The only problem is that then you need access to the offline master to be able to generate application key sets and the idea of the offline master is that you should only need to ever use it when changing your administration device. --000000000000b767e10591d92ac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson &= lt;mcr+ietf@sandelman.ca>= wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > OK so here is the difference.

okay, thank you.
I didn't realize the "done now" version encrypted the private= keys like that.
I assumed in my brain that it would always be the KDF version :-)

> Escrow Key =3D HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0= ],
> "mmm/mesh-escrow/X448", 448)
>
>So now recovery of the escrow record ONLY requires the master secret >ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record= .

I'm confused here.=C2=A0 Isn't the private key is deterministically= created from the
master key, why do we need an escrow key?=C2=A0 =C2=A0Won't the key nee= d to be numbered
so that one knows which of potentially many pieces are generated? Or is
there a master key for each key that Alice needs to generate?

Ah, the escrow key is the 'master escrow key' that may be used t= o create an escrow record for the user's application keys should they c= hoose.

So let us imagine = that I am using OpenPGP and disk level encryption. I will have an encryptio= n key for both applications. I might not want to escrow the encryption keys= for the applications at all but it I did, I could create key shares for th= ose applications as for my mesh signature key or I could just escrow them t= o my mesh escrow key.

Sor= ry for the confusion. There are two different levels of encryption going on= .



=C2=A0
=C2=A0 =C2=A0 > Pros: More convenient.=C2=A0 Cons: The private keys have= less ergodicity and
=C2=A0 =C2=A0 > are related by means of the HMAC function.

I think that it's okay for the reasons you gave.

Nico Williams <nico@cryptonector.com> wrote:
=C2=A0 =C2=A0 > I don't see why in the first case you'd need a s= eparate service to
=C2=A0 =C2=A0 > store the private keys encrypted in the master secret.= =C2=A0 All the
=C2=A0 =C2=A0 > entities that hold secret shares can also hold copies of= the encrypted
=C2=A0 =C2=A0 > record along with the secret shares.

This allows the secrets to split and sent to appropriate entities once at t= he
beginning of the process, and they never need to be updated again.=C2=A0 Al= ice
can generate as many keys (and as frequently) as she wishes, interacting on= ly
with the escrow service.=C2=A0 Assuming that I understand correctly.

Allowing escrow of the secrets alone allows them to be protected = using steganographic techniques.

For example, let us say we want to hide the secret=C2=A0SAYE-UHOY-TV= ZO-LPGT-ZAGE-7JUW-6MTJ-I

So lets render it in Base-32768-Engli= sh which uses a dictionary of 32678 words to represent the code points. It = (might) now become=C2=A0

Marmalade Snorkel Tuna Smoked Perambulate Throat W= ombat Perfume Dredging Tufted

That is something I can read to someone over = a (secure) telephone line or write down in a book


=
=C2=A0
=C2=A0 =C2=A0 > However, you might find it difficult to generate key pai= rs from a
=C2=A0 =C2=A0 > master secret, especially if you ever need to generate k= eys on a
=C2=A0 =C2=A0 > hardware token.=C2=A0 If you won't have that require= ment, and if you're
=C2=A0 =C2=A0 > willing to have that as an anti-requirement, then the se= cond scheme is
=C2=A0 =C2=A0 > simpler, indeed, and the entities that store key shares = will need to
=C2=A0 =C2=A0 > store smaller records.

You are saying: If you use a hardware token, then you need the escrow servi= ce.
Isn't it the case that some hardware tokens have no mechanism to get th= e
private key out?=C2=A0 I guess they are SOL regardless of scheme.

I agree. If someone is using a hardware token, the hardware token ne= eds to manage the escrow mechanism itself (e.g. like the way Luna cards do)= . But it will in any case need a way to import a private master key generat= ed elsewhere.

=C2=A0
Couldn't we generate per-key escrow keys from the master key using
the same KDF mechanism?=C2=A0 Doesn't that get us the best of both worl= ds,
with the confusion as to how the different

=
Hmm... that might be= the way to do it. The only problem is that then you need access to the off= line master to be able to generate application key sets and the idea of the= offline master is that you should only need to=C2=A0 ever use it when chan= ging your administration device.
--000000000000b767e10591d92ac4-- From nobody Sun Sep 8 04:45:29 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF012003E for ; Sun, 8 Sep 2019 04:45:17 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 4VgG9typQ_0H for ; Sun, 8 Sep 2019 04:45:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497BB12001E for ; Sun, 8 Sep 2019 04:45:15 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [88.214.187.115]) by relay.sandelman.ca (Postfix) with ESMTPS id 0F7081F459; Sun, 8 Sep 2019 11:45:14 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 067FB2025; Sun, 8 Sep 2019 12:45:36 +0100 (WEST) From: Michael Richardson To: Phillip Hallam-Baker cc: mathmesh@ietf.org, cfrg@irtf.org In-reply-to: References: <6241.1567487279@localhost> <14973.1567579627@dooku.sandelman.ca> Comments: In-reply-to Phillip Hallam-Baker message dated "Thu, 05 Sep 2019 22:26:22 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 08 Sep 2019 12:45:36 +0100 Message-ID: <28565.1567943136@dooku.sandelman.ca> Archived-At: Subject: Re: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2019 11:45:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I understand now. The master escrow key can be used to escrow both asymmetr= ic private keys, but also to escrow session-level keys used for specific purposes (such as the disk encryption example) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl106d8ACgkQlUzhVv38 QpCMLQf9FHEspDAHv5um5QXMWL8aAErLMk03PxRMS4dKfagaGk2Egskada1Z1vaz VwQjHiqoZarBWEWLCLpO1KI+tf+Muemhott93i13ZKs3IwJvOQ/HpNAzwOdyss6t E2IiWNl9hnehZ6FwwWtv6U2G/RRwGDAob1mNefOWY52QFdTTwuMSQafil14810lr UeQfXaBul+3ZWulL8q8w8ZuH3xEKh2h3YC76PJZhLBA1r0+y7hMlbVlxiEX9D3GO IwYJgwzjRcCsAZIL7eSYNgUAyLBdLzFeNOj3LAwZC3rmmr95BSTnqq7ypzSwKl89 ROBOCgi1LrvKVqa/SzlBfaoRgihg7g== =G++G -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 9 08:09:26 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A441120818 for ; Mon, 9 Sep 2019 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7O0Mm6pON3Cb for ; Mon, 9 Sep 2019 08:09:23 -0700 (PDT) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (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 D723812080F for ; Mon, 9 Sep 2019 08:09:22 -0700 (PDT) Received: by mail-ot1-f48.google.com with SMTP id g19so12720821otg.13 for ; Mon, 09 Sep 2019 08:09:22 -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=hDsgN1pMOC8iGIY8ACA6zazzTyZTiqTVEZQW8C0atJU=; b=BvH7DuQqDjeCFHSCbusnXid8xfYKy+qihUtDhksbP9RD8WNd71ltkydWaqfrpYjYur F7fJJ96gY4PRSyQJLmCVeEebXwvCfVwu1hmzGkqRE9D3Wxci0SvZ08mGgFKBXlH0TpDK BeLQ/df3DhFZkS4y0bVh74155H7M2LSlKqZ/U72QuMn8Hrc2awiH3VWql3j3tInPlqPT dPhW2mMC91amEq7uvbd92pHHhQPmvUsBHKZH+dBFgJWpyc6V2xKQflS/WZV1xoXAomc0 5GJU4d1K4eyKXL93gkRcdTd7s9GS3N87Y0h/7e44or09SGdiJlpgP9Mk9iGRw30VX4Mn kS7w== X-Gm-Message-State: APjAAAXxCpt9+JCGhlf8zdGKUyLZIu/nORb9dKz6wbJm8GiTQtSFyaic 1Anj1khirbyQfHoila6nqCkzduHT6i7Lb4Lm3I4= X-Google-Smtp-Source: APXvYqzB6ZFuw8kDzuuWh4Asjv7etnMmGw6Cfj3c+CFRNnOoUpjUI/Bcy7JUxXbKSquWhja0iyz00dneS/Ry8Z9SJZ0= X-Received: by 2002:a9d:4786:: with SMTP id b6mr15242685otf.112.1568041762103; Mon, 09 Sep 2019 08:09:22 -0700 (PDT) MIME-Version: 1.0 References: <6241.1567487279@localhost> <14973.1567579627@dooku.sandelman.ca> <28565.1567943136@dooku.sandelman.ca> In-Reply-To: <28565.1567943136@dooku.sandelman.ca> From: Phillip Hallam-Baker Date: Mon, 9 Sep 2019 11:09:10 -0400 Message-ID: To: Michael Richardson Cc: mathmesh@ietf.org, cfrg@irtf.org Content-Type: multipart/alternative; boundary="0000000000003928680592202c94" Archived-At: Subject: Re: [Mathmesh] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 15:09:24 -0000 --0000000000003928680592202c94 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 8, 2019 at 7:45 AM Michael Richardson wrote: > > I understand now. The master escrow key can be used to escrow both > asymmetric > private keys, but also to escrow session-level keys used for specific > purposes (such as the disk encryption example) > Yes, sorry for the confusion. I am trying to unpack this all and make two video presentations describing first what the Mesh is trying to do and second the components used to do it. The three big problems I see in Internet security are 1) Managing and credentialing the users keys across their many devices. 2) Managing and accepting contact information including public keys of other users and services 3) Securing data at rest. The mechanism required to address any one of these by itself is only slightly less than the mechanism required to solve all three --0000000000003928680592202c94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 8, 2019 at 7:45 AM Michael Richardson &= lt;mcr+ietf@sandelman.ca>= wrote:

I understand now. The master escrow key can be used to escrow both asymmetr= ic
private keys, but also to escrow session-level keys used for specific
purposes (such as the disk encryption example)

Yes, sorry f= or the confusion. I am trying to unpack this all and make two video present= ations describing first what the Mesh is trying to do and second the compon= ents used to do it.

The t= hree big problems I see in Internet security are
1) Managing and credentialing the users k= eys across their many devices.
2) Managing and accepting contact information including pub= lic keys of other users and services
3) Securing data at rest.

The mechanism required to address any one of these b= y itself is only slightly less than the mechanism required to solve all thr= ee=C2=A0
--0000000000003928680592202c94-- From nobody Mon Sep 9 09:38:50 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4C412080E for ; Mon, 9 Sep 2019 09:38:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 BAmEl2BxiE6x for ; Mon, 9 Sep 2019 09:38:35 -0700 (PDT) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 BF58B120853 for ; Mon, 9 Sep 2019 09:38:27 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A66001A2631; Mon, 9 Sep 2019 16:38:26 +0000 (UTC) Received: from pdx1-sub0-mail-a12.g.dreamhost.com (100-96-6-79.trex.outbound.svc.cluster.local [100.96.6.79]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7FC111A27B4; Mon, 9 Sep 2019 16:38:21 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a12.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Mon, 09 Sep 2019 16:38:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Dime-Quick: 03b5db5d2d24c192_1568047102028_2740679145 X-MC-Loop-Signature: 1568047102028:4210485620 X-MC-Ingress-Time: 1568047102028 Received: from pdx1-sub0-mail-a12.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTP id 845F88009E; Mon, 9 Sep 2019 09:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3AQTVD0v2j3k6E y3WBHa467iTzA=; b=dAnSvsgSosUhIw3aUnt1QOYfpv9oWzz6puZljspdM+8pej XcEuD7G6dnlZloYa65CWUpfXgPlZhur3ldzn+fXEfcODZWoHMdwBE9h8cUwoUlnM GU7r/FW25K7N4SLkpgfzw0MUhaVLVYDjcEabsWsc7RoYd0xz+eVRVFVyYYiMI= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 6E7EA80064; Mon, 9 Sep 2019 09:38:17 -0700 (PDT) Date: Mon, 9 Sep 2019 11:38:14 -0500 X-DH-BACKEND: pdx1-sub0-mail-a12 From: Nico Williams To: Phillip Hallam-Baker Cc: Michael Richardson , mathmesh@ietf.org, cfrg@irtf.org Message-ID: <20190909163813.GG7920@localhost> References: <6241.1567487279@localhost> <14973.1567579627@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudekiedguddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Mathmesh] [Cfrg] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 16:38:42 -0000 On Thu, Sep 05, 2019 at 10:26:22PM -0400, Phillip Hallam-Baker wrote: > On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson > wrote: > > Nico Williams wrote: > > > I don't see why in the first case you'd need a separate > > > service to store the private keys encrypted in the master > > > secret. All the entities that hold secret shares can also > > > hold copies of the encrypted record along with the secret > > > shares. > > > > This allows the secrets to split and sent to appropriate entities > > once at the beginning of the process, and they never need to be > > updated again. Alice can generate as many keys (and as frequently) > > as she wishes, interacting only with the escrow service. Assuming > > that I understand correctly. If you use a master secret to to generate all the others, indeed. The first scheme, however, requires storing updated encrypted secrets payloads. That's the "service" that we'd asked about, but I assumed the services that store secret shares would also store those payloads. > > > However, you might find it difficult to generate key pairs > > > from a master secret, especially if you ever need to generate > > > keys on a hardware token. If you won't have that requirement, > > > and if you're willing to have that as an anti-requirement, > > > then the second scheme is simpler, indeed, and the entities > > > that store key shares will need to store smaller records. > > > > You are saying: If you use a hardware token, then you need the escrow > > service. > > Isn't it the case that some hardware tokens have no mechanism to get the > > private key out? I guess they are SOL regardless of scheme. Yes, though I expect wrapped key export to be generally available, still: > I agree. If someone is using a hardware token, the hardware token needs to > manage the escrow mechanism itself (e.g. like the way Luna cards do). But > it will in any case need a way to import a private master key generated > elsewhere. not supporting such tokens is a reasonable thing to do. > > Couldn't we generate per-key escrow keys from the master key using > > the same KDF mechanism? Doesn't that get us the best of both worlds, > > with the confusion as to how the different That enlarges the amount of secret share storage needed, which gets us back to Phillip's desire to avoid that. A nice feature of this scheme is that there's a fixed number of fixed-sized keyshares generated early on and this need never change unless you want to re-key everything. Speaking of which, how does master secret change work? > Hmm... that might be the way to do it. The only problem is that then you > need access to the offline master to be able to generate application key > sets and the idea of the offline master is that you should only need to > ever use it when changing your administration device. Nico -- From nobody Mon Sep 9 20:03:04 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28AA120020 for ; Mon, 9 Sep 2019 20:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 bwP_b9kx7c_c for ; Mon, 9 Sep 2019 20:02:53 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 5219F120059 for ; Mon, 9 Sep 2019 20:02:53 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id b2so16003453otq.10 for ; Mon, 09 Sep 2019 20:02:53 -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=PjtShIVawsm3/X681dfzQwcrSaHfn/SLTJMS2gJlEOY=; b=OsAuSSnBknKGGEElBFTmQHVPYn7YzzihtKODh6nP7Xu251q6W8i0Zul+22BJvO7Ju4 6CwTfNnOmIIlTXY7UHFFAGH6iIIdKRS4qcr8amkystlUaPJ7U8NfhNsxD80i6IiNyADP tV8Wa4+lz9B9s0LCj8SPjBPWDvRCyi8z2DAEGBB1TLXliAFEhsk5OjpqoOe+yYEO2Zj0 4ikdieHn5NIuPaM3hMir7RQCvSjz8t3hdOH36TlQVpv7PDqmh/DaycM8pTVGja1bY2jZ z/JVOMhwbQouBIWiACYNRUD/ASoY3jG2HyhkyaYFNpX+HvIaKC8FoVcdCpNonnH/9nb9 l8Yw== X-Gm-Message-State: APjAAAUtFkJEaxMnIAIAhoHuU7PTeo7vKVa2eJOlbHO7iB28xhtOFfJE yL20p6cmcVDEFUiI5rGZYApUF8EQ1Q14+/k29ac3Kw== X-Google-Smtp-Source: APXvYqzz2YzDOHL3JfUNR6udaw3uA6SVZP8+kTgI2XnonpdnSH25va7p86LBFFCLQymiGFA/MElP8Ei4jwhxbBfnwTk= X-Received: by 2002:a9d:4786:: with SMTP id b6mr18179331otf.112.1568084572536; Mon, 09 Sep 2019 20:02:52 -0700 (PDT) MIME-Version: 1.0 References: <6241.1567487279@localhost> <14973.1567579627@dooku.sandelman.ca> <20190909163813.GG7920@localhost> In-Reply-To: <20190909163813.GG7920@localhost> From: Phillip Hallam-Baker Date: Mon, 9 Sep 2019 23:02:41 -0400 Message-ID: To: Nico Williams Cc: Michael Richardson , mathmesh@ietf.org, cfrg@irtf.org Content-Type: multipart/alternative; boundary="000000000000ec837205922a2305" Archived-At: Subject: Re: [Mathmesh] [Cfrg] A different approach to key escrow X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 03:02:56 -0000 --000000000000ec837205922a2305 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 9, 2019 at 12:38 PM Nico Williams wrote: > > Speaking of which, how does master secret change work? > That might not be so critical with the changes I made to the way accounts work. The master secret for the Mesh is only used in the management of the user's Mesh devices. It is no longer something that is exposed to other people. Only the account keys are exposed to other users. What we probably need to do is to go through the scenarios that would require re-keying a personal Mesh. The way that would have least impact on other systems would be to simply create a parallel Mesh and then create an assertion 'the person who used to have fingerprint X now has fingerprint Y'. And then various parties would have to decide the extent to which they trust that assertion. --000000000000ec837205922a2305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 9, 2019 at 12:38 PM Nico Williams <nico@cryptonector.com> wrote:

Speaking of which, how does master secret change work?

That migh= t not be so critical with the changes I made to the way accounts work.

The master secret for the Mes= h is only used in the management of the user's Mesh devices. It is no l= onger something that is exposed to other people. Only the account keys are = exposed to other users.

What we probably need to do is to go through the scenarios that would re= quire re-keying a personal Mesh.=C2=A0

The way that would have least impact on other systems would b= e to simply create a parallel Mesh and then create an assertion 'the pe= rson who used to have fingerprint X now has fingerprint Y'. And then va= rious parties would have to decide the extent to which they trust that asse= rtion.
--000000000000ec837205922a2305-- From nobody Thu Sep 19 08:26:26 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2F012002E for ; Thu, 19 Sep 2019 08:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, 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 G-Z4cjA0zqfj for ; Thu, 19 Sep 2019 08:26:21 -0700 (PDT) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (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 A60D112000F for ; Thu, 19 Sep 2019 08:26:21 -0700 (PDT) Received: by mail-oi1-f173.google.com with SMTP id w17so3039752oiw.8 for ; Thu, 19 Sep 2019 08:26:21 -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=7IaLxVSWbYYPPKbed93cvZldSNGsdwMECo84KH3aFd8=; b=AokuTeRTxp0EtfYG+SKn/Pff4bwesPNDhUbt9qdkFQGSOfcMTxs+VC4m+VRqj980EW HzOa9vsS4/XUfLW0K45ST6YXcZVO0rm1YhpQXQPUMbzyNucdAKcWiQkWMTzs46ygFZfp nf0dhrbq2x2+vXWbPT2cwEQNL9j0vbF8mO/bgTAzV0uyKkKIU61lS0YJSK034GWElcxo y1cwjrXxtIgyyLV2WhwpNCHOxKy/S36yWAzbLNCJ2MSpYA2qQUTA4lp1uXEeMHFPx7/L hEdQD7gTqbZSJ0KGC6Ow2is2ulLz0Q+kQoQX5MlV1W/eFOF9S+JGBL5RmTnUlAVd+tx1 8jEg== X-Gm-Message-State: APjAAAUipYvIBTpk4cG4o4eP67HAWAru6Uln+hRfbVcF5wOMgnaEC4BS Wsr56jvC1Ygr67Lr/vxaUqXkAkNUqmoiBjcq3WfKYMV0 X-Google-Smtp-Source: APXvYqzMG9tg/w7BjLJEr3p9XoPmEWwzKCzzC/zC9bxfClpxlZNBLxtHobb1VgZFwRqRJoMva4jgMFLRTcxES1DHwQs= X-Received: by 2002:aca:c458:: with SMTP id u85mr2785300oif.100.1568906780675; Thu, 19 Sep 2019 08:26:20 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Thu, 19 Sep 2019 11:26:09 -0400 Message-ID: To: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="0000000000005913e70592e9936d" Archived-At: Subject: [Mathmesh] How much data should Mesh Services see? X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 15:26:25 -0000 --0000000000005913e70592e9936d Content-Type: text/plain; charset="UTF-8" I am almost done getting the 3.0 reference code to run. This was a very substantial rewrite as it meant using the features I intended to build on top of the Mesh to secure the Mesh itself. At the moment there are three basis constructs *Mesh*: User Alice has exactly one Mesh to which she connects all her devices. *Account*: Alice can create as many Mesh Accounts as she likes and they are each insulated from every other account. A device may be connected to multiple accounts. *Service*: A minimally trusted Internet service that provides a point of contact through which devices connected to a Mesh Account may be synchronized. It is not necessary for Alice to create multiple Meshes to protect her privacy because it is a purely personal resource that is only used for the management of devices and accounts. A Mesh account may be connected to multiple services but only one of the services is authoritative. The user may change their service at any time. I have not implemented a transition protocol but since every Mesh contact exchange is bound to the account UDF fingerprint, we can easily effect a change of service by simply dropping a signed assertion into some sort of public log. "MeshAccount" : { "ServiceIDs" : ["alice@example.com", "alice@example.net "], "KeyEncryption": "MD67-UDAY-6JTI-BVTV-ZQBE-S2L5-HXCX" } MDXC-UHN2-UXXU-3MAD-QHPR-3VMA-WOXA Where MDXC-- is a key attesting to the account profile... OK so the idea of the service is that it just holds a sequence of DARE catalogs which are just lists of envelopes with a header, encrypted blob of data and a trailer. The problem lies in the fact that the service needs to know some of the contents of some of the catalogs. Specifically: Device catalog - Needs to know if a ConnectionDevice has been updated or revoked. Needs to be able to retrieve the device entry by an index known before the device is connected. Contacts catalog - Needs to be able to determine that an inbound Mesh Message is sent by a party authorized by the recipient. Need to be able to determine that an outbound message sent by the user is not likely to be abusive. Filtering inbound messages is relatively straightforward as we can easily require the message envelope to carry whatever information we like. We could even require it to contain a token of the form 'Alice is allowed to speak to Bob', i.e. a capability. I think it more likely however that we would want to enable anyone to communicate with anyone else without requiring every possible link be represented as a capability. Not least because I don't think Bob wants Alice to know precisely what those capabilities are. So I think the wrapper of a Mesh Message from Bob to Alice is going to be limited to a signature by Alice's device and an authentication chain plus the strong address of Bob, i.e. the service address plus the mesh fingerprint of the account. Which means that the contacts directory is going to need to include some unencrypted information that allows it to 1) locate Bob's entry in the contact catalog using his strong address(es) as index and 2) determine if the strong address is authorized for the operation in question. I am aware that there is something of an efficiency issue here and it is probably not desirable for an Internet service to be constantly parsing structures as complex as a DARE Container every time a message is received. But this is fairly easy to address using a 'hot index' file which the service can compute from the container as an offline task. We can now perform a lookup in O(1+u) time where u is the number of updates written to the container since the index was calculated. The container file format even allows such an index to be written to the end of the container itself. --0000000000005913e70592e9936d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m almost done getting the 3.0 reference code to run. This was a very substa= ntial rewrite as it meant using the features I intended to build on top of = the Mesh to secure the Mesh itself.

At the moment there are three basis constructs

Mesh: User Alice has exactly one = Mesh to which she connects all her devices.

Account: Alice can create as many Mesh Accounts as she likes = and they are each insulated from every other account. A device may be conne= cted to multiple accounts.=C2=A0

Service: A minimally trusted Internet service that provi= des a point of contact through which devices connected=C2=A0to a Mesh Accou= nt may be synchronized.

I= t is not necessary for Alice to create multiple Meshes to protect her priva= cy because it is a purely personal resource that is only used for the manag= ement of devices and accounts.

A Mesh account may be connected to multiple services but only on= e of the services is authoritative. The user may change their service at an= y time. I have not implemented a transition protocol but since every Mesh c= ontact exchange is bound to the account UDF fingerprint, we can easily effe= ct a change of service by simply dropping a signed assertion into some sort= of public log.

"Mes= hAccount" : { "ServiceIDs" : ["alice@example.com",=C2=A0 "alice@example.net"],
"KeyEncrypti= on": "MD67-UDAY-6JTI-BVTV-ZQBE-S2L5-HXCX"
}
<Signed> MDXC-UHN2-UXXU-3MAD-QHPR-3V= MA-WOXA
Where=C2=A0 MDXC-- is a key attesting to the account profile...


OK so the idea of the service is that it just holds a sequ= ence of DARE catalogs which are just lists of envelopes with a header, encr= ypted blob of data and a trailer.

The problem lies in the fact that the service needs to know some= of the contents of some of the catalogs. Specifically:

Device catalog -=C2=A0
=C2=A0 =C2=A0 Needs to know if a Con= nectionDevice has been updated or revoked.
=C2=A0 =C2=A0 Needs to be able to retrieve the = device entry by an index known before the device is connected.

Contacts catalog -
=C2=A0 =C2=A0 Needs to be able to= determine that an inbound Mesh Message is sent by a party authorized by th= e recipient.
= =C2=A0 =C2=A0 Need to be able to determine that an outbound message sent by= the user is not likely to be abusive.

Filtering inbound messages is relatively straightforward as w= e can easily require the message envelope to carry whatever information we = like. We could even require it to contain a token of the form 'Alice is= allowed to speak to Bob', i.e. a capability. I think it more likely ho= wever that we would want to enable anyone to communicate with anyone else w= ithout requiring every possible link be represented as a capability. Not le= ast because I don't think Bob wants Alice to know precisely what those = capabilities are.

So I th= ink the wrapper of a Mesh Message from Bob to Alice is going to be limited = to a signature by Alice's device and an authentication chain plus the s= trong address of Bob, i.e. the service address plus the mesh fingerprint of= the account.
<= br>
Which means that the contacts directory is going to need to include so= me unencrypted information that allows it to 1) locate Bob's entry in t= he contact catalog using his strong address(es) as index and 2) determine i= f the strong address is authorized for the operation in question.


I am aware that there is something of an eff= iciency issue here and it is probably not desirable for an Internet service= to be constantly parsing structures as complex as a DARE Container every t= ime a message is received. But this is fairly easy to address using a '= hot index' file which the service can compute from the container as an = offline task. We can now perform a lookup in O(1+u) time where u is the num= ber of updates written to the container since the index was calculated. The= container file format even allows such an index to be written to the end o= f the container itself.
--0000000000005913e70592e9936d-- From nobody Thu Sep 19 09:42:42 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578C91201E3 for ; Thu, 19 Sep 2019 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, 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 nr66evm7uoF1 for ; Thu, 19 Sep 2019 09:42:38 -0700 (PDT) Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) (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 4BD6E120077 for ; Thu, 19 Sep 2019 09:42:38 -0700 (PDT) Received: by mail-oi1-f195.google.com with SMTP id k25so3230654oiw.13 for ; Thu, 19 Sep 2019 09:42:38 -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=0Z/KeT+oBrjcpUM5TvLkqwsuNEEBa0bQG4mttMJsHfk=; b=e1c0FC4S/MhH3jW/bE2NrbjJcOjPWLsy8JMMGpmrWWaPiMJ1HhMsWPAv1F4kFUjBQJ Hfo/kR+5/qN6bM44dGkx5TqRz7WVRME/zGaS5Z0Lbwt0kvYcHN12jkgVp+Lg8K4HTos6 Cd3htKTyt8pEy+O5HbKi4xS5+1Zu5GI2LBbkm1g3ByedUgrQJ2s02qbLzIY5zv7zV+9X OHHH38XjHy20iGPPuJRMhOVD4n6MaKDgmQDrdsDycwDzDu2j+IJ7RrTNlnzCZOzLO2Y1 r4f4PJMIKALldomq+W0S7Lwq/PBSdQfFmkLwMlDLFcQvYJrYuiG4DaLKgcs0x0aX47Pe qhKw== X-Gm-Message-State: APjAAAXZW5GpcEpJGAHd23fVZ1turjVmvQSI/GqDva/JDA8HJVKKzCN8 skVVpE/TRn1GsdpPHJbGAuIprWubNynYbe43siUQLyKa X-Google-Smtp-Source: APXvYqz5mUYv9DnjqkSWIGjRqnJtft1QnKg7Wk+zbz9/7XPNYNYZ+uwS6HHWtOR63wbLJan/cjlkXzy0LzakymU1+kU= X-Received: by 2002:aca:32d4:: with SMTP id y203mr2265088oiy.17.1568911357343; Thu, 19 Sep 2019 09:42:37 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Thu, 19 Sep 2019 12:42:27 -0400 Message-ID: To: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="000000000000237c2f0592eaa43e" Archived-At: Subject: [Mathmesh] What part(s) of the Mesh should we charter a WG to address X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 16:42:40 -0000 --000000000000237c2f0592eaa43e Content-Type: text/plain; charset="UTF-8" My objective with the Mesh is to address three problems I see as critical for addressing current Internet security concerns. * Management of private keys across devices and accounts. * Obtaining and verifying public keys for devices and accounts. * Securing data at rest To meet these needs, I have developed a technology platform that has three separable parts: * The UDF identifier infrastructure which encapsulates naming an addressing functionality, * The DARE envelope and sequence formats which applies JSON and JOSE to support PKCS#7/BlockChain/more * The Mesh infrastructure consisting of the Mesh Schema and Mesh Service. While it is in principle possible to separate the last two, I can't see that as having any point as they are designed to be interdependent. Similarly, DARE is built on UDF and the Mesh 3.0 is built on DARE so you can't do just the Mesh without UDF but the reverse is possible. So the question raised in Montreal was should we address one, two or all three? I am currently trying to complete the specifications for the Mesh part. By complete, I mean that the specifications should be implementable with no essential functionality missing with running reference code that does not show obvious gaps. Complete does not mean final. We can certainly make changes and that is the point of having a standards process. The point of getting to a complete stage is that it should no longer be necessary to make a change. We could decide it was all a bad idea, publish the document set as 'experimental' and walk away quietly. >From a research point of view, the primary novel contributions are as follows: * UDF identifiers provide 'Rails for cryptography'. Choosing a single identifier and applying it consistently greatly simplifies design. ** Strong Internet Names allow any Internet address containing a DNS component to be bound to a security policy that determines its interpretation. This mechanism may be used a means of representing the outcomes of a traditional CA based trust mechanism (e.g. PKIX/WebPKI) or as a direct trust mechanism. * DARE envelopes enable the use of threshold cryptography (i.e. splitting the decryption key) to enable data to be shared with dynamic groups of users of devices. ** A user who has acquired a new device can immediately enable decryption of end-to-end messages and data previously received while retaining the ability to remove the capability if the device is lost or stolen. ** Sharing of encrypted documents and data between groups of users enables the subset of DRM capabilities that are useful and may be implemented without relying on trustworthy hardware. * DARE Sequences support incremental authentication (aka BlockChain) and incremental encryption. ** DARE Catalogs provide a lightweight persistence mechanism well suited to small data objects which permit straightforward implementation with ACID properties. * The Mesh overcomes the challenges presented by private key generation and distribution in traditional PKI through use of threshold cryptography techniques in reverse. PHB --000000000000237c2f0592eaa43e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My = objective with the Mesh is to address three problems I see as critical for = addressing current Internet security concerns.

* Management of private keys across devices and accou= nts.
* Obtainin= g and verifying public keys for=20 devices and accounts.
* Securing dat= a at rest=C2=A0

To meet t= hese needs, I have=C2=A0developed a technology platform that has three sepa= rable parts:
* The UDF id= entifier infrastructure which encapsulates naming an addressing functionali= ty,
* The DARE = envelope and sequence formats which applies JSON and JOSE to support PKCS#7= /BlockChain/more=C2=A0
* The Mesh infrastructure consisting of the Mesh Schema and Mesh Se= rvice.

While it is in pri= nciple possible to separate the last two, I can't see that as having an= y point as they are designed to be interdependent. Similarly, DARE is built= on UDF and the Mesh 3.0 is built on DARE so you can't do just the Mesh= without UDF but the reverse is possible.

So the question raised in Montreal was should we address o= ne, two or all three?=C2=A0
I= am currently trying to complete the specifications for the Mesh part. By c= omplete, I mean that the specifications should be implementable with no ess= ential functionality missing with running reference code that does not show= obvious gaps.=C2=A0

Comp= lete does not mean final. We can certainly make changes and that is the poi= nt of having a standards process. The point of getting to a complete stage = is that it should no longer be necessary to make a change. We could decide = it was all a bad idea, publish the document set as 'experimental' a= nd walk away quietly.

Fro= m a research point of view, the primary novel contributions are as follows:=

* UDF identifiers provid= e 'Rails for cryptography'. Choosing a single identifier and applyi= ng it consistently greatly simplifies design.

** Strong Internet Names allow any Internet address co= ntaining a DNS component to be bound to a security policy that determines i= ts interpretation. This mechanism may be used a means of representing the o= utcomes of a traditional CA based trust mechanism (e.g. PKIX/WebPKI) or as = a direct trust mechanism.

* DARE envelopes enable the use of threshold cryptography (i.e. splitting = the decryption key) to enable data to be shared with dynamic groups of user= s of devices.=C2=A0

** A = user who has acquired a new device can immediately enable decryption of end= -to-end messages and data previously received while retaining the ability t= o remove the capability if the device is lost or stolen.

** Sharing of encrypted documents and data = between groups of users enables the subset of DRM capabilities that are use= ful and may be implemented without relying on trustworthy hardware.

* DARE Sequences support incre= mental authentication (aka BlockChain) and incremental encryption.

** DARE Catalogs provide a lightw= eight persistence mechanism well suited to small data objects which permit = straightforward implementation with ACID properties.

* The Mesh overcomes the=20 challenges presented by private key generation and distribution in traditio= nal PKI through use of threshold cryptography techniques in reverse.
<= div class=3D"gmail_default" style=3D"font-size:small">

PHB
--000000000000237c2f0592eaa43e-- From nobody Sat Sep 28 15:16:37 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C271200A3 for ; Sat, 28 Sep 2019 15:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, 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 gOEy5XB3Smtr for ; Sat, 28 Sep 2019 15:16:34 -0700 (PDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (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 8C06712009E for ; Sat, 28 Sep 2019 15:16:34 -0700 (PDT) Received: by mail-oi1-f193.google.com with SMTP id t84so8079346oih.10 for ; Sat, 28 Sep 2019 15:16:34 -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=SbFHBygOyZnElPR3q2z5T8Hh7ojemUGm6MIdDqxnN4s=; b=EwyGT+0BMyt4ax8aE6OtCXCzYQG+pYdjlqZGdwEPcIpCwXv+yixrlQaiaNktVYmKoH 84DYR/ORmz6Pf0+0e3cqu2P9b3hbapZw4c9y4CO+fdnGyflS80z0/9Mh7nxVm2JlOyA/ PHkJ2bFEr73Av2180gUygP8reNdVJmbppdMleJlXh3e7XFE3UDSq0uUET8G/e1G8PH7l pyQ7Rg8O/9sllfqPMYi4Di90XrOzllNc9/5LS0VMEHVNX/KhcCAMC4Xg046SfzSyjbEw PrlOLTCPUNl6RUYfnyg1DKY8pGE6S33fE+1oPVSICnxqofE/C8FlVKjyYWX+dsKaEozR EaBg== X-Gm-Message-State: APjAAAVUh+ZjgMBp13KT/fuIbloG85KJ8hso/Y87QWaEjanMrgrfiJ5y 77/agunaF6oG5IlaOz2xLIzpJCIG67kP0yKnBPEnIpWTGyA= X-Google-Smtp-Source: APXvYqwiJbtqHepinfYF3S0GoAnknR0rfzTWKokYY2gMyf/qf9adqmEG8R+Eyiq7ehyXk5dRsyiLVEZjEVL+U9/mWpY= X-Received: by 2002:aca:c458:: with SMTP id u85mr12793248oif.100.1569708993568; Sat, 28 Sep 2019 15:16:33 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Sat, 28 Sep 2019 18:16:23 -0400 Message-ID: To: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="000000000000f664080593a45a9a" Archived-At: Subject: [Mathmesh] Configure SSH with UDF key... X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 22:16:37 -0000 --000000000000f664080593a45a9a Content-Type: text/plain; charset="UTF-8" I am just writing a series of presentations on the Mesh to put out to podcast to explain the concepts and the technology. The Mesh presents four technologies that in combinations can solve a large number of difficult problems. UDF is the one Mesh technology that does not depend on any other and I keep finding new uses. And the latest of these is to configure SSH. The biggest hassle with SSH is how to install your private key on each of the devices that you want to use it from. In theory of course, you want to have an independent key for each device so that you are not completely hosed if you lose one of them or you are passing through an airport and someone demands you login to your laptop. But most people have one private key and they move it from one machine to another in email. Oh and 'most people' probably isn't most of the people here. It only takes one pinhead to bust a hole in your corporate defenses. So I have been looking at recovery mechanisms for Mesh profiles. And one very promising approach is to use a KDF and a strong password to generate them. KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_signature") KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_escrow") So the encryption and signature keys are generated from Z AR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA All we need to do now is to escrow ZAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ which we can do by Shamir Secret sharing. What if we could also do KDF ("ZAA5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN-AQQE", "ssh_client") Now we have a really quick way to reconstitute the authentication key on each of the user's devices. What I was thinking of for implementation is to define a new type code, probably 200 which gives an initial letter of Z. Then make the following two bytes a 16 bit registry code saying what the key is to be used for (Mesh, SSH, etc.) Comments? As with passwords, we might well need to help people follow their current workflow in a not quite so stupid fashion before we try to change it. --000000000000f664080593a45a9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m just writing a series of presentations on the Mesh to put out to podcast = to explain the concepts and the technology. The Mesh presents four technolo= gies that in combinations can solve a large number of difficult problems.

UDF is the one Mesh techno= logy that does not depend on any other and I keep finding new uses. And the= latest of these is to configure SSH.

The biggest hassle with SSH is how to install your private key= on each of the devices that you want to use it from. In theory of course, = you want to have an independent key for each device so that you are not com= pletely hosed if you lose one of them or you are passing through an airport= and someone demands you login to your laptop.

But most people have one private key and they move it= from one machine to another in email. Oh and 'most people' probabl= y isn't most=C2=A0of the people here. It only takes one pinhead to bust= a hole in your corporate defenses.


So I have been looking at recovery mechanisms for Mesh profiles. And one v= ery promising approach is to use a KDF and a strong password to generate th= em.

<= div class=3D"gmail_default" style=3D"font-size:small">KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_signature")
KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_escrow")=C2= =A0=C2=A0

<= /div>
So the encrypti= on and signature keys are generated from ZAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA

All we need to do now is to escrow ZAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ=C2= =A0which we can do by Shamir Secret sharing.

What if we could also do=C2=A0

KDF ("ZAA-AQQE", "ssh_client&q= uot;)=C2=A0 =C2=A0=C2=A0

Now we have a really quick way to reconstitute the authentication ke= y on each of the user's devices.=C2=A0

What I was thinking of for implementation is to define a = new type code, probably 200 which gives an initial letter of Z. Then make t= he following two bytes a 16 bit registry code saying what the key is to be = used for (Mesh, SSH, etc.)

Comments?
As with passw= ords, we might well need to help people follow their current workflow in a = not quite so stupid fashion before we try to change it.

--000000000000f664080593a45a9a-- From nobody Sun Sep 29 15:37:43 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BB2120073 for ; Sun, 29 Sep 2019 15:37:42 -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 AUegw2lHaWb4 for ; Sun, 29 Sep 2019 15:37:41 -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 C2904120025 for ; Sun, 29 Sep 2019 15:37:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 556F03897D; Sun, 29 Sep 2019 18:35:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BC410373; Sun, 29 Sep 2019 18:37:38 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: mathmesh@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Mathmesh] Configure SSH with UDF key... X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2019 22:37:42 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > The biggest hassle with SSH is how to install your private key on each of > the devices that you want to use it from. In theory of course, you want to > have an independent key for each device so that you are not completely > hosed if you lose one of them or you are passing through an airport and > someone demands you login to your laptop. > But most people have one private key and they move it from one machine to > another in email. Oh and 'most people' probably isn't most of the people > here. It only takes one pinhead to bust a hole in your corporate defenses. So you have a fairly reasonable use case. I also observe the 90% of people don't use ssh private keys or understand how to use ssh-agent, or understand that they can keep their private key in some central place and use ssh -A/ssh-keyadd to gain access to it for the current session. This turns SSH into a far more KRB5-like ticket system with limited lifetimes, and so the private key on the laptop only lets one get to the "home cloud"(owncloud) machine that holds the master key. But MMM should let us do other things with SSH keys. Since 1996, I've wanted to do signed statements about logins, rather than hacking ~/.ssh/authorized_keys files. > So I have been looking at recovery mechanisms for Mesh profiles. And one > very promising approach is to use a KDF and a strong password to generate > them. > KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_signature") > KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_escrow") > So the encryption and signature keys are generated from Z > AR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA > All we need to do now is to escrow ZAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ which > we can do by Shamir Secret sharing. > What if we could also do > KDF ("ZAA5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN-AQQE", "ssh_client") > Now we have a really quick way to reconstitute the authentication key on > each of the user's devices. If I understand you correctly, you are trying to find a way to generate the private key(s) in a deterministic way from a master secret which can be split? This way, the user doesn't use email to distribute their private key, but rather can just recover it each time they might need it after a dangerous situation. (Such as going through a border control, etc.) > What I was thinking of for implementation is to define a new type code, > probably 200 which gives an initial letter of Z. Then make the following > two bytes a 16 bit registry code saying what the key is to be used for > (Mesh, SSH, etc.) Seems like a useful thing. > As with passwords, we might well need to help people follow their current > workflow in a not quite so stupid fashion before we try to change it. An illustrative video would help. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2RMjIACgkQgItw+93Q 3WURsAgAlTIQsSpbSpfklwsj2RPPV+7LOA1XnK0Zz3WZJnnm3cbiIHtcz+u1blMv XnAKAzwCako/nXaflGLduj0yH/zUV8XauqQgd9Y4G4hxsboHk0PKKCutMKJVLrHB ypTuG9ZIbSOIHyplAF7Bvg2DDWRGgFQm8IpiXrsBxyJgI7m1jEDoiXwVUXgaI4gm V25UpKijMTyTEyeWQsW+xwJ/FcY6eDMwMhuQnXFqBEjoJ/ZvSOvdwQGfAa3PSHl8 gUUjZvyqQbVcHhu0Rxf6hCUkCIvkN4ASvk0zy8HrUCy7Rp6LFV3qcxV6OxZyPgBr dwDUPm3AnA7Bx2b8yS6jOsQIkjYFUw== =yoRr -----END PGP SIGNATURE----- --=-=-=--