Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-messaging-16: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 19 June 2021 01:23 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118A13A1A7F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 18 Jun 2021 18:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Level:
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YlYF9JYWspA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 18 Jun 2021 18:23:28 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FC23A1A97 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 18 Jun 2021 18:23:28 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1luPdi-0008Rt-P6 for ietf-http-wg-dist@listhub.w3.org; Sat, 19 Jun 2021 01:19:18 +0000
Resent-Date: Sat, 19 Jun 2021 01:19:14 +0000
Resent-Message-Id: <E1luPdi-0008Rt-P6@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <kaduk@mit.edu>) id 1luPcx-0008QP-6F for ietf-http-wg@listhub.w3.org; Sat, 19 Jun 2021 01:18:29 +0000
Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <kaduk@mit.edu>) id 1luPcp-0001l5-Mh for ietf-http-wg@w3.org; Sat, 19 Jun 2021 01:18:24 +0000
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15J1Htq2023397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Jun 2021 21:18:00 -0400
Date: Fri, 18 Jun 2021 18:17:54 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mark Nottingham <mnot@mnot.net>
Cc: Martin Thomson <mt@lowentropy.net>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-messaging@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Message-ID: <20210619011754.GA11634@kduck.mit.edu>
References: <162389376384.2031.14383558836768559852@ietfa.amsl.com> <83B4B04D-0B2B-4A79-B178-28F08467847C@mnot.net> <20210617031531.GU11634@kduck.mit.edu> <812453F4-E080-442B-9E2D-7C8FE5374639@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <812453F4-E080-442B-9E2D-7C8FE5374639@mnot.net>
X-W3C-Hub-Spam-Status: No, score=-10.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1luPcp-0001l5-Mh d2f378fe2432a038281f85f3e9c92fae
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-messaging-16: (with DISCUSS and COMMENT)
Archived-At: <https://www.w3.org/mid/20210619011754.GA11634@kduck.mit.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38923
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Mark,

I suspect that I have missed the point you were trying to make, so my
apologies if the following comes across as confused...

On Thu, Jun 17, 2021 at 02:19:36PM +1000, Mark Nottingham wrote:
> 
> > On 17 Jun 2021, at 1:15 pm, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> > I guess there's two parts, here: "take the scheme from the request-target"
> > seems to fall pretty clearly from §3.3's "the target URI is the
> > request-target".  Getting from that to "engage processing for the https
> > origin" is something more of a leap, and I confess that I was just relying
> > on the intuition I developed over the couple days I spent enjoying
> > -semantics earlier in the week and did not go digging for specific
> > references in -semantics to support that statement.  The origin triple for
> > a URI derives from the scheme (looking now, that's §4.3.1 of -semantics),
> > and so my intuition was presumably trying to extend that to how the
> > namespace is per origin and accordingly the resource representation that
> > would be returned in response to the request in question.  I don't know if
> > there are other places in -semantics that give more specifics on how or
> > whether the target URI affects the origin/namespace that the origin server
> > uses to service the request.
> 
> There *should* be as clear and consistent difference between the request-target (the on-the-wire component in HTTP/1.1) and the target uri / target resource, which is the version-independent concept in semantics. All of the requirements for things like this should be pointed at target [uri, resource], not the request-target.
> 
> If that's not the case somewhere, or we could make that more clear, a pointer or a suggestion would be welcome.

AFAIK this distinction is properly made everywhere.  My complaint was
attempting to focus specifically on the procedure for converting the
request-target to the target URI, since in this one specific case of the
absolute-form request target the procedure is that "the target URI is
defined to have the same value as the request-target" and there seem to be
some edge cases relating to the scheme selection.

At a high level, my point is that if a client sends a request with
request-target of https://www.example.com over TCP-without-TLS, I expect
the client to get back an HTTP 4xx response over that TCP channel, or maybe
just a TCP RST.  In particular, I do not expect it to get a non-4xx
response, and definitely not 200 with content from the "https" origin.
There are actually quite a few places in the flow of processing the message
where this could be done, across both -messaging and -semantics, but I
don't remember a specific place that gives a clear direction to the server
implementation to handle this scenario.

> Martin commented:
> 
> > I think that this question doesn't really read on -messaging, but more 
> > on -semantics.  However, I am not seeing any requirement on the server 
> > to ensure that the response it generates is secured.
> > 
> > s 4.2.2 of semantics -- 
> > https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.uri
> > 
> >> A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time.
> > 
> > No similar requirement is made of the server.  It would be trivial to 
> > impose a similar requirement on servers in that same paragraph.
> 
> I don't think that helps, at least in the case of HTTP/1.1. There, the server is responsible for setting the correct scheme for the target URI when a request is received; the security properties of the request and response follow from that. Effectively, it's not under attacker control.

(This is the part where I'm most confused.)
Where is the requirement specified that the server set the correct scheme
for the target URI?  If the procedure to set the taret URI is "use the
scheme the client gave you", that seems like it's clearly under attacker
control, so I don't understand how you reached the conclusion in the final
sentence.  Were you maybe talking about h2 at that point and not HTTP/1.1?

> However, I don't see any equivalent mechanism regarding :scheme in http/2 bis  or http/3. Off the cuff, I tend to think that security considerations about this probably belong on both of those specs.

That makes sense to me, as does spinning it off to a separate issue for
h2-bis.  I will note that I didn't raise a concern for h3 and :scheme
processing since h3 always requires secure transport and the failure
case didn't seem very significant.

Thanks,

Ben