Re: [MLS] AEAD data in messages

Richard Barnes <rlb@ipv.sx> Tue, 13 August 2019 14:22 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 6289212087A for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 07:22:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 unEKzIz_cwbS for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 07:22:52 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 060ED120866 for <mls@ietf.org>; Tue, 13 Aug 2019 07:22:52 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id q20so20203306otl.0 for <mls@ietf.org>; Tue, 13 Aug 2019 07:22:51 -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=F4nthDXWOGJVD9uz2Hu8q6UhAP1AD0vYCpHfrCFSgQ4=; b=y7gtwt7jaY+rpcK0UU/hJBDpunyzucMUMml9X020lv+Bz6SUU7QAVSpn+bOKuurTaM qcOMRva+AY70a1ALbk4AaT0zgy5ZzdQJoBP7z2t/8AqBXTFTzQWqGZUqPX5JRchGcF7y wcQ5xCroIvY+4i7+3Kz0BHWi4sTc42J2xGN6YhnpMxUGT+B+STb+yvP6ynx+VndDyOQG ZRzyO8dX73gfRsD4UJZqDFduv9mNx1m/STgsCNGVt8ocTZtHE2IosfL7tbWCLetWHLIw 0qL1cchD006WTsbZnBskBRcCBLdyzt/FJMpxaieRJOm8rb33rAj53Z1Lkk0kcHTHaKf1 VPOw==
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=F4nthDXWOGJVD9uz2Hu8q6UhAP1AD0vYCpHfrCFSgQ4=; b=gHujI2q8fZSnJ/UK3O8SClm8WqoOrvTEk6Ab7zPdobpc8pCPcXUSj5dQC7pKWJiv0n ZtuL42s6hnbE2CDXIoxEbEL4gaBwlrv0uR15OySGVv906cTfpsxrgwa0WRKFeDSZyZaC KNV7rwmYwo4NNbaGLM0zwZnbmClJEAL6dB4DUeki7MFXrEHjF29Tdw1ljtZyohhBvgmv YwMOii/VhlATQWUc79mxUJCBg5GAp1rJ1aZQesmYIeWxBY2YYAUbbHxvjbz7hS0URMk6 kIAlirijmW6VaC0QE4VA7r3LGjTLwb1xLKDCBoMbyxBgicyMBUpOhVkiZuksa/i4N9zI m1Yw==
X-Gm-Message-State: APjAAAV6uf1yIIhqTgIwNlGGZCLS7Ve5GrHEUpK8qBrPMBrhKBN39zPV vl4KjwOt+tuJokw3Ymr61vp6k0RiHtIlNh6CyAbRXg==
X-Google-Smtp-Source: APXvYqyKSIET8+CjFJkH1njMJaxAHjCuYdTXCSyxpO9UNt2IClIZjqlFbOmJz/+ka4iadT+o8jUUChj5g38jg0almVk=
X-Received: by 2002:a9d:7c87:: with SMTP id q7mr12724189otn.241.1565706171283; Tue, 13 Aug 2019 07:22:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ1bmRnw3WmQZstaHi2+gmA1jrQKy_A2vAk6AYVEG3QwGke7MQ@mail.gmail.com> <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> <CAJ1bmRkWNSdUGEoC83tG=BFwqXq-3XXqAR3WHxmGWWJvVL7O+A@mail.gmail.com>
In-Reply-To: <CAJ1bmRkWNSdUGEoC83tG=BFwqXq-3XXqAR3WHxmGWWJvVL7O+A@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 13 Aug 2019 10:21:49 -0400
Message-ID: <CAL02cgRYcwRQ==4LbBvgi8q45KaAp=rgNdnP+W2zxLRnvzg9dQ@mail.gmail.com>
To: Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org>
Cc: Jeff Burdges <burdges@gnunet.org>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000298cf90590006027"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/EpRp63FClLL3g11lbKSc3aNGVek>
Subject: Re: [MLS] AEAD data in messages
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, 13 Aug 2019 14:22:54 -0000

I don't think we have a slot for this, but it seems sensible enough.
Basically you'd just be changing the API from
session.encrypt(application_data) to session.encrypt(aad,
application_data).  I'd be happy to review a PR.

--Richard

On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala <psla=2Bmls=
40google.com@dmarc.ietf.org> wrote:

>
>
> On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges <burdges@gnunet.org> wrote:
>
>>
>>
>> > On 13 Aug 2019, at 01:15, Peter Slatala <psla=2Bmls=
>> 40google.com@dmarc.ietf.org> wrote:
>> > I was wondering if you considered allowing additional plaintext but
>> authenticated data in MLS messages.
>>
>> It’d be outside the header encryption, making the AEAD would be the
>> header encryption?
>>
>> How would the delivery service authenticate it?
>
>  Delivery service is often TLS encrypted so client-server connection
> should be secure.
>
>
>> > Here are some use-cases for MLS that I can think of:
>> > * sending a 'sending device identifier' in case if delivery service
>> can't differentiate different user devices from each other.
>>
>> I’d hope the delivery service does not care too much to which device it
>> communicates.
>>
>> > * sending 'message type' that server can act upon. For example,
>> delivery report sent by the recipient to the sender, which also acts as an
>> ACK to the server that the message was persisted.
>>
>> > * authenticating message id (but make it visible to server to avoid
>> redelivery),
>>
>> ACKs and message ids should often be done fully encrypted, but yeah
>> making one ACK or message id notify both the delivery service and the end
>> user makes sense in some use cases.
>>
>> Jeff
>>
>>
>> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>