Re: [MLS] Encoding padding as variable-size vector

[Richard Barnes <[e-mail]>]

Minor point, but if you wanted to do that, you would need to use the vector
notation

struct {

    select (content_type) { ... }

    MLSMessageAuth auth;

    uint8 zeros<0..2^16-1>;

} MLSCiphertextContent;


But I still think it's cleaner just to not bother with the length prefix,
since it's length-delimited on the outside.


On Mon, May 2, 2022 at 2:34 AM Rohan Mahy <[e-mail]> wrote:

> I think we need:
>
> struct {
>
>     select (content_type) { ... }
>
>     MLSMessageAuth auth;
>
>     uint8 zeros[0..65535];
>
> } MLSCiphertextContent;
>
>
> so the length field of "zeros" is fixed at 2 octets.
>
> 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
>
>
> On Fri, Apr 29, 2022 at 3:21 AM Alwen, Joel <alwenjo=
> [e-mail]> wrote:
>
>> > struct {
>>
>> >    select (content_type) { ... }
>>
>> >    MLSMessageAuth auth;
>>
>> >    uint8 zeros[length_of_padding];
>>
>> > } MLSCiphertextContent;
>>
>>
>>
>> This seems better. I.e. I think it now lets us pad to any target length
>> of the resulting TLS serialization.
>>
>>
>>
>> One thought though: If I were parsing such a TLS serialization from a
>> buffer more data after the struct starting with a 0 byte would I
>> unambiguously know when I’ve reached the end the struct? If not is that a
>> concern?
>>
>>
>>
>> - Joël
>>
>>
>>
>> *From:* Richard Barnes <[e-mail]>
>> *Sent:* Thursday, 28 April 2022 06:03
>> *To:* Alwen, Joel <[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* RE: [EXTERNAL][MLS] Encoding padding as variable-size vector
>>
>>
>>
>> *CAUTION*: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender and
>> know the content is safe.
>>
>>
>>
>> TBH, I'm not sure we need to demarcate the padding at all -- just append
>> zero bytes.  The real, non-padding data in MLSCiphertextContent is itself
>> length-delimited (assuming the content type is known), so there's no need
>> to signal how much padding there is.  It's just whatever bytes are left in
>> the decrypted content.  (We should still require it to be zero).
>>
>>
>>
>> So we could do something like what TLS 1.3 does [1][2]:
>>
>>
>>
>> struct {
>>
>>     select (content_type) { ... }
>>
>>     MLSMessageAuth auth;
>>
>>     uint8 zeros[length_of_padding];
>>
>> } MLSCiphertextContent;
>>
>>
>>
>> ... with some prose to explain and require that any non-zero padding
>> bytes MUST cause a message to be rejected.
>>
>>
>>
>> For context, we arrived at the current scheme in #213 [3].  That PR is
>> still correct that the prior scheme was ... too creative.  The above
>> proposal would have the pendulum swing back a little bit, but I think not
>> too much.
>>
>>
>>
>> --Richard
>>
>>
>>
>>
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.2
>>
>> [2] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4
>>
>> [3] https://github.com/mlswg/mls-protocol/pull/213/files
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 26, 2022 at 9:55 PM Alwen, Joel <alwenjo=
>> [e-mail]> wrote:
>>
>> In the MLSCiphertextContent struct we have a field for padding
>> represented using a variable-size vector which helps hide information about
>> the length of content; notably application messages. But because of the way
>> we encode variable-size vectors it turns out you can't actually pad the
>> rest of the content with certain number of bytes: namely 0, 65, 16386,
>> 16387. (E.g. if you pad with a vector of 63 bytes the TLS encoding actually
>> produces 64 bytes for padding: 63 bytes + 1 length byte. But if you pad
>> with 64 bytes you end up with a 66 byte encoding as now you need 2 bytes
>> for the length.
>>
>> Not being able to pad with 0 is OK. But 65 is kind of annoying. E.g. if
>> you want to pad to a target content length X bytes then if the rest of the
>> content ends up being X-65 bytes long you are out of luck. (Assuming I'm
>> right about how this all works) it seems a bit silly to me for a padding
>> scheme to have somewhat arbitrary gaps like that; especially at a not
>> unreasonable number of bytes to want to pad with.
>>
>> If I didn't miss something, and you all agree that its better to avoid
>> having gaps like that then how about represent padding as, say, a fixed
>> length vector's?
>>
>> - Joël
>>
>>
>> Amazon Development Center Austria GmbH
>> Brueckenkopfgasse 1
>> 8020 Graz
>> Oesterreich
>> Sitz in Graz
>> Firmenbuchnummer: FN 439453 f
>> Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz
>>
>>
>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
>>
>>
>>
>> Amazon Development Center Austria GmbH
>> Brueckenkopfgasse 1
>> 8020 Graz
>> Oesterreich
>> Sitz in Graz
>> Firmenbuchnummer: FN 439453 f
>> Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz
>>
>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
>