Subject: [MLS] TLS presentation layer issues

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 Jan 2022 12:28:48 -0800

Hi,
I've started rereading the spec from scratch trying to look at it in detail
with fresh eyes. The following issues are related to our use of the TLS
Presentation format.

1) The Comment format uses // in several places as a comment. But both
TLS1.2 and TLS1.3 specify only /*  */ for comments.

2) "authenticated_data" is a poor name, as it is alongside a bunch of other
data which will all be authenticated. What is special about this
authenticated data? At least there is some explanation of the separate
"additional_authenticated_data" field.

3) There are a few places where "optional" is used, that are required or
forbidden in specific cases that are straightforward to fully specify
(reformulated below).

4) We shouldn't reuse a presentation stanza (MLSPlaintext) both for a wire
framing format and for an intermediary unless they are the same (see
reformulation below).

struct {
    WireFormat wire_format;
    opaque group_id<0..255>;
    uint64 epoch;
    Sender sender;
    opaque extra_authenticated_data<0..2^32-1>;
    ContentType content_type;
    select (MLSPlaintext.content_type) {
        case application:
          opaque application_data<0..2^32-1>;
        case proposal:
          Proposal proposal;
        case commit:
          Commit commit;
    }
} MLSPlaintextTBS;

struct {
    WireFormat wire_format = mls_plaintext;
    opaque group_id<0..255>;
    uint64 epoch;
    Sender sender;
    opaque extra_authenticated_data<0..2^32-1>;
    ContentType content_type;
    select (MLSPlaintext.content_type) {
        case proposal:
          Proposal proposal;
        case commit:
          Commit commit;
    }
    opaque mls_plaintext_signature<Signature_length>;
    select (MLSPlaintext.content_type) {
        case commit:
            opaque confirmation_tag<MAC_length>;
    }
    select (MLSPlaintext.sender.sender_type) {
        case member:
            opaque membership_tag<MAC_length>;
    }
} MLSPlaintext;

struct {
    select (MLSCiphertext.content_type) {
        case application:
          opaque application_data<0..2^32-1>;
          opaque signature<0..2^16-1>;
        case proposal:
          Proposal proposal;
          opaque signature<0..2^16-1>;
        case commit:
          Commit commit;
          opaque signature<0..2^16-1>;
          MAC confirmation_tag;
    }
    opaque padding<0..2^16-1>;
} MLSCiphertextContent;

Thanks,
-rohan

*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire

Wire <https://wire.com/en/download/> - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675