I support adopting #443. For the server side, I have a weak preference for
#457 (2) over #313 (3) because it makes it easier to implement a complete
solution. I have not yet assessed how hard it is to implement ... perhaps
it would be best if we all tried it out in our respective stacks and report
So I like #443 as I have said. It simplifies padding for CHInner a lot.
I also like #457 (option 3). My initial reaction was not positive, but I've
come to appreciate the value of it. I don't like that this has to be in the
transcript (QUIC doesn't need it by virtue of a design that separates
On Tue, Jun 22, 2021 at 6:12 PM Stephen Farrell
wrote:
> On 22/06/2021 22:57, Christopher Patton wrote:
> > Just to be clear, (1), (2) and (3) are not alternatives to the same
> > problem. (1) solves client-side padding, whereas (2) and (3) are
> > alternatives for solving server-side padding.
>
On 22/06/2021 22:57, Christopher Patton wrote:
Just to be clear, (1), (2) and (3) are not alternatives to the same
problem. (1) solves client-side padding, whereas (2) and (3) are
alternatives for solving server-side padding.
Apologies. (Though I put part of the blame on excessive
githubbery
I think there might be some confusion here. It probably doesn't help that
(1) and [1] are different things. :-)
(1) is a standalone change, unrelated to QUIC, [1], (2), or (3). It's about
changing how we pad the *ClientHelloInner*, which is carried in the ECH
encrypted payload. We currently use th
> (1) aka #443 is the way to go here I think. (Such an aptly
> numbered PR has to be accepted I'd say:-) I'm only convinced
> of that because of QUIC, but that seems like enough or a
> rationale.
>
> I'm against (3) - it'd break too much and cost too much.
>
> WRT (2) I'd prefer to drop that extens
(1) aka #443 is the way to go here I think. (Such an aptly
numbered PR has to be accepted I'd say:-) I'm only convinced
of that because of QUIC, but that seems like enough or a
rationale.
I'm against (3) - it'd break too much and cost too much.
WRT (2) I'd prefer to drop that extensibility rath
Hi all,
One of the last design questions for Encrypted ClientHello (ECH) is to
decide how to pad encrypted handshake messages so that their length does
not leak privacy-sensitive handshake-parameters. The current approach is to
insert padding into the record layer as needed. However, the consensus
Ben Schwartz found some problems and edge cases with the current ECH padding
policy text [1]. This PR proposes a fix:
https://github.com/tlswg/draft-ietf-tls-esni/pull/268
Please have a look and provide feedback.
Thanks,
Chris
[1] https://github.com/tlswg/draft-ietf-tls-esni/issues/252
__
