Subject: Fwd: SECDIR review of draft-ietf-httpbis-alt-svc-12

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Feb 2016 10:43:29 +1100

FYI; we got a secdir review of alt-svc, with some editorial issues.

> Begin forwarded message:
> 
> From: Mark Nottingham <[email-masked]>
> Subject: Re: SECDIR review of draft-ietf-httpbis-alt-svc-12
> Date: 22 February 2016 at 10:42:02 AM AEDT
> To: Chris Lonvick <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
> 
> Hi Chris,
> 
> Thanks for the review. See:
>  https://github.com/httpwg/http-extensions/commit/23d3b09374c077
> 
> I eradicated the bulk of the spurious parenthesis, "e.g.," and "i.e.," :)  If folks could have a read of them I'd appreciated it, to make sure I didn't introduce any new issues.
> 
> One thing - I didn't introduce requirements in 9.3 as you suggested below, because we generally try to avoid having normative requirements in Security Considerations (believing that they should be in the spec itself, so that people don't miss them). We also try to avoid untestable requirements where possible (although we don't always reach that goal).
> 
> Cheers,
> 
> 
>> On 22 Feb 2016, at 7:57 AM, Chris Lonvick <[email-masked]> wrote:
>> 
>> Resending to get it to all the right people.
>> 
>> Hi,
>> 
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.  These comments were written primarily for the benefit of the 
>> security area directors.  Document editors and WG chairs should treat 
>> these comments just like any other last call comments.
>> 
>> Overall, the document looks pretty good. It clearly spells out its intent and the implementation. I believe it will be useful.
>> 
>> I would recommend some small edits which are more on the subjective side. Please take these as mere suggestions and use them, edit them, or ignore them as you see fit.
>> 
>> The term "safely ignore it" is used twice in the document. I would prefer a more concrete directive for each. The first time it is used is in the second paragraph of Section 4. In this case, the term should be replaced with "MAY" as that is definitive per RFC 2119 for the protocol. The second case occurs in the following paragraph:
>>   The ALTSVC frame is intended for receipt by clients; a server that
>>   receives an ALTSVC frame can safely ignore it.
>> 
>> I'd recommend changing that to:
>>   The ALTSVC frame is intended for receipt by clients. A device acting
>>   as a server MUST ignore it.
>> 
>> This advises what to do if a server receives the frame, but allows some leeway if the device is simultaneously being used as a client. 
>> 
>> 
>> In Section 9.2, there is a paragraph that starts as follows:
>>   Alternative services could be used to persist such an attack; for
>>   example, an...
>> 
>> The whole thing is a bit of a run-on sentence so I'd recommend that the semicolon be replaced with a period and a second sentence started after that.
>> 
>> Each use of 'e.g.' should be followed by a comma. There seem to be some that aren't. 
>> 
>> Section 9.3 has the following two paragraphs:
>>   For example, if an "https://"
>> URI has a protocol advertised that does
>>   not use some form of end-to-end encryption (most likely, TLS), it
>>   violates the expectations for security that the URI scheme implies.
>> 
>> 
>>   Therefore, clients cannot blindly use alternative services, but
>>   instead evaluate the option(s) presented to assure that security
>>   requirements and expectations (of specifications, implementations and
>>   end users) are met.
>> 
>> This should either be one unified paragraph or two paragraphs expressing different thoughts. My suggestion would be:
>>   For example, if an "https://"
>> URI has a protocol advertised that does
>>   not use some form of end-to-end encryption (most likely TLS), it
>>   violates the expectations for security that the URI scheme denotes.
>>   Therefore, clients MUST NOT blindly use alternative services, but
>>   instead SHOULD evaluate the option(s) presented and make a selection
>>   that assures the security requirements and expectations of policy 
>>   provided by specifications, implementations, and end user desires.
>> 
>> There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in a sentence does not require that it be within parenthesis. Stick a comma in front it it and move on. ;-) Y'all almost did that within the last paragraph of Section 9.5 but didn't get it altogether right.
>>   When the protocol does not explicitly carry the scheme (e.g., as is
>>   usually the case for HTTP/1.1 over TLS, servers can mitigate this
>>   risk by either assuming that all requests have an insecure context,
>>   or by refraining from advertising alternative services for insecure
>>   schemes (such as HTTP).
>> 
>> The first parenthetical is opened with a left parenthesis but closed with a comma. I'd suggest using commas to open and close that. The second should just be separated by a preceding comma. Best regards, Chris
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Feb 2016 18:45:36 +0100

On 2016-02-22 00:43, Mark Nottingham wrote:
>> ...

I'm not totally OK with all the edits, for instance we now have 
normative language in notes, and a lowercase "required" has sneaked in.

Will review tomorrow.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Feb 2016 13:44:25 +0100

On 2016-02-22 18:45, Julian Reschke wrote:
>>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
>>> <[email-masked]>, [email-masked]
>>>
>>> Hi Chris,
>>>

OK, here we go. Below are the changes that IMHO need to be reviewed as 
they affect normative language:

> Section 2., paragraph 11:
> OLD:
>
>     Alt-Svc MAY occur in any HTTP response message, regardless of the
>     status code.  Note that recipients of Alt-Svc are free to ignore the
>     header field (and indeed need to in some situations; see Sections 2.1
>     and 6).
>
> NEW:
>
>     Alt-Svc MAY occur in any HTTP response message, regardless of the
>     status code.  Note that recipients of Alt-Svc MAY ignore the header
>     field (and are required to in some situations; see Sections 2.1 and
>     6).

This should be reverted; the actual requirements are in Sections 2.1 and 
6, and we should not have them in multiple places.

> Section 4., paragraph 2:
> OLD:
>
>     The ALTSVC frame is a non-critical extension to HTTP/2.  Endpoints
>     that do not support this frame can safely ignore it.
>
> NEW:
>
>     The ALTSVC frame is a non-critical extension to HTTP/2.  Endpoints
>     that do not support this frame MAY ignore it.

This is IMHO misleading as it is true for any unknown frame. It just 
follows from 
<http://greenbytes.de/tech/webdav/rfc7540.html#rfc.section.4.1>:

"Implementations MUST ignore and discard any frame that has a type that 
is unknown."

> Section 4., paragraph 13:
> OLD:
>
> NEW:

I'm ok with this one (but wanted to highlight the new normative 
requirement).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 26 Feb 2016 08:30:22 +1100

