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
The IESG has approved the following document:
- 'Connection Identifiers for DTLS 1.2'
(draft-ietf-tls-dtls-connection-id-13.txt) as Proposed Standard
This document is the product of the Transport Layer Security Working Group.
The IESG contact persons are Benjamin Kaduk and Roman Danyliw.
A URL
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Connection Identifiers for DTLS 1.2
Authors : Eric Rescorla
Hannes Tschofe
