On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood < christopherwoo...@gmail.com> wrote:
> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekr...@fb.com> wrote: > > > > 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. > > Of course, and that requires padding on the fly and some way for the > sender to know what is the correct amount of padding per Certificate. > Plumbing up that API seems non-trivial. In comparison, one could > imagine pre-padding wire-encoded Certificate messages a priori using > the extension. So I still think restricting padding to CH is a bit > extreme. > Using the padding extension isn't going to mesh well with the compressed certificates draft. (Compression is perfectly compatible with hiding the length. If all your certificates compress well---they probably do---you can pad based on the distribution of compressed lengths you're trying to mask. Of course, this will leak whether compression happened, but that's not the information that's interesting to hide.) Record-level padding is indeed kind of annoying to plumb properly though. I've always thought the excitement for padding at that layer was somewhat misplaced. I could imagine allowing handshake messages to be punctuated by no-op padding messages, but then it's just one layer to route through to get to the record layer here. I think it's more at higher up the stack where record-level padding really becomes impractical. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
