Last Call Review of draft-ietf-tls-padding-01
review-ietf-tls-padding-01-secdir-lc-roca-2015-09-03-00
Request | Review of | draft-ietf-tls-padding |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-09-01 | |
Requested | 2015-08-13 | |
Authors | Adam Langley | |
I-D last updated | 2015-09-03 | |
Completed reviews |
Genart Last Call review of -01
by Meral Shirazipour
(diff)
Genart Telechat review of -02 by Meral Shirazipour (diff) Secdir Last Call review of -01 by Vincent Roca (diff) Opsdir Last Call review of -01 by Susan Hares (diff) |
|
Assignment | Reviewer | Vincent Roca |
State | Completed | |
Request | Last Call review on draft-ietf-tls-padding by Security Area Directorate Assigned | |
Reviewed revision | 01 (document currently at 04) | |
Result | Has nits | |
Completed | 2015-09-03 |
review-ietf-tls-padding-01-secdir-lc-roca-2015-09-03-00
Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. IMHO, the document is almost ready. However I have a question plus a non-security related comment. That’s perhaps a naive question, but let me ask it. Shouldn’t a receiver check that the actual length of the extension_data field is in line with the value of the extension_data length field. Since those zero bytes are actually carried over the net and present in the reception buffer, there could be several ways to calculate this length… (I really don’t know if it’s the case or not) Additionally, section 3 says: The client MUST fill the padding extension completely with zero bytes, although the padding extension may be empty. I think that you mean « padding extension_data field » and not « padding extension »: The client MUST fill the padding extension_data field completely with zero bytes, although the padding extension_data field may be empty. And finally, in the example (figure), instead of: 16-bit, extension_data length I’d rather add a « _ » as in: 16-bit, extension_data_length Cheers, Vincent Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail