Re: [MLS] Sending secrets in WelcomeInfo instead of keys

Richard Barnes <rlb@ipv.sx> Wed, 07 August 2019 18:50 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 EDA4E12071E for <mls@ietfa.amsl.com>; Wed, 7 Aug 2019 11:50:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 oUT977zSl5W9 for <mls@ietfa.amsl.com>; Wed, 7 Aug 2019 11:50:15 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 03DCC1206A7 for <mls@ietf.org>; Wed, 7 Aug 2019 11:50:15 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id z23so180659ote.13 for <mls@ietf.org>; Wed, 07 Aug 2019 11:50:14 -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=RU1NDX6KLqc44YNOykakNF8h18ms1YvMlcJGmHF9POY=; b=RVvBV5pKHTxImYPjTRR5n8dFTPw7JFlzc1+eOjS/USSQoadfPlCmBOy9l59KRk7/tZ X/vc+OXB52gVCrPBHCk9inSjBS0LCmqDFYYQfZ7XT8+wQxPalaUmeKPTznGdUFFwIYaq F6DrQQsMTfUqg/53xQ6YhaFTZxhuIJyELCskv/ZXkAlOeHc5ZKpqiokqPep/2lIVBTJz JeCHtp1dXWws753yRc6zlLLzeG/sk+6x+tbil34p8aCwsXUKtJnjZDZrinTwaVed1QRX 95qyXccTDjdRJ9nyhnoUYG+NpjjD+VR/rCTBPFnL3uHCgF3+VTAQplLq04cRWyr0VWvP tMQQ==
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=RU1NDX6KLqc44YNOykakNF8h18ms1YvMlcJGmHF9POY=; b=Rv6kGCj7+gfP6ETJKbUCoIK2X/Mzgn/GLzW1VKNUdkyyLStyodChKFp+L9O5YIQc+D P++AW+QRrfiuWCFBkoYhJKFscV9bzmy1VZVAnQ8JHRoKF1+LCUviIlXoEub/1BSXkxR3 Auf5t5dFkmi0+bWdwrVh4WfiFP1u+s/4vvIq4aq6lypdwLUkrpH7egsFRVTQHa1CfTIf fU05WYiSQyz4ZlIJph4c2TM+OhMODE12/NCbthHy9H9GEC67zCPryqQRtMfc5urw5YhN yzxB/u8fxnMNLiERVXPz3FRdzCF1cMjVc7PAp9dx1G3cuI2IowfCgKfwFI/Jb1A130eE B73A==
X-Gm-Message-State: APjAAAWk1FjHVZWCWI27yF9ZbvMP7ftI73edgyMqG8MPSkfchiC9ltvh svcLFqazt75fsggR1HrkAf/cMv5RsQNP6288ByXOYw==
X-Google-Smtp-Source: APXvYqzEmYXgRKFoLxHETQX25R+O8y3IHcDBfVA5XJ15o8CyWkHBWarEVBAuFgoTXlnxBplgAb7PugTk/jD/0h71K+0=
X-Received: by 2002:a9d:390:: with SMTP id f16mr9451522otf.93.1565203814167; Wed, 07 Aug 2019 11:50:14 -0700 (PDT)
MIME-Version: 1.0
References: <13C4667A-7D07-4E67-B762-9EF13723160C@fastmail.com>
In-Reply-To: <13C4667A-7D07-4E67-B762-9EF13723160C@fastmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 7 Aug 2019 14:49:14 -0400
Message-ID: <CAL02cgQxLm9n0frnnzhQDLHLCOKRoXTCLBxtS1TK8P_hSbSAAQ@mail.gmail.com>
To: Michael Rosenberg <micro@fastmail.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000584961058f8b697a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/TQ8pu95OQm1-Kxr_6LpXO5QqNCg>
Subject: Re: [MLS] Sending secrets in WelcomeInfo instead of keys
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, 07 Aug 2019 18:50:26 -0000

Hey Michael,

Thanks for bringing this issue up.  WelcomeInfo::add_key_nonce does seem
like kind of a hack.

The change you propose seems sensible to me.  It's also coherent with the
"lazy operations" proposal I presented at IETF 105.  EKR asked there how
one does encrypted Add messages in that context.  After thinking about it
for a bit, the only approach that seems workable to me is to provide the
new joiner with the init_secret, sender_data_secret, and handshake_secret
for the epoch in which he is added.  That would enable the new joiner to
decrypt and process all of the handshake messages since the last Ratchet
message, and thus be joined to the group on the next Ratchet message.
Obviously, this aligns exactly with your proposal.

Benjamin's objection seems to reflect a problem in the invariant rather
than the solution here.  We have always leaked at least the init_secret for
an epoch to a new joiner; this proposal just expands that boundary a bit.
It seems like the right way to arrange this is to clarify which secrets
logically "belong" to which epoch.  The init_secret derived from an
epoch_secret, for example, would belong to the epoch after the
epoch_secret.  (And in your proposal, the handshake_secret and
sender_data_secret would also move to that side of the line.)  Then you
could properly require that the secrets in a given epoch are known only to
the members of the group in that epoch.

--Richard


On Wed, Aug 7, 2019 at 1:58 PM Michael Rosenberg <micro@fastmail.com>; wrote:

> Problem
> -------
>
> The special-casing required to use WelcomeInfo::add_key_nonce in unframing
> Add messages nontrivially increases code complexity.
>
> Framing ordinarily depends on just a handshake_secret and
> sender_data_secret. From those, the framer/unframer derives the handshake
> key/nonce and sender data key/nonce.
>
> But in the case of an Addee processing an incoming Add, the Addee's
> unframer needs to be told to use the handshake key / nonce from the
> previous WelcomeInfo, and be told to not attempt to decrypt
> MLSCiphertext::encrypted_sender_data, because
>
> 1) The only reason it would need to do this is to derive the handshake
> key/nonce, which it already has, and
> 2) the Addee doesn't even know sender_data_key.
>
> This is complex enough that it becomes hard to reason about and painful to
> implement.
>
>
> Proposal
> --------
>
> To reduce the amount of special casing necessary, the handshake_secret and
> sender_data_secret be included in WelcomeInfo instead of handshake_key and
> handshake_nonce. This way, the only steps in the algorithm that differ
> between the Addee and non-Addees is where the inputs to the unframer's
> constructor come from, i.e., Unframer(group_ctx.handshake_secret,
> group_ctx.sender_data_secret) versus
> Unframer(welcome_info.handshake_secret, welcome_info.sender_data_secret).
>
> Benjamin mentioned that this is technically a violation of the secrecy
> invariant of TreeKEM: a user who is not a member of a group at epoch n
> cannot know secrets from epoch n. It should be noted though that this is
> already violated by the existence of WelcomeInfo::init_secret and
> WelcomeInfo::add_key_nonce.
>
> -Michael
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>