On Mon, Oct 21, 2019 at 11:09 AM Eric Rescorla <e...@rtfm.com> wrote:
> > > On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre <say...@gmail.com> wrote: > >> On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla <e...@rtfm.com> wrote: >> >>> >>> >>> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre <say...@gmail.com> wrote: >>> >>>> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe >>>> you just mean it would be superfluous. >>>> >>> >>> Yes, that is what I mean. >>> >> >> OK. To be clear, I understand why there is padding in the spec. I don't >> understand three aspects: >> >> 1) Where did the number 260 come from? It also seems to conflict with the >> "multiples of 16" advice in the previous sentence. >> > > I believe it was large enough to fit the maximum plausible label size, but > I'd have to go look at the relevant issue. > I have not tested this, but I wondered about IDNA-encoded domain names as I read. Is their encoded form always under 255? So, it might be worthwhile for the draft to explain where 260 came from. > > > 2) Why does the server set the padding amount? If clients were allowed to >> vary it with different amounts of zeros, wouldn't that be more anonymous? >> > > No. You want padding to be set to be the longest size that you would send > to any origin in the anonymity group, and the server knows this. Many > client padding strategies leak information over time and it's hard to know > how to construct one that doesn't unless you know the max. For instance, > consider what happens if the anonymity group consists of "a.example" and " > thisisaverylongname.example.com" and the client always pads to the next > 16. > I thought the "padded_length" field might be more useful as a minimum. I agree with you about narrowly-padded messages. None of this stuff signals a flaw in the draft from an interoperability >> perspective--I was able to follow it as a non-expert in TLS and get things >> working. But I still have questions about why things are specified this way. >> > > Generally speaking, these issues were aired on the list or in Github > issues, so the best way to answer them is to go look at the history > I don't agree with this. These questions all concern MUST or SHOULD requirements in the draft. There should be rationales for the requirements that aren't obvious. Especially the "SHOULD" ones. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
