bering settings makes 0-RTT useless anyways, so
this is kind of moot. That said, we could add an "upgrade to compatible
settings" mechanism similar to QUIC if people believe it's useful.
Also, from what I recall, the approach we chose for HTTP/3 was partially
motivated by the order
Hello TLS and HTTP working groups,
(QUIC WG bcc'd as this has been discussed there before)
Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2
and HTTP/3. The SETTINGS frame is sent at the very beginning of TLS
application data; this approach, while simple, has some drawbac
Thank you for your comments!
I've opened a PR to address them:
https://github.com/tlswg/certificate-compression/pull/25
On Sat, Mar 30, 2019 at 2:26 AM John Mattsson
wrote:
> Two short comments:
>
> - Would be good to mention that the document does not specify any
> preset dictionaries.
>
Did we ever reach any agreement about what to do here?
For me, the threat model here seems fairly far-fetched and infeasible, in
the sense that the threat only exists in some very specific bugs in
multithreaded decompressor.
I'd be less reluctant to do this if it were not for the fact that all
so
On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk wrote:
>
> The new note about "no ServerHello extension to echo back" makes me
> wonder if (not) echoing back in Certificate should also be mentioned,
> since the TLS 1.3 paradigm is that CertificateRequest extensions are
> also "requests" that can
On Thu, Dec 14, 2017 at 5:43 PM, David Benjamin
wrote:
> Another observation about the middlebox issue: if we leave the text as-is,
> where it is defined for TLS 1.2 server certificates, but we all silently
> agree that servers should decline it at TLS 1.2, clients are still
> obligated to implem
Currently, TLS 1.3 specification forbids resuming the session if SNI values
do not match. This is inefficient in multiple cases, for example, if you
have a wildcard domain cert, and the user is likely to visit multiple
subdomains over a longer timespan, so there is no existing connection to
pool o
On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla wrote:
> I've just gone through this thread and I'm having a very hard time
> understanding what the actual substantive argument is about.
>
I believe at this point we mostly disagree on what specific scenarios
are and are not a concern that should b
On Tue, Mar 21, 2017 at 7:30 PM, Eric Rescorla wrote:
> This proposal seems like a reasonable idea. One question I had is what the
> point of the "uncompressed length" field is:
>
>struct {
> uint24 uncompressed_length;
> opaque compressed_certificate_message<1..2^
It seems that this issue has not been so far successfully resolved, and to
the
best of my knowledge it has not been discussed during the meeting in Seoul.
I
still believe that this is a valuable feature, and our experience with 0-RTT
handshake deployment in QUIC has indicated that it's basically r
On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku wrote:
> I oppose to going to TLS 4, due to the following reasons:
>
> * it might give people false notion that SSL 2.0, 3.0 is superior to TLS
> 1.0-1.2
> * if name the new protocol TLS 1.3, 2.0, or 2, then there would be no
> confusion once SSL goes
11 matches
Mail list logo
