Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336)

Richard Barnes <rlb@ipv.sx> Tue, 28 July 2020 17:38 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 C1F6C3A0A4D for <mls@ietfa.amsl.com>; Tue, 28 Jul 2020 10:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 Uj2lT2UcLEwe for <mls@ietfa.amsl.com>; Tue, 28 Jul 2020 10:38:08 -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 5EC6A3A0A49 for <mls@ietf.org>; Tue, 28 Jul 2020 10:38:08 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id u64so19423892qka.12 for <mls@ietf.org>; Tue, 28 Jul 2020 10:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pqHrF+BHJKIZHApcANcz/+lZysj8KOyJFwbPCqDySJA=; b=tjNycLOBHv2K9BFQufM0uqdBKEzfEV/j+28MrspCWTEoC+eCpBj1zvSdZbWzWSM/38 6UrjeIzgwukggLOct+iw2vmlIpX8RRCtfckf53wDTZMR+1nKm682H7OwCO/XK1fN1vPo XpkiB2uNv+jP9UpdO2OIdtvbexK4jQuxZV7mX9T2mUnOU30qMKqfi8KEMH2eEnYE8QyM fm2ljZK9U9W/elvZapOmhMS0B5JgkO5quiJ6QA9wuYFf5ZOZYa4/OuJoU7XR4nP60ubQ y17N+SIwX3I8Eld9gjtxTrn7AFBuuNS73w1j+j295w1MGx3VMvsG43W3FmhCHkRzNAKF ZBpw==
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=pqHrF+BHJKIZHApcANcz/+lZysj8KOyJFwbPCqDySJA=; b=YVI4Mda4iXAdLCEzScZAyyDfekhhFDG+3Vrx/vTnDtoQ4lMUxALkXqDnH3ACHwrpPT CaN5H3B1Ii13PXNouLGOxjwyzf3Zrej3+Ag0uDn2KIo+IkykTfxzpXFR3rN+S6NMc9qQ ZHe41jh9MPz16jO6hMWcwe/aQfjgvS/fQ8+T10qPtu4nWoTbhYj5wp5wWwduwS4p41Dm 3SZCgHeGt9Bvqdb1y0HJ+u/JqzPi68HK4tasekfj705T6F5XswmrpAyrjFv9s+JWTpGT gUVzKS5DhhsuGLKoAM0zZzJmFwqDWLn/RLToYayRRwnFZVZb1jjp5iz33ZpIANBqA5/8 2rKg==
X-Gm-Message-State: AOAM5335I2vz7T5w6cgFeVNnsysKTNABU2nbtRWhuJ35cXBfl32W7ImQ XMVMRo8jORGgUinsashvCkacDH3G7qnHtO2I+ubdnHqZw6zarQ==
X-Google-Smtp-Source: ABdhPJxgfBBDpkClzcRyESUCT/0owdx/8Q8UOrBZ9Gygv0w5v244vETp2D1VDh5rDijGD/5ZUb9h8+F47WiBjmNJlsM=
X-Received: by 2002:a37:5cc5:: with SMTP id q188mr14022717qkb.347.1595957887049; Tue, 28 Jul 2020 10:38:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgTxm+OMRHvXk_34MAxk5bgit_kpkW81wigGPZriKFtebw@mail.gmail.com> <BFD5B4F7-3617-41AD-811F-C6C49A803983@nps.edu> <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> <d3c4ca24-504b-f167-f733-bf8ae5bb1d00@datashrine.de> <CAL02cgS_xVANTvYn+pHq69CZUi4nJPgnayRp6OORXmt+k2Kn0w@mail.gmail.com>
In-Reply-To: <CAL02cgS_xVANTvYn+pHq69CZUi4nJPgnayRp6OORXmt+k2Kn0w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 28 Jul 2020 13:37:37 -0400
Message-ID: <CAL02cgRMtZgc6vfcSjMzWQ1wguXB-764BaRn6X8qBa=gB9iLdA@mail.gmail.com>
To: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ef3da105ab83e6fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/XKgskDGUFkxg9vmatGrb1rzJfg4>
Subject: Re: [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: Tue, 28 Jul 2020 17:38:13 -0000

Actually, noticed one thing that isn't accounted for in that list:

Derive an "authentication secret"
https://github.com/mlswg/mls-protocol/issues/374

A fun question for the list is what we should call these things, since
there are a bunch of terms in the prior art, for example:

- Authentication secret [PR#336]
- Short authentication string [ZRTP, TLS]
- Safety numbers [Signal]
- Security codes [Zoom security whitepaper]

Personally, I'm inclined against things that include "authentication",
since the thing we're defining here is a backstop to the primary
Authentication Service.  Among the above list, "Security Codes" might be my
favorite.  Otherwise, maybe something like "group state verifier"?


On Fri, Jul 24, 2020 at 6:39 PM Richard Barnes <rlb@ipv.sx> wrote:

> Picking this thread back up:
>
> I tried to encapsulate my approach to the issues here in a few GitHub
> issues and one PR:
>
> Reorder key schedule inputs
> https://github.com/mlswg/mls-protocol/issues/362
>
> Add extensions to the Commit message
> https://github.com/mlswg/mls-protocol/issues/366
>
> Negotiate PSKs
> https://github.com/mlswg/mls-protocol/issues/367
>
> Proof of prior membership in the group / Resumption
> https://github.com/mlswg/mls-protocol/issues/368
>
> Konrad / Britta - I think those combine to cover the cases you were trying
> to address in #366, but tease the issues apart a bit more clearly.  Does
> that make sense to you?  What have I missed here?  If this general plan
> looks good, I think we can get the details arranged and agreed fairly
> quickly, as these are each pretty self-contained pieces of work.
>
> Thanks,
> --Richard
>
> On Tue, Jul 14, 2020 at 12:37 PM Konrad Kohbrok <
> konrad.kohbrok@datashrine.de> wrote:
>
>> We just briefly touched upon this PR in the virtual interim on July 14th
>> and I
>> think we agreed that the discussion should be continued on the
>> mailinglist and
>> then tied up at the IETF 108 meeting.
>>
>> I think continuing the discussion on the mailinglist is a good idea,
>> however,
>> neither Britta nor myself are going to be present at the IETF 108
>> meeting. Maybe
>> we can push the discussion to the next virtual interim meeting instead?
>>
>> Cheers,
>> Konrad
>>
>>
>> On 18.06.20 16:29, Konrad Kohbrok wrote:
>> > Hi,
>> >
>> > Just a small addition to Britta's response:
>> >
>> > For #3: We already mandate that the parent group must not be used
>> anymore if a
>> > Re-Init proposal is included in a commit in lines 2341-2342 of the PR
>> (although
>> > "to send messages" might as well be removed). We could also get rid of
>> the
>> > proposal and simply have the intent to re-initialize be implicit in
>> sending a
>> > Welcome message with a corresponding PSK Id. The idea behind the
>> Proposal was to
>> > make that intent explicit such that the intent, as well as the target
>> > ciphersuite and MLS version are all entered into the transcript and
>> thus agreed
>> > upon. Even though the group is terminated after the proposal is
>> received, this
>> > agreement can be verified by using the authentication key technique
>> that Britta
>> > proposed, i.e. each party can check that their authentication key
>> corresponds to
>> > the one the committer uploaded.
>> >
>> > I'm also ok with splitting it into multiple individual PRs if that
>> makes it
>> > easier to review and discuss.
>> >
>> > Cheers,
>> > Konrad
>> >
>> >
>> > On 18.06.20 04:07, Hale, Britta (CIV) wrote:
>> >> Hi Richard,
>> >>
>> >>
>> >>
>> >> Thank you for the comments and careful read of the PR.
>> >>
>> >>
>> >>
>> >> For #1/#2: I am amicable to the idea of adding an extension field to
>> the commit
>> >> message. As a general comment, we may want to consider if there are
>> other types
>> >> of commit extensions worth adding or, alternatively, how the field may
>> be abused
>> >> (e.g. treated as AD by an application).
>> >>
>> >> It terms of objection to the current form though, your argument is not
>> clear.
>> >> PSKIds should uniquely identify PSKs, and a joiner (or anyone) should
>> be able to
>> >> identify the correct PSK given the PSKId, if they are in possession of
>> it. PSKs
>> >> must only be used in an Add if the joiner is a past group member (line
>> 2055) and
>> >> therefore has the correct PSKId/group_id/psk_epoch, although this is
>> nullified
>> >> if we make the change discussed in #4. In that case, the issue for
>> Adds goes away.
>> >>
>> >> The PR already allows for a PSK in the Welcome message.
>> >>
>> >>
>> >>
>> >> For #3: Currently, in the PR, there is a recovery_secret derived
>> per-epoch. When
>> >> a member wants to re-initialize, they issue a Re-Init proposal. They
>> may then
>> >> re-initialize the group by sending a Welcome message (see lines 1923,
>> 1948, and
>> >> 2349) with the PSKId for the parent group/epoch and a psktype that
>> indicates
>> >> that they are re-initializing the group with the stated PSKId. So this
>> seems to
>> >> already be what you describe below as “have the initiator of the child
>> send a
>> >> Welcome that has a pointer back to the parent”. However, you are right
>> that more
>> >> detail can be added; in particular a requirement should be added to
>> terminate
>> >> the parent group and that the terminating member/re-init proposer must
>> also
>> >> create the new group.
>> >>
>> >>
>> >>
>> >> For #4: There was a discussion at the first virtual interim in late
>> April
>> >> (Interim #11-2020) wherein some expressed a desire for this feature.
>> Namely,
>> >> instead of re-syncing the entire group, there were use cases for
>> re-syncing the
>> >> odd member when necessary. Its inclusion in the PR arises from that
>> later
>> >> request. I am favorable to removing it since, from security
>> standpoint, it is
>> >> not ideal. However, the motivation for this was pushed from the
>> implementation
>> >> standpoint. Consequently, now is a good time for anyone to speak up
>> who wants to
>> >> push for this.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> One item: you made point of specifically requesting – a few times – at
>> the
>> >> virtual interims #11 and #12 in April/May that this PSK PR and as many
>> other key
>> >> schedule-related PRs be combined into a single one. Raphael made a
>> similar
>> >> request under git issue #325. In fact, the authors of this PR had
>> pushed back on
>> >> that insistence to limit the current PR down to the items it currently
>> covers,
>> >> instead of merging in other key schedule changes as well. Are you
>> saying that
>> >> you have changed your mind?
>> >>
>> >> We can, of course, accommodate a revised preference if needed.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Britta
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> *From: *MLS <mls-bounces@ietf.org> on behalf of Richard Barnes
>> <rlb@ipv.sx>
>> >> *Date: *Wednesday, June 17, 2020 at 3:54 PM
>> >> *To: *Messaging Layer Security WG <mls@ietf.org>
>> >> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group
>> Branching (#336)
>> >>
>> >>
>> >>
>> >> 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 mailing list
>> >> MLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/mls
>> >>
>> >
>> > _______________________________________________
>> > MLS mailing list
>> > MLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/mls
>> >
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>
>