> On 25 Feb 2016, at 11:44 PM, Julian Reschke <[email-masked]> wrote:
> 
> OK, here we go. Below are the changes that IMHO need to be reviewed as they affect normative language:
> 
> 
> This should be reverted; the actual requirements are in Sections 2.1 and 6, and we should not have them in multiple places.

Agreed.

> This is IMHO misleading as it is true for any unknown frame. It just follows from <http://greenbytes.de/tech/webdav/rfc7540.html#rfc.section.4.1>:
> 
> "Implementations MUST ignore and discard any frame that has a type that is unknown."

Would adding "as per [RFC7540], Section 4.1" help?

> I'm ok with this one (but wanted to highlight the new normative requirement).
> 
> Best regards, Julian
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Feb 2016 22:38:56 +0100

>> This should be reverted; the actual requirements are in Sections 2.1 and 6, and we should not have them in multiple places.

200.

> Would adding "as per [RFC7540], Section 4.1" help?

"Endpoints that do not support this frame *will* ignore it (as per thee 
extensibility rules defined in Section 4.1 of [RFC7540])."

?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 26 Feb 2016 10:59:36 +1100

> On 26 Feb 2016, at 8:38 AM, Julian Reschke <[email-masked]> wrote:
> 
> "Endpoints that do not support this frame *will* ignore it (as per thee extensibility rules defined in Section 4.1 of [RFC7540])."

WFM.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Feb 2016 11:02:19 +1100

On 26 February 2016 at 08:38, Julian Reschke <[email-masked]> wrote:
> thee

and to thine also

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 26 Feb 2016 11:45:39 +1100

https://github.com/httpwg/http-extensions/commit/5f22e10b0c82

Note that I changed "are free to" to "can" in the first one (as that phrase was the original source of the issue).

Cheers,