Roman Danyliw COMMENT draft-ietf-httpbis-semantics-16

[reschke]

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?

Editors: removed in #903 (#854 (comment))

---

• ** 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.

Editors: added text in #903

---

• ** 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.

Editors: we intentionally do not to use normative language for registration requirements.

---

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

Editors: it's syntactically possible in H2 and H3. It's up to those specs to describe what that would mean.

---

• ** 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.

Editors: #854 (comment)

---

• ** 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.

Editors: added text in #903 (see also #854 (comment))

---

• ** 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.

Editors: 5e9c304

---

• ** 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.

Editors: d466398

---

** Editorial

---

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

Editors: no, advance has the same meaning as "configuration choices made prior to request"

---

• -- 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/

Editors: "secured" is a defined term for this spec.

---

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

Editors: b211884

---

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

Editors: it does in HTML: https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-16.html#name-authentication-scheme

---

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

Editors: 521758f

[reschke]

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.

Yes. But this is the definition of "safe methods", not a discussion of all potential attack vectors of a server.

[reschke]

** 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.

Understood. Q: do we attempt an exhaustive list here, or just mention examples? If we did mention DoT and DoH, woulkd that be exhaustive?

[mnot]

do we attempt an exhaustive list here, or just mention examples? If we did mention DoT and DoH, woulkd that be exhaustive?

By nature I don't think we can be exhaustive here. If anything, I'd replace DNSSEC with DoH, as it's getting more adoption (both in implementation and deployment) on the web.

[mnot]

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

We already say that in several places, and I don't think repeating ourselves helps the document become more readable or useful.

[royfielding]

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

There are technical interop requirements for the protocol and social requirements to keep people safe on the Internet (or the Web safe from the people abusing it). This is just a short-hand version of old IETF lore, and probably isn't worth repeating in the spec.