- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 17 Jun 2021 11:53:26 +1000
- To: Benjamin Kaduk <kaduk@mit.edu>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-messaging@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Hi Ben, > On 17 Jun 2021, at 11:36 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: > > Let's discuss whether the currently specified procedures for > reconstructing the target URI For others' benefit: this is s 3.3. > from a request-target in absolute-form > provide adequate security properties, at the origin server. I'm > specifically concerned about taking the scheme directly from the request > target, i.e., making the distinction between the "http" and "https" > schemes. The simple procedure of "take the scheme from the > request-target" would seem to allow for the client to cause the server > to engage processing for the "https" origin without receiving the > protection that https is supposed to provide. Where do you see that behaviour specified? > (The converse case does > not immediately seem to present much risk but is probably worth > preventing as well on general principles of retaining consistency.) I > don't remember seeing any text that would require the server to validate > the scheme from the request-target against the actual properties of the > transport (or the configured fixed URI scheme as might be provisioned > with a trusted outbound gateway, etc.) While we do reference ยง7.4 of > [Semantics] with a note that reconstructing the target URI is only part > of the process of identifying a target resource, that part of > [Semantics] does not mention scheme validation as part of rejecting > misdirected requests. > > Does the origin server need to validate the scheme from an absolute-form > request-target? What is the scope of consequences if it fails to do so? -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 17 June 2021 01:53:57 UTC