[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
- [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Raphael Robert
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Hale, Britta (CIV)
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Chelsea Komlo
- Re: [MLS] Hiding content type Hale, Britta (CIV)
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Chelsea Komlo
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Chelsea Komlo