Since the Certificate message is sent in an encrypted record, the normal record padding mechanism (section 5.4) can be used, rather than sending the padding as actual handshake data.
-----Original Message----- From: TLS <[email protected]> On Behalf Of Christopher Wood Sent: Tuesday, June 12, 2018 1:41 PM To: <[email protected]> <[email protected]> Subject: [TLS] CH padding extension Hi folks, In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21) extension is restricted to the CH and no other handshake messages. Another plausible spot for this extension is in the Certificate message. Specifically, although we're encrypting this message, we may not want to reveal its length. Adding a padding extension seems to address that problem. Granted, RFC7685 [2] clearly indicates that this padding is for the CH, and that server "MUST NOT echo the extension." However, I don't think that rules out server-chosen padding for the Certificate. What do others think? Is this worth a change? Best, Chris [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D28-23section-2D4.2&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=NoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=ULkmSYAHjmTYA-5NcfzbLoiexbGrO9m-LTuTZoMz_T8&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7685&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=NoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=DCiLNYn2n-dm1n-a96cwNup4Yrm8jxj66ynWdfUIzOY&e= _______________________________________________ TLS mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=NoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=gqkkU78PTKoxJ2uHr1YonppiXHwkRP3SRTPlEnP4iE8&e= _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
