Subject: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12

From: Chris Lonvick <[email-masked]>
Date: Sun, 21 Feb 2016 14:13:45 -0600

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

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 21 Feb 2016 14:57:17 -0600

Resending to get it to all the right people.

Hi,

    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.

    For example, if an"https://"  URI has a protocol advertised that does

---

From: Barry Leiba <[email-masked]>
Date: Sun, 21 Feb 2016 13:42:48 -0800

Thanks for the review, Chris.  A point on the Latin abbreviations:

> Each use of 'e.g.' should be followed by a comma. There seem to be some that
> aren't.
...
> 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.

As it happens, I have a strong preference for avoiding "i.e." and
"e.g.", for a number of reasons.  One is that they're often not used
quite right, as you note in these two comments.  Another is that one
is often used when the other should be (that's not the case in this
document).  But the main one is that they're almost always
unnecessary, and removing them and/or rewording makes better sentences
-- "i.e." can almost always just be removed, and "e.g." can usually be
replaced with a more natural "such as", "as with", or something of
that sort.  An example of common misuse: "...as with fruit, e.g.,
apples, bananas, etc."  Euw!

> 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

Actually, this is a really good example where "e.g." isn't needed at
all (the "as is...the case" takes care of that), and where the
sentence works better this way (also correcting the non-parallel use
of "either", while we're here):

NEW
   When the protocol does not explicitly carry the scheme, as is
   usually the case for HTTP/1.1 over TLS, servers can mitigate this
   risk either by assuming that all requests have an insecure context,
   or by refraining from advertising alternative services for insecure
   schemes such as HTTP.
END

I urge the authors to make a quick run-through along with handling
other comments, and to get rid of as many of the "i.e."s and "e.g."s
as they reasonably can.

Barry

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 21 Feb 2016 22:07:40 +0000

> I urge the authors to make a quick run-through along with handling other
> comments, and to get rid of as many of the "i.e."s and "e.g."s as they
> reasonably can.

Plus-one to that!

---

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

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:
> 
> 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:
> 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. 
> 
> 
> 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. 
> 
> This should either be one unified paragraph or two paragraphs expressing different thoughts. My suggestion would be:
> 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.
> 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/