Roman Danyliw's Yes on draft-ietf-httpbis-semantics-16: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-semantics-16: Yes

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 DISCUSS and COMMENT positions.


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



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

** Section 2.2.  Per “Additional (social) requirements are placed on
implementations …”, what’s a “social” requirement?

** Section 4.2.2.

Resources made available via the "https" scheme have no shared
identity with the "http" scheme.  They are distinct origins with
   separate namespaces.  However, an extension to HTTP that is defined
   to apply to all origins with the same host, such as the Cookie
   protocol [RFC6265], can allow information set by one service to
   impact communication with other services within a matching group of
   host domains.

It would be worth reiterating that it might be risky for extensions to treat
http + https origins on the same host uniformly.

** Section 5.1.  Convention question.  Per “Field names … ought to be
registered within the …” HTTP field name registry, I have a question about the
strength of the recommendation based on the use of the verb “ought” – is that
RECOMMENDED? SHOULD?  Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar
construct.

** Section 7.2.  Does this text allow for the possibility for both a Host and
:authority be included?

** Section 9.2.1.  In addition to example of the access logs files filling the
disk, there could be significant CPU load if the target is a script.

** Section 17.1.  The text provides helpful caution by stressing that “… the
user's local name resolution    service [is used] to determine where it can
find authoritative responses.  This means that any attack on a user's network
host table, cached names, or name resolution libraries becomes an avenue for
attack on establishing authority for "http" URIs.”  The subsequent text
highlights DNSSEC as improving authenticity.  It seems that the integrity
provided by DoT or DoH would also be relevant.

** Section 17.2

Users need to be aware that intermediaries are no more trustworthy than the
people who run them; HTTP itself cannot solve this problem.

No disagreement with the sentiment, but I would recommend not framing it in
term of the trustworthiness of the _people_ (i.e., intermediaries with poor
security or privacy practices is not necessarily due to the lack of
trustworthiness of the engineers operating the service; perhaps these services
are also run in of jurisdictions where confidence in them should be reduced).

NEW
Users need to be aware that intermediaries are no more trustworthy that the
entities that operate them and the policies governing them; HTTP itself cannot
solve this problem.

** Section 17.5.  More generically describe the attack

OLD
Failure to limit such processing can result in buffer overflows, arithmetic
overflows, or increased vulnerability to
   denial-of-service attacks.

NEW
Failure to limit such processing can result in arbitrary code execution due to
a buffer overflows or arithmetic overflows; or increased vulnerability to
denial-of-service attacks.

** Editorial

-- Section 3.5.  Should s/advance configuration choices/advanced configuration
choices/?

-- Section 4.2.2.
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.

This text goes from referring to “secured” in the first sentence to
“[acceptable] cryptographic mechanisms” in the second sentence.  To link them,
perhaps s/are secured/are cryptographically secured/

-- Section 6.5.  Typo. s/section_ are are/section_ are/

-- Section 11.1.  The text (at least when read as a .txt) isn’t showing RFC7617
or RFC7616 as references.

-- Section 14.1.1.  Typo. s/gramar/grammar/

Received on Thursday, 10 June 2021 12:30:35 UTC