On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <david...@chromium.org> wrote: > > 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.)
Yep, valid point. > > 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. To be clear, are you suggesting that adding a padding extension to the Certificate message is impractical? (I wouldn't consider this record-level padding.) Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
