Re: [MLS] Keying Material Exporter

Raphael Robert <raphael@wire.com> Tue, 07 January 2020 14:12 UTC

Return-Path: <raphael@wire.com>
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 74171120123 for <mls@ietfa.amsl.com>; Tue, 7 Jan 2020 06:12:26 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=wire-com.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 NcDKn8ZCMT6n for <mls@ietfa.amsl.com>; Tue, 7 Jan 2020 06:12:24 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 88D1D1200E9 for <mls@ietf.org>; Tue, 7 Jan 2020 06:12:23 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id u71so54850209lje.11 for <mls@ietf.org>; Tue, 07 Jan 2020 06:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AWbtwwrRI2IusDa1r1DLYrt5bAeME+E5ZSCuZwJquqw=; b=UPaZPBrfmhiy99qzJT6cFi2XoK9ybSr9hEphH5grb6mYcdIsuCVHg160g371Rv+8IB L2YSnEbqa88yX8hhYtuN21XkAa9G2PC01Xz0+dyK/HVvTjWbRooJGw3rkPQk6Nva9q3+ z5kecSv0mcKQPQQmDJk5kx0k+mzhaG45/x4pNWHWdlBT3aL/9iojsL6OUYKo0zldyaBZ o0B/HMf3GoExNSgjaLPrzAFtM7sPWlZVy7a2pu3kPB3Ij+hVlIFK6Zm03BDnLwmk35TX yEiAWKoQ+HldhAxj6qs72jK7QT11ww4NeKpFiLB9M9ty+81AbwiERkCqHTvunio+/TiK Vi4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AWbtwwrRI2IusDa1r1DLYrt5bAeME+E5ZSCuZwJquqw=; b=hSKtCmCW9Mz0QO1Ffr4fP9JyOWVxbigRaHjPMHF+1ilD7o5iSvk2QI2XC04eStrxlu VQRnitOZRglVSV9uSIvupFAoaY5IghE9LqkfT3ZUSlLy34Ndy0EvNg3JHEr40pDoxdmA B+6gPvrPFmTVOAgvq2mWcG74B2IQKYYgkWLWNjU1zfEIxoUZrkOM5Rpbnvx/LLtyuG5P AVz0jDtSINUefj5Y0VLD8zRpPk/fgH6POPNN4Z/b2s8aIMYLNFde3qRAErst2kVveJRB jtcMnFolitNK+zXZG+Ud/Nj9JIVlXbXZrN+T/a9HiTMBplcbQnBG5Nk3tvooKKd7Eybk zZFw==
X-Gm-Message-State: APjAAAUY3Re2Ra79F4JOyqfiJJKoRhAjFOo9IT3jBAF5sfIGvthheyJa Yllsp+Eil5VPCM7ekMk/unX+JBx+MzB3oQ==
X-Google-Smtp-Source: APXvYqw733xiIWBC0WpHsqiqUSMIk2bgNjQfEtVYmtMSnIPCFOQGpqWMyZkUMPPG6zcPIoLPgcwQkw==
X-Received: by 2002:a2e:83d5:: with SMTP id s21mr58437965ljh.95.1578406341752; Tue, 07 Jan 2020 06:12:21 -0800 (PST)
Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id w8sm29663543ljd.13.2020.01.07.06.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 06:12:20 -0800 (PST)
From: Raphael Robert <raphael@wire.com>
Message-Id: <F1B6CDA6-D08C-4350-9B0E-36FE037A7BD4@wire.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FAE2F2B2-A82C-4F46-A375-5C277D52CD88"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 7 Jan 2020 15:12:19 +0100
In-Reply-To: <d4776960-5176-fb43-fff2-44fde0dc7b93@rfc2549.org>
Cc: mls@ietf.org
To: Arne Schwabe <arne@rfc2549.org>
References: <d4776960-5176-fb43-fff2-44fde0dc7b93@rfc2549.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/AhWpZyzTsj5NYj2eI3QW84k2bvI>
Subject: Re: [MLS] Keying Material Exporter
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, 07 Jan 2020 14:12:26 -0000

Hi Arne,

Yes, there is a way to export secrets from the key schedule. You can find the details in the “Exporters” section in the LS protocol draft (https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md>)
I hope that helps, otherwise let us know.

Thanks

Raphael

> On 7 Jan 2020, at 15:08, Arne Schwabe <arne@rfc2549.org>; wrote:
> 
> Hey,
> 
> this is my first mail to an IETF mailing list, so please point out my
> mistakes to me. I also want to apologise if this the wrong way to
> interact with standardising working groups.
> 
> My question is if there are any plans to add an interface for keying
> material export to MLS?
> 
> Let me explain the background why I am asking this. Some might be
> familiar with RFC 5705. RFC 5705 adds a standardised interface to TLS to
> generate/derive keying material from a TLS session, so it can be used
> for example used in the encryption an UDP datastream.
> 
> Since my background is being a OpenVPN core developer, I will write the
> rest a bit from that perspective. OpenVPN basically does a standard TLS
> session and then does a TLS inspired custom key derivation with normal
> messages over that secure channel to generate the session key for
> encryption of data packets. The TLS standardised key export (RFC5705) is
> planned to replace the custom key derivation schema. Typically, in a VPN
> you have have point to point encrypted links and the VPN server will
> decrypt the data and reencrypt it before sending it to a different
> client. And a compromise of the VPN server compromises all communication
> if not secured otherwise.
> 
> The idea is to use MLS to create a VPN, where the VPN server (or some
> VPN "cloud") is not fully trusted but mainly would only route and
> forward the (encrypted) IP packets between the clients. MLS would then
> be used to create 2 member groups for direct communication and multiple
> member groups for multicast/broadcast communication. While also
> application messages could be used then to securely agree on a session
> key for the encrypted IP packets, having a keying material exporter
> function in MLS would be much better than to reinvent the wheel.
> 
> I recognise that my intended use of MLS is probably not the
> focus/intended use of the MLS protocol. But it looks that MLS could
> solve my problem without the need to implement a custom protocol for the
> same purpose (which is never a good idea). And the additional feature
> are also nice to have.
> 
> Arne
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls