On Tue, Mar 21, 2017 at 7:30 PM, Eric Rescorla <e...@rtfm.com> 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls