On Sat, Jun 29, 2019 at 08:36:49AM -0400, Yishuai Li wrote: > Thanks Ilari. > > Ilari Liusvaara <ilariliusva...@welho.com> 于2019年6月28日周五 上午4:01写道： > > 1) 0x16 byte is appended to plaintext to yield TLSInnerPlaintext > > (since this is encrypted handshake message), together with 0 > > trailing zeroes (for padding, there could be more). > > 1. Is it worth adding this explanation to RFC 8448? Neither > "TLSInnerPlaintext" or "0x16" was mentioned in the context, making > this "Informational" RFC not so informative.
Well, the RFC 8448 does not cosider how the record protection works internally. > 2. Is there a specific reason to structure TLSInnerPlaintext this way? > Does it make parsing counterintuitive that the parser must know > ContentType before locating ContentType? Yes, to encrypt the content type of encrypted records and offer to pad them with no extra overhead (there is no padding length field). It was not possible to encrypt the main content type field due to the fact that the range is not bit-aligned. Parsing should not be that difficult: - If outer content type is 21, it is unencrypted alert, if 22 it is unencrypted handshake fragment and if 23, it is encrypted record, that one should attempt to decrypt. If this fails, send fatal alert. - For unencrypted records, payload starts at byte 5 of the record and extends to the end. - For encrypted records, After decrypting, scan for last nonzero byte. If none is found, send fatal alert. - The last nonzero byte is true content type. - The part of decrypt output before that last nonzero byte is the record payload. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
