[MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336)
Richard Barnes <rlb@ipv.sx> Wed, 17 June 2020 22:54 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D4F3A090A for <mls@ietfa.amsl.com>; Wed, 17 Jun 2020 15:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 ifqzWpi61tGm for <mls@ietfa.amsl.com>; Wed, 17 Jun 2020 15:54:34 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 6581D3A08F8 for <mls@ietf.org>; Wed, 17 Jun 2020 15:54:33 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id g28so3796885qkl.0 for <mls@ietf.org>; Wed, 17 Jun 2020 15:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=07ef65sj+xDFa5dV7JsMRVhGWU2wzenulYK6oz7ygRE=; b=p3Bi6RGzBcfXHxL/1ltP6qlM6UrdZTHh9YpNlh72UyZY4LgHcw2WbG4nkt+REHVOc6 qlOCF+DtVKkxktGIqS8gYiZKCJT+HztjUFO+89Guxh+e/Utae1PbNIIRuL4u7AQxNc+0 k5IqqEZNRjedI75cD/YYu4DvzVA/yeN5g+G/ELtUJKrGyG5sdN8kOzSZmw1lXKM0oGbL kpR1tIb6ZjLZ5fxIjBqMPuK3xa+7woE63Piyvxt5eE4o/oumNJbAPw39kVrh9F8bFLgb Xkl5GFECb49lnNYYk3py0vtgUSHTj06k42TcRgAcMUK4I0DN412RUvQaSsfi4mFie94H t3Fg==
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=07ef65sj+xDFa5dV7JsMRVhGWU2wzenulYK6oz7ygRE=; b=hCdrydvpLifJV/xF7BTPFri+tckJHFOy1uPhjZbfMfyGwKOi86oC7JNCoZAFyrevqA DHCfxgfL3CmhaKFoTG+P0wnYREgvvMaA3wQHr3kgC6TlThcmxPNTfD9gDFfhqBdiIUU1 h7tHuqIM3lLm8jsVUFHW9KsvE0JFmn6tLWhvcL/V7b3tKcVXWUZ8B64fI3HvzcgPr4F5 HIN6R512YJcMGd3Qa53fgXxh88F4YcrP8gpwtRYemR9IZbhkKPIAm2JiCoNgoKkFADHF NPRuTjg7+qEquGlU0IL0TLiZXFbGnBefyHfhn6zX645AVWWNYXNGELn+kxuKhydO746q zk/Q==
X-Gm-Message-State: AOAM530bfC2TldmB8KeAf0HJ7QXiK4CQ/Znc35/deNb8QmjfqwGmpmJN IKAX2BcyNXv/RbpX629EpxMVg6Gp271G8SCueqZJzdeiRH/nsQ==
X-Google-Smtp-Source: ABdhPJyzs3AS4prYBGTK6N5PchR1Ibu88OKwbkJleD23pTXn3iwtjCYesnACt12gBVlz925j05tWyQb571mfRxt17Tw=
X-Received: by 2002:a37:4a85:: with SMTP id x127mr932420qka.159.1592434472444; Wed, 17 Jun 2020 15:54:32 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 17 Jun 2020 18:54:16 -0400
Message-ID: <CAL02cgTxm+OMRHvXk_34MAxk5bgit_kpkW81wigGPZriKFtebw@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000ef7b805a84f8bf0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE>
Subject: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336)
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 22:54:36 -0000
Hey all, Sorry for the late review on this PR, I have finally gotten a chance to really dig into it, and ... I have some concerns. My current thinking is consistent with my earlier comments that the general thrust of this PR is OK. But I think the actual approach needs to change a fair bit. As its title implies, this PR is trying to do several things at once, which seem to me to be fairly separable: 0. Update the key schedule so that PSKs are injected at the right point and multiple PSKs are supported 1. Signal that a PSK should get injected into a given epoch 2. Request injection of PSK at join / in Welcome 3. Re-initialize the group with different parameters 4. Re-sync group members that have lost state For the most part, I think these are worthwhile goals, but they should be accomplished in different ways than the PR proposes. Detailed thoughts by objective: # 0. Update the key schedule so that PSKs are injected at the right point and multiple PSKs are supported This part of the PR is fine, but I think is ultimately done a bit more elegantly with the n-PRF stuff in #337. # 1. Signal that a PSK should get injected into a given epoch # 2. Request injection of PSK at join / in Welcome (These go together) The PR proposes (heh) an EPSK proposal or an Add proposal, but then requires that only one EPSK be used. I actually don't the proposal for including PSKs in Adds actually works. The joiner would have to know all of them plus the EPSK, and there's not even any syntax in the PR to tell the joiner which ones to include. I would propose that instead we add an extensions field to the Commit message, then add a Commit extension that specifies the PSK ID for the PSK to be added. That extension can then also go in the Welcome message corresponding to the commit, so that joiners know to add the PSK. This change actually doesn't make a difference in terms of what ends up in the transcript -- either way, only the PSK ID selected by the committer goes in the transcript. It seems better not to deliberately have proposals floating around that never get included in the transcript. # 3. Re-initialize the group with different parameters The PR proposes another proposal type for reinitialization, but it's really under-specified what you do to re-init. For example, what goes in the ratchet tree? Clearly you need a brand new tree, since the one you have might be tied to the wrong ciphersuite. What you really need is something like a Welcome message. And that's how I think we should actually arrange things. Instead of having the parent group do something to spawn, have the initiator of the child send a Welcome that has a pointer back to the parent. So we have another Welcome extension (`parent_group`, say) that has a pointer to the parent group by group ID and epoch, and instructs the joiner to take a secret from that group/epoch's key schedule and add it into the new group's key schedule. # 4. Re-sync group members that have lost state We should not do these. At the January interim, we decided not to drop the resync issue (#93) given that there were some subtleties depending on exactly what state had been lost, and that it could be cleanly done in a separate spec. # Conclusions Given the above, I would propose we break this into separate issues to be closed with individual, smaller PRs. Assuming that (0) will get addressed by the n-PRF PR, that leaves us with: #XXX Add Extensions to the Commit message #XXX Signal use of external PSKs in Commit/Welcome (=> extension to Commit/Welcome messages) #XXX Allow Welcome to signal the inclusion of information from a prior group (=> Welcome extension) Happy to write those up, and contribute to PRs. Sorry again for the slow progress here. --Richard
- [MLS] PSK Injection, Group recovery, Re-Init, Sub… Richard Barnes
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Hale, Britta (CIV)
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Konrad Kohbrok
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Konrad Kohbrok
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Richard Barnes
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Richard Barnes
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Richard Barnes
- Re: [MLS] PSK Injection, Group recovery, Re-Init,… Konrad Kohbrok