Subject: Eric Rescorla's No Objection on draft-ietf-httpbis-origin-frame-04: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 06 Jan 2018 18:11:37 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-origin-frame-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to
   indicate what origin(s) [RFC6454] the server would like the client to
The citation here is to the frame format. I think you could make this clearer
and also point the user to that section for the conventions,

   The ORIGIN frame type is 0xc (decimal 12), and contains zero to many
   Origin-Entry.
Nit: "zero or more" is conventional

      serialization of an origin ([RFC6454], Section 6.2) that the
      sender believes this connection is or could be authoritative for.
What are the semantics of a zero-length origin entry? It seems like an odd
thing to allow.

   Note that for a connection to be considered authoritative for a given
   origin, the client is still required to obtain a certificate that
   passes suitable checks; see [RFC7540] Section 9.1.1 for more
"Obtain" seems confusing here. Perhaps "the server is still required to
authenticate using"

   viable connection to an origin open at any time.  When this occurs,
   clients SHOULD not emit new requests on any connection whose Origin
   Set is a proper subset of another connection's Origin Set, and SHOULD
Nit: SHOULD NOT

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Jan 2018 13:51:37 +1100

Hi EKR,

> and also point the user to that section for the conventions,

Did this comment get truncated?

> Nit: "zero or more" is conventional

Will be in -05.

> What are the semantics of a zero-length origin entry? It seems like an odd

I suppose, but so is an origin-entry with a length of 1 (since it needs to be a FQDN, effectively). Where do we draw the line? The semantics are defined above the syntax.

> "Obtain" seems confusing here. Perhaps "the server is still required to

Could you please provide complete text? This section has been agonised over a fair amount.

>   Set is a proper subset of another connection's Origin Set, and SHOULD

Will be in -05.

Thanks!

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Jan 2018 19:20:10 -0800

> Did this comment get truncated?

No, it's just badly written. The point here is that the citation to 7540
section 4 isn't
to the ORIGIN frame but rather to the *format* of a frame. So, this text is
confusing.
I would say

This document defines a new HTTP/2 frame type ([RFC7540], Section 4) called
ORIGING, which...

> > Nit: "zero or more" is conventional

OK.

> I suppose, but so is an origin-entry with a length of 1 (since it needs to
> be a FQDN, effectively). Where do we draw the line? The semantics are
> defined above the syntax.
>

Well, zero length does seem special.

> Could you please provide complete text? This section has been agonised

I would say:

" A connection MUST NOT be considered authoritative for a given origin
unless the
server has authenticated to the client using a certificate that would have
been acceptable
for that origin; see ...."

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Jan 2018 09:48:04 +1100

> On 10 Jan 2018, at 2:20 pm, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> No, it's just badly written. The point here is that the citation to 7540 section 4 isn't
> to the ORIGIN frame but rather to the *format* of a frame. So, this text is confusing.
> I would say
> 

Done.

[...]

> " A connection MUST NOT be considered authoritative for a given origin unless the
> server has authenticated to the client using a certificate that would have been acceptable

That makes it a requirement, which repeats one already in 7540. We try to avoid repeating requirements of other specs, since any deviation in wording or context can cause conflicting interpretations.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Jan 2018 14:56:44 -0800

On Wed, Jan 10, 2018 at 2:48 PM, Mark Nottingham <[email-masked]> wrote:

> That makes it a requirement, which repeats one already in 7540. We try to
> avoid repeating requirements of other specs, since any deviation in wording
> or context can cause conflicting interpretations.
>

Well, then I'm not quite sure what you're looking for here.

-Ekr

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Jan 2018 09:28:37 +1100

> On 11 Jan 2018, at 9:56 am, Eric Rescorla <[email-masked]> wrote:
> 

*scratches head*

I'm happy to ship the doc as-is; what are you looking for?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Jan 2018 14:38:19 -0800

I am looking for text which is technically accurate. the current text is
not, for any sense of "obtain". What is required here is that the server
authenticate to the client with a private key that corresponds to a
certificate which passes the suitable tests. That's entirely different from
"obtain".

-Ekr

On Thu, Jan 11, 2018 at 2:28 PM, Mark Nottingham <[email-masked]> wrote:

> > That makes it a requirement, which repeats one already in 7540. We try
> to avoid repeating requirements of other specs, since any deviation in
> wording or context can cause conflicting interpretations.
> >

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Jan 2018 10:16:55 +1100

> On 12 Jan 2018, at 9:38 am, Eric Rescorla <[email-masked]> wrote:
> 
> I am looking for text which is technically accurate. the current text is not, for any sense of "obtain". What is required here is that the server authenticate to the client with a private key that corresponds to a certificate which passes the suitable tests. That's entirely different from "obtain".

How about:

Original: """
Note that for a connection to be considered authoritative for a given origin, the client is still required to obtain a certificate that passes suitable checks..."""

Update: """
Note that for a connection to be considered authoritative for a given origin, the server is still required to present a certificate that passes suitable checks..."""

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Jan 2018 15:19:10 -0800

"present" seems too weak. You need to prove possession of the private key,
not just show it. How about "authenticate with"?

On Thu, Jan 11, 2018 at 3:16 PM, Mark Nottingham <[email-masked]> wrote:

> origin, the client is still required to obtain a certificate that passes
> suitable checks..."""
>
> Update: """
> origin, the server is still required to present a certificate that passes
> suitable checks..."""
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Jan 2018 10:20:32 +1100

WFM, committing.

Thanks,

> On 12 Jan 2018, at 10:19 am, Eric Rescorla <[email-masked]> wrote:
> 
> "present" seems too weak. You need to prove possession of the private key, not just show it. How about "authenticate with"?
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Jan 2018 15:26:11 -0800

Sold

On Thu, Jan 11, 2018 at 3:20 PM, Mark Nottingham <[email-masked]> wrote:

> > "present" seems too weak. You need to prove possession of the private
> key, not just show it. How about "authenticate with"?
> >
> > > I am looking for text which is technically accurate. the current text
> is not, for any sense of "obtain". What is required here is that the server