W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

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

From: Martin Thomson <mt@lowentropy.net>
Date: Thu, 17 Jun 2021 12:32:21 +1000
Message-Id: <55f5f91f-da6c-4d13-9c38-42a2ae714bae@www.fastmail.com>
To: ietf-http-wg@w3.org
Cc: "The IESG" <iesg@ietf.org>, draft-ietf-httpbis-messaging@ietf.org, httpbis-chairs@ietf.org, tpauly@apple.com, tpauly@apple.com, "Mark Nottingham" <mnot@mnot.net>
Restoring the CC list (sorry about that).

On Thu, Jun 17, 2021, at 12:13, Martin Thomson wrote:
> On Thu, Jun 17, 2021, at 11:53, Mark Nottingham wrote:
> > > 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
> 
> 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.
> 
> s 4.3.3 of semantics is another place you might look for this: 
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.origin 
> 
> 
Received on Thursday, 17 June 2021 02:33:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 17 June 2021 02:33:14 UTC