Subject: Genart last call review of draft-ietf-httpbis-origin-frame-04

From: Brian Carpenter <[email-masked]>
Date: Sun, 26 Nov 2017 03:45:04 +0000

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-httpbis-origin-frame-04

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-origin-frame-04.txt
Reviewer: Brian Carpenter
Review Date: 2017-11-
IETF LC End Date: 2017-11-30
IESG Telechat date: 

Summary: Ready with (minor) issues
--------

Minor Issues:
-------------

> 2.1.  Syntax
...
> Origin: An OPTIONAL sequence of characters ... that the
> sender believes this connection is or could be authoritative for.

So, that implies that all data in the ORIGIN frame might be false.
Doesn't that deserve a bit of a health warning at the beginning of the
Security Considerations? Also, using the word "believes" of a server
is strange. How would the server acquire uncertain knowledge in the
first place, and what algorithm would decide what it "believes"?

Appendix A doesn't show any sign of a client checking whether an
Origin-Entry is real.

> 2.3.  The Origin Set
...
>  o  Host: the value sent in Server Name Indication (SNI, [RFC6066]
>     Section 3), converted to lower case

In that reference:

>> Literal IPv4 and IPv6 addresses are not permitted in "HostName".

Is that an intended or unintended restriction for the ORIGIN frame?
In any case it should probably be mentioned explicitly to avoid confusion.
(If IPv6 literals were allowed, they might be very convenient for server
load balancing. But RFC6066 excludes that.)

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Nov 2017 10:38:43 +1100

Hi Brian,

Thanks for the review. Responses below.

> On 26 Nov 2017, at 2:44 pm, Brian Carpenter <[email-masked]> wrote:
[...]
> Security Considerations?

The first paragraph of SC is already:

"""
   Clients that blindly trust the ORIGIN frame's contents will be
   vulnerable to a large number of attacks.  See Section 2.4 for mitigations.
"""

What would you suggest?

> Also, using the word "believes" of a server

This is to emphasise that ORIGIN is advisory only -- it does not constitute proof (crypto does that).

> Appendix A doesn't show any sign of a client checking whether an

As per Section 2.4, it isn't checked when the origin set is created or updated; it's checked when the value is used.

> load balancing. But RFC6066 excludes that.)

Good catch. I don't think there's cause for confusion here (the text there isn't about what can go on the wire), but there is a corner case we haven't covered (when a client that supports SNI omits it because it's an IP literal). 

My inclination there is to say that the host is the SNI value or the server IP if SNI is missing; what do people think?

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Nov 2017 11:33:27 +1100

Thanks again. Please see:
  https://github.com/httpwg/http-extensions/commit/871a80d12aa

> On 27 Nov 2017, at 1:05 pm, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Mark,
> 
> On 27/11/2017 12:38, Mark Nottingham wrote:
>> Hi Brian,
>> 
> Right. But I think it's the anthropomorphic choice of word that triggered me. If you said "that the sender asserts this connection is or could be authoritative for" I think I'd have nothing further to say, since it's clearly an assertion that needs to be checked.
> 
>> 
> OK
>> From this reviewer's peanut gallery seat, that makes sense.
> 
>   Brian
> 
>> 
>> Cheers,
>> 
>> --

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2017 03:59:31 +0000

Works for me.

   Brian