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

[Rohan Mahy <[e-mail]>]

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
>