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 <tls-boun...@ietf.org> On Behalf Of Christopher Wood Sent: Tuesday, June 12, 2018 1:41 PM To: <tls@ietf.org> <tls@ietf.org> 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 TLS@ietf.org 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
