Hiya, On 14/02/2019 19:21, David Benjamin wrote: > On Wed, Feb 13, 2019 at 6:24 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > > I have been using air quotes for a reason... :-P My personal view on these > things is very far from positive.
That's what I thought. You're right there anyway:-)
>
> The intent was simply to update the existing text talking about this same
> scenario ("A more serious problem is MITM proxies [...] The client can
> detect this case and disable ESNI while in that network configuration"). In
> so far as it made sense for the original document to talk about this, among
> the many complex compatibility considerations in ESNI, I think it continues
> to makes sense for the PR to do so.
>
> That said, you have a good point about the word "correct". I was using that
> just to invert the existing sentence which begins "A non-conformant MITM
> proxy [...]", but you are right that the phrasing in the PR has different
> implications. I need to go through the comments on GitHub and update the
> PR. In doing so, I will also take another stab at wordsmithing this.
> Hopefully I can come up with something less objectionable.
Fair enough.
>>> Is there any reason not to just do it in every ClientHello?
>>
>> I'd guess that some implementers may be put off by the
>> wasted bandwidth. Others won't care but if it's the case
>> that sending a bogus ESNI x% of the time gets as good a
>> result as sending all the time (which is how I interpret
>> what the SHOULD calls for) then it seems better to encourage
>> x% and not 100%.
>>
>
> When Chrome sends GREASE extensions today, we do it unconditionally on all
> ClientHellos.
>
> I think x% doesn't give a great result. Then implementation bugs get
> papered over with some probability on retry. The world is full of
> transparent retries, so this is a poor enforcement of protocol invariants.
> But, in terms of interop, nothing goes wrong if you choose not to send it
> sometimes (maybe you're doing a field trial, I dunno). Hence SHOULD, not
> MUST.
Also fair. I guess we can see what's folks do in other cases.
>>> - Padding to 260 is IIRC the max that works. A CH with such
>>>> padding is ~600 bytes. Seems like a waste of bytes to me and
>>>> it could stick out depending on real ESNI padding_lengths.
>>>> Maybe consider something like "pad to a length that matches
>>>> recent traffic" and leave it to clients to figure out what
>>>> might stick out less. (I'm not sure every server will ask
>>>> for padding to 260 as CF do;-)
>>>>
>>>
>
>> 260 comes from elsewhere which says:
>>>
>>>> The length to pad the ServerNameList value to prior to encryption.
>>>> This value SHOULD be set to the largest ServerNameList the server
>>>> expects to support rounded up the nearest multiple of 16. If the
>>>> server supports wildcard names, it SHOULD set this value to 260.
>>
>> Yeah, and I disagree with that too:-)
>>
>>> I figured that assuming, by default, that the server supports wildcard
>>> names seemed reasonable so the text mirrored the other SHOULD. Though
>> maybe
>>> that's a bit much? I don't have strong feelings here. What do you think
>> the
>>> text should say? Perhaps it should pick a random multiple-of-16 length
>>> between 64 and 260? Or maybe we should decrease the wildcard value... a
>>> 260-byte SNI name is kind of excessive, honestly.
>>
>> Regardless of the above disagreement about 260, if a client has
>> been sending a bunch of CH's including real ESNI that are about
>> 400 bytes because some server's ESNIKeys says to pad to 160, and
>> that client then sends 600 bytes CH's to everyone else, I think
>> it'd be crystal clear which is grease and which not.
>>
As a possible side-note, isn't this greasing a little different
from others - this is also really chaff that functions to discourage
blocking all ESNI (as well as the usual greasing) by causing real
uses of ESNI to "not stand out" as per the section in Christian's
draft. I think that comes into play here.
> This is precisely why client and server recommendations should align. It
> sounds like you believe that the server recommendation of 260 is too much.
That, but moreso that I don't think a per-server padding_length is
really a good design choice. If it's there, different services will
choose different values. That means greasers need to pick a value,
and either that forces all services to pick whatever the best
greaser chooses (or real use of ESNI with that service stands out),
or else it forces greasers to use whatever is the most commonly
used padding_length (current whatever CF deploy I guess, which is
260), and that again means the non grease uses out stand out.
Either way we all end up at 260 or risk getting blocked.
> I would support a change to that (together with a matching client change).
> What do you think it should say instead?
Drop paddling_length entirely and replace it with some MUST level
thing that everyone does. E.g. for real uses of ESNI could be
"padding MUST be to a multiple of 64 octets and SHOULD be minimal"
perhaps with "greasers MUST send some percentage <X% padded to 128
or bigger" and then I think only very few would stand out if we get
X even roughly correct (and we could measure to find a good X).
(I think there are other things we can/should be thinking about
from the "don't stand out" POV, but they, and the suggestion above,
probably go beyond this PR. It's just this PR also highlights the
issue.)
> I don't think "pad to a length that matches recent traffic" works well
> because that adds a bit of correlation between multiple services. It's a
> minor correlation, but such things still aren't great for privacy and
> doesn't seem worth adding here. I certainly would not want to implement
> such a thing. I'm fine with recommending a fixed value, or picking randomly
> within a range. Beyond that, I think the problem should be solved at both
> recommendations together.
Fair point. I was trying to suggest something that'd work within
the scope of this PR. Let me try argue for it a little bit more:
If paddling_length remains as-is, then ISTM that a particular
client will recently have been seen emitting mostly grease-padding
lengths, but also a few different lengths as determined by real
services. In order to stop use of those services sticking out, I
think the greaser needs to emit some CHs matching the lengths of
those real services too. So I'd suggest maybe keeping a set of
(padding_length, probability) tuples and randomly picking from
that when greasing, with that table updated based on traffic
seen/sent. Bit complex yes, but I think that's the consequence
of per service padding_length in ESNIKeys. Sound any better?
Cheers,
S.
>
> David
>
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
