I commented on the pull requests, but to close the loop here:
I can live with the acceptance signal proposed in #423. However, I might still
prefer the approach I proposed. I say "might" because I might not understand
the objections that have been raised properly.
I *think* that the main conc
HI Martin, all, I added another alternative, so let me summarize for
everyone the possible paths forward, with links to the corresponding PRs.
1. https://github.com/tlswg/draft-ietf-tls-esni/pull/407: HRRInner and
HRROuter (original proposal, deemed too complicated).
2. https://github.com/tlswg/dr
I've created a few pull requests that make the changes I propose. I think that
the whole suite of related issues are closed as a result.
The main one is here: https://github.com/tlswg/draft-ietf-tls-esni/pull/417
There's a bit of rewriting here, but the change is not that large. I would
expect
I'm going to briefly respond, but as this is a public holiday and I have no
real desire to work too much, please forgive any radio silence that follows.
On Fri, Apr 2, 2021, at 05:56, David Benjamin wrote:
> This was a previous attempt at this, but it seems to have been confusing.
>
> I do agree
Hiya,
On 01/04/2021 19:24, Stephen Farrell wrote:
some guidance on checking your front-
end's choice of curves and failing when some of the HRR
cases get out of whack
Actually it occurs to me that we could for example say
that back-ends are RECOMMENDED to support the first
curve listed in ECH
Hi Martin,
Thanks for the comments. As the author of #374, I obviously didn't think it
so clearly unnecessary, but glad to hear your thoughts. Hopefully we can
get on the same page as to what the issues are and/or a better solution.
(Always happy to replace something with a simpler option, provide
Hiya,
On 01/04/2021 19:28, Carrick Bartle wrote:
I absolutely agree both that we seem to be almost happily adding
complexity
I don't think you have to assume bad intent (or negligence). Several
people brought up valid concerns and we're trying to address them.
Hmm. I got an offlist mail on
> I absolutely agree both that we seem to be almost
> happily adding complexity
I don't think you have to assume bad intent (or negligence). Several people
brought up valid concerns and we're trying to address them.
> On Apr 1, 2021, at 4:46 AM, Stephen Farrell wrote:
>
>
> I'm not sure I ag
Hiya,
On 01/04/2021 19:13, Christopher Patton wrote:
But let me ask a question meanwhile - how often does HRR
actually happen and could we not just let ECH fail in a
bunch of situations that would otherwise require all this
new complexity?
One way HRR is used is in case the client's and serv
One way HRR is used is in case the client's and server's cipher suite
> preferences don't intersect. This feature is an essential part of TLS, as
> there's no a priori reason why the client and server will initially
> advertise overlapping preferences. (They usually do, hence the claim that
> HRR i
> But let me ask a question meanwhile - how often does HRR
> actually happen and could we not just let ECH fail in a
> bunch of situations that would otherwise require all this
> new complexity?
>
One way HRR is used is in case the client's and server's cipher suite
preferences don't intersect. Th
Given the range of Martin's comments, I'd be surprised
if that could be reduced to a PR;-)
But let me ask a question meanwhile - how often does HRR
actually happen and could we not just let ECH fail in a
bunch of situations that would otherwise require all this
new complexity?
Thanks,
S.
On 0
Hi Martin, would you mind working out a PR? I think being able to compare
407 to a concrete alternative would be helpful. Just so that we're on the
same page, here's a quick summary of the issues that 407 is designed to
solve. (These may or may not be problems in your view, and I don't claim
this l
I'm not sure I agree with all of Martin's remarks below,
but I absolutely agree both that we seem to be almost
happily adding complexity and that that's a bad plan.
S.
On 01/04/2021 02:57, Martin Thomson wrote:
I just reviewed the proposal to split HelloRetryRequest into outer and
(encrypted)
14 matches
Mail list logo
