[MLS] Hiding content type

Richard Barnes <rlb@ipv.sx> Mon, 13 July 2020 13:56 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 5FFF23A11FB for <mls@ietfa.amsl.com>; Mon, 13 Jul 2020 06:56:19 -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 kyXdEFWdgqYB for <mls@ietfa.amsl.com>; Mon, 13 Jul 2020 06:56:17 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 9EA043A11F1 for <mls@ietf.org>; Mon, 13 Jul 2020 06:56:17 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id k18so9925450qtm.10 for <mls@ietf.org>; Mon, 13 Jul 2020 06:56:17 -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=XLkHcEKwfZSwK0FO7kcLPwlzLqUEA6DIfBY/bZeEy2I=; b=hD+Vz3ukatN+Yq1MCNs+YQIEeVTA6zPvP+j/rezUD7YZpxTA4SoficpVEgF2M5TAsC ctVaQCezV+lildSgwBfrvadDmzcoOOK0XLu/8is4q360DbwFfi0jz4vFKgyvSzl6tXX7 x7iWZNcAY9CO9HqErD6mmDhN0N7VXJ1OviOYs2S6ng+AqY12LgZyEMqQG3CLfsDME8sA QWnxnklnzFWtraj9V8p+xctH88xKTAzmZxcC/kcB1xZ4KIKsOdJHqpxTqsyBBTNH6GH0 LsWDEAhARX8IiDDl2+hHzMQ/XqIwFdtjmNnFxxE4BNYAPizz+TOJxNcdQhmy4g00v2we Ycxw==
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=XLkHcEKwfZSwK0FO7kcLPwlzLqUEA6DIfBY/bZeEy2I=; b=MZkMoDZuwCQ4zEBsISCzeu2V5JiUnPdzKYAzxNhw0AcC1kSCZlMcvD0XZsPRxPdrfQ r154Zjf+qRMh6+f3xb2dYVNQGppwKPH05ceMft9oWBQkh3OFxRP3m4e4LGFxIoeqim6D fbtbVioDDdWVhgGS8NAEOotHA7wxDZLuNmwRWWqxz505l/Ns6PpLyE6D6MZIcm/Bhp0L czLYj00kinUFB52M6V5DklR2fqOIU5/q0Qzn8EFvVwFNOd0IF02VbnVULByamET4hA3x gorjnqDm1WTHqUQqMfbwYwuhYPQ3qSpz7EXk7/DR+Bxe7CFKpfo8s3+hjJCSKJik6yAK yw8A==
X-Gm-Message-State: AOAM530gB7J7+D6CfXYntdtPpCf/y2pi+rnJL672OkAzxoUi0eNJurm7 eOplpItat/lPedd58vtWnLKARNg8iFLlWYib35MIBtB0JWM=
X-Google-Smtp-Source: ABdhPJw4eFmjUYYf9SLme6wCTJldkwoBH8vYYxX3suGzZW9sXDXGIsPf5pJrqLnwUsBVpxUNQVWsU31YIB7VsO0wUWk=
X-Received: by 2002:ac8:4649:: with SMTP id f9mr35077764qto.313.1594648576162; Mon, 13 Jul 2020 06:56:16 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 13 Jul 2020 09:55:55 -0400
Message-ID: <CAL02cgT4jBiJNCoRBsBc7hRWBX0qzmZjC8B8XmJnGcZXgEiCdg@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ec99d205aa530d0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/mtjbsnRrx70plQ2_Z3A2DM7sCSU>
Subject: [MLS] Hiding content type
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: Mon, 13 Jul 2020 13:56:19 -0000

Hi all,

Recall that PR#349 does two things (1) use an opaque epoch ID, and (2)
encrypt the content type of the message (application / proposal / commit)
[1].

There was some discussion on the call last week that encrypting the content
type might not be that useful, since an application that relies on a server
to assure ordering of commits will need to at least be able to tell commits
from other things.  Of course, even if the content type is encrypted by
default, the application can add it back in authenticated data, or in some
unauthenticated wrapper.

Net of those considerations, I'm personally still inclined to merge the PR,
to have a conservative baseline.  But those on the call thought it would be
useful to pose this to the group, so please speak up if you have concerns.

--Richard

[1] https://github.com/mlswg/mls-protocol/pull/349