On Tue, Mar 21, 2017 at 7:30 PM, Eric Rescorla <[email protected]> wrote:
> This proposal seems like a reasonable idea. One question I had is what the
> point of the "uncompressed length" field is:
>
> struct {
> uint24 uncompressed_length;
> opaque compressed_certificate_message<1..2^24-1>;
> } Certificate;
>
> I initially thought maybe it was a sanity check, but if so it's not a very
> good
> one. I see that in S 5 you encourage receivers to limit the compressed
> length, but having it expressed like this doesn't seem like that useful a
> security measure because the attacker gets to choose both the compressed
> data and the length. Is the idea just to let the receiver pre-allocate a
> buffer
> for decompression?
>
It's to some extent for all of the purposes you've mentioned, but in
general knowing
the size of decompression target makes writing code easier (since you only
need
to call inflate() once).
> The text says:
>
> compressed_certificate_message The compressed body of the
> Certificate message, in the same format as the server would
> normally express it. The compression algorithm defines how the
> bytes in the compressed_certificate_message are converted into the
> Certificate message.
>
> I assume in this case "body" means "not including the header bytes"? I
> guess it's
> redundant, but it might be worthwhile being very precise
>
Indeed. I'll see if I can make this more clear.
> Also:
>
> The implementations MUST limit the size of the resulting decompressed
> chain to the specified uncompressed length, and they MUST abort the
> connection if the size exceeds that limit. Implementations MAY
> impose a lower limit on the chain size in addition to the 16777216
> byte limit imposed by TLS framing, in which case they MUST apply the
> same limit to the uncompressed chain before starting to decompress
> it.
>
> Do you mean "upper" rather than "lower" for limit?
>
I meant "lower than 16M". I've edited the editor's copy to make this
paragraph clearer.
-- Victor.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
