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

> 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 <rlb@ipv.sx>
Sent: Thursday, 28 April 2022 06:03
To: Alwen, Joel <alwenjo@amazon.com>
Cc: mls@ietf.org
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=40amazon.com@dmarc.ietf.org<mailto:40amazon.com@dmarc.ietf.org>> 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
MLS@ietf.org<mailto:MLS@ietf.org>
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