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

[Richard Barnes <[e-mail]>]

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
>