- From: Eric Gorbaty <e_gorbaty@apple.com>
- Date: Wed, 05 Jul 2023 16:43:34 -0700
- To: Ryan Globus <rglobus@apple.com>
- Cc: ietf-http-wg@w3.org
Hi Ryan, Thanks for the feedback! > "A client MUST NOT send certificates to the server” - I don’t think it’s needed. I understand you’re focusing on server side certificates, but I think it’s fine to leave the door open to client certificates if folks have other use cases. Maybe we can change the "SETTINGS_HTTP_SERVER_CERT_AUTH” setting to mean the endpoint can *receive* certificate frames, so if a server wants to send but not receive these frames, it can set this setting to 0. I do not disagree; we can downgrade the severity of that language or omit a requirement for clients to not send certificates, but just not define any behavior (if this stays scoped to servers). I'm thinking that we still do want endpoints to be able to advertise that they can send certificates as well (or, well, that they support the entire flow here). That said, we could just decide that SETTINGS_SERVER_CERT_AUTH is strictly indicating support for server auth, allowing the possibility of SETTINGS_CLIENT_CERT_AUTH or something like that in the future if there was interest there. > In the second diagram in 3.2, it’d be nice to indicate the server still responds to the CONNECT request in stream N. Agreed, thank you. Will make this adjustment for the next iteration. Thanks, Eric > On Jul 5, 2023, at 12:09 PM, Ryan Globus <rglobus@apple.com> wrote: > > Hi Eric, > > This draft looks great. I have a couple points of feedback: > > * "A client MUST NOT send certificates to the server” - I don’t think it’s needed. I understand you’re focusing on server side certificates, but I think it’s fine to leave the door open to client certificates if folks have other use cases. Maybe we can change the "SETTINGS_HTTP_SERVER_CERT_AUTH” setting to mean the endpoint can *receive* certificate frames, so if a server wants to send but not receive these frames, it can set this setting to 0. > > * In the second diagram in 3.2, it’d be nice to indicate the server still responds to the CONNECT request in stream N. A few options for how to show that: > <----------------------- (stream N) HTTP response — > <----------------------- (stream N) 200 OK — > <----------------------- (stream N) 405 METHOD NOT ALLOWED — > > Thanks, > Ryan Globus > >> On Jul 1, 2023, at 5:41 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: >> >> On Fri, Jun 30, 2023 at 08:43:06PM -0700, Eric Gorbaty wrote: >>> Hello HTTP Enthusiasts, >>> >>> I’ve put up a -00 draft, in collaboration with Mike Bishop (and >>> others), a re-imagining of secondary certs. >>> >>> - https://datatracker.ietf.org/doc/draft-egorbaty-httpbis-secondary-server-certs/ >>> >>> "This document defines a way for HTTP/2 and HTTP/3 servers to send >>> additional certificate-based credentials after a TLS connection is >>> established, based on TLS Exported Authenticators.” >>> >>> It’s pretty similar to the older archived secondary certs draft >>> (https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs-06), >>> with a few key differences: >>> 1. It defines support for both HTTP/2 and HTTP/3 >>> 2. It is focused on unprompted authentication for servers; as it’s >>> the most flexible and simple to coordinate. >>> 3. TLS Exported authenticators are now an RFC >>> >>> A decent amount of the language and ideas are borrowed from the >>> previous draft, credit goes to the previous authors and contributors. >>> >>> The draft is still in early stages and could certainly use some >>> feedback. We’re having some luck at Apple as far as useful >>> implementation is concerned. One of the goals is to build this from >>> the bottom up based on implementation. And probably to leave client >>> authentication out of it. >> >> I would imagine the most common case for this is that the client >> discovers that it already has connection to alt-svc, but that connection >> is not authoritative. So it would like to ask the alt-svc it is >> connected to to authenticate for the origin (as that would be doable >> in 1-RTT, which is way less than setting up a new connection). >> >> If client is in that position, it can not perform any speculative >> actions, but needs to send pure authentication request. >> >> >> A crazy idea I had was to transport this on global OPTIONS (not origin >> OPTIONS). >> >> 1) Early in the connection: >> >> - Client requests OPTIONS * >> - Server responds indicating capability. >> >> 2) When needing to authenticate: >> >> - Client requests OPTIONS * with header indicating this is EA requst, >> and EA request in the body. >> - Server responds with header indicating this is EA, and EA in the >> body (or header indicating an error). >> >> >> Reason not to use origin OPTIONS is that those may get dispatched, which >> is very much undesired here. While global OPTIONS is never dispatched. >> >> >> >> >> -Ilari >> >
Received on Wednesday, 5 July 2023 23:43:58 UTC