You could use the existing Certificate padding mechanism. Which mechanism?! The one in this paragraph:
For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first. I ran an experiment a while ago in which all major browsers (at that point) accepted an arbitrary X.509 certificate in the Certificate message. In other words, you could just build a blob that looks like a DER encoded X.509 certificate and include it in the chain. It is indeed a hack, but in all seriousness, would the client endpoint stacks even bother to change that behavior? (disclaimer: I have not checked the latest behavior). --Roelof > On Jun 12, 2018, at 3:07 PM, Christopher Wood <christopherwoo...@gmail.com> > wrote: > > 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 <mailto:christopherwoo...@gmail.com>> wrote: >> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <david...@chromium.org >> <mailto:david...@chromium.org>> wrote: >> > >> > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood >> > <christopherwoo...@gmail.com <mailto:christopherwoo...@gmail.com>> wrote: >> >> >> >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekr...@fb.com >> >> <mailto: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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
