Reviewer: Dan Romascanu
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more informati
On the heels of this change, here's another PR that I'd folks to weigh in on:
https://github.com/tlswg/draft-ietf-tls-esni/pull/381
Thanks,
Chris
On Mon, Feb 8, 2021, at 2:29 PM, Christopher Wood wrote:
> We previously had a server-selected label for the ECHConfig, but that
> has since been
I find the language around "optional" configuration identifiers confusing
here. Both of these proposals require ECHConfig to specify an identifier,
and both of them require the client to transmit one, so it doesn't seem
very "optional". I think the point is that special case usage profiles are
pe
I am not in favor of shrinking this to a single byte, as it significantly
limits future flexibility.
As far as I can tell, the argument here is to limit the entropy available
for tracking, but recall that in this case the attacker controls the DNS
and they can (for instance) provide a unique IPv6
On Tue, Feb 16, 2021, at 1:02 PM, Eric Rescorla wrote:
> I am not in favor of shrinking this to a single byte, as it
> significantly limits future flexibility.
>
> As far as I can tell, the argument here is to limit the entropy
> available for tracking, but recall that in this case the attacker
On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote:
> That's true, but I'd personally prefer one tracking vector to two. This
> structure also better aligns with other proposed use cases for HPKE
> configurations. I also don't see an immediate need for flexibility in
> this value given that
On Tue, Feb 16, 2021 at 3:01 PM Martin Thomson wrote:
> On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote:
> > That's true, but I'd personally prefer one tracking vector to two. This
> > structure also better aligns with other proposed use cases for HPKE
> > configurations. I also don't see
> It's not significant extra complexity to have this field bigger and it
> basically makes it impossible to have any structure.
What do you mean by structure? How does a byte not provide sufficient
"structure"?
> On Feb 16, 2021, at 3:33 PM, Eric Rescorla wrote:
>
>
>
> On Tue, Feb 16, 2
Hiya,
On 16/02/2021 21:31, Christopher Wood wrote:
That's true, but I'd personally prefer one tracking vector to two.
This structure also better aligns with other proposed use cases for
HPKE configurations. I also don't see an immediate need for
flexibility in this value given that there are ex
On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle
wrote:
> It's not significant extra complexity to have this field bigger and it
> basically makes it impossible to have any structure.
>
>
> What do you mean by structure? How does a byte not provide sufficient
> "structure"?
>
It's not long enough
On Tue, Feb 16, 2021 at 4:31 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 16/02/2021 21:31, Christopher Wood wrote:
> > That's true, but I'd personally prefer one tracking vector to two.
> > This structure also better aligns with other proposed use cases for
> > HPKE configurations. I also don't se
On 17/02/2021 00:34, Eric Rescorla wrote:
How is it any harder to manage a multi-octet server-chosen value than a
single-octet server-chosen value?
Easier for the library on the server side. If it's >1 octet
then someone will want some semantics. If ==1 then they'll
have to accept none and po
I see. It seems reasonable to me to leave it as a variable-length vector to
provide flexibility. Since the best mitigation for the privacy issue,
regardless of the length of the config_id, is to have a large anonymity set as
described in Security and Privacy Goals, it doesn't seem like a longer
The shorter ID was described as such: "significantly limits future
flexibility."
What "flexibility" is lost?
thanks,
Rob
On Tue, Feb 16, 2021 at 4:57 PM Carrick Bartle wrote:
> I see. It seems reasonable to me to leave it as a variable-length vector
> to provide flexibility. Since the best mi
14 matches
Mail list logo
