Got it — thanks for the clarification! I agree with your conclusion assuming we do not want to make an incompatible wire format change. However, if we’re willing to budge on that, I think it’s worth including. I’m curious to hear what others think.
Best, Chris On Jun 12, 2018, 11:48 AM -0700, David Benjamin <david...@chromium.org>, wrote: > > On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood > > <christopherwoo...@gmail.com> wrote: > > > 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.) > > > > Sorry, that was probably unclear. What I meant was: I agree that > > record-level padding is pretty difficult to use in general, but this > > particular instance is probably(?) not too bad, so it seems sufficient to > > use the existing mechanism rather than make a wire-incompatible change > > (unsolicited Certificate extensions are forbidden) at this stage. > > > > Though I otherwise don't particularly object to jamming the padding > > extension into more places, the compressed certificates point aside.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
