Re: [TLS] Application-Layer Protocol Settings

2020-07-07 Thread Ilari Liusvaara
On Mon, Jul 06, 2020 at 03:12:45PM -0400, Victor Vasiliev wrote: > 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 beg

[TLS] A query related to support the hard-failing when subdomain1.example.com tries to front example.com?

2020-07-07 Thread Avineshwar Singh
In the context of TLS, what can be done to detect a MITM by *subdomain1.example.com * of *example.com *? Can the TLS checks fail (assuming cname contains wildcard)?. Let's say public key pinning isn't used. I could think of *blacklistedSubjectAlt

Re: [TLS] Application-Layer Protocol Settings

2020-07-07 Thread David Benjamin
Hi Martin, You’re right that this is closely related to half-RTT data. However, I don’t think this is a no-op for HTTP/2. I’m not aware of HTTP/2 clients that wait for the SETTINGS frame today. Doing so costs a round-trip with servers that don’t send SETTINGS in half-RTT, and there's no indicator

Re: [TLS] Application-Layer Protocol Settings

2020-07-07 Thread David Benjamin
Hi Ben, (I’ve covered many of these points in my reply to Martin, so you may want to read that first.) Any solution here involves a TLS change, even for servers which currently send half-RTT settings. See my reply to Martin for why. The question then is which is more complex. As a TLS implementor

Re: [TLS] Application-Layer Protocol Settings

2020-07-07 Thread David Benjamin
On Tue, Jul 7, 2020 at 4:38 PM Ben Schwartz wrote: > > On Tue, Jul 7, 2020 at 3:14 PM David Benjamin > wrote: > >> Any solution here involves a TLS change, even for servers which currently >> send half-RTT settings. ... >> > > I think a new ALPN protocol ID > ("h2-but-with-settings-from-the-serv

Re: [TLS] Application-Layer Protocol Settings

2020-07-07 Thread Martin Thomson
Hi David, I think that there is an important difference between something that is hard to realize in practice (as many aspects of this clearly are) and using that to say that the fundamental protocol definition is wrong. I appreciate - at least superficially - the complexities involved here. H