- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 16 Dec 2014 10:04:41 +0100
- To: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Martin,
below some unstructured feedback...
Best regards, Julian
1. Introduction
...
Currently, "https" URIs require acquiring and configuring a valid
certificate, which means that some deployments find supporting TLS
difficult. Therefore, this document describes a usage model whereby
sites can serve "http" URIs over TLS without being required to
support strong server authentication.
"Currently"?
1.1. Goals and Non-Goals
A secondary goal is to limit the potential for active attacks. It is
not intended to offer the same level of protection as afforded to
"https" URIs, but instead to increase the likelihood that an active
attack can be detected.
This repeats a paragraph from Section 1.
A final (but significant) goal is to provide for ease of
implementation, deployment and operation. This mechanism should have
a minimal impact upon performance, and should not require extensive
administrative effort to configure.
Please void lowercase BCP14 terms.
2. Using HTTP URIs over TLS
...
A client that places the importance of protection against passive
attacks over performance might choose to withhold requests until an
encrypted connection is available. However, if such a connection
cannot be successfully established, the client MAY resume its use of
the cleartext connection.
As the first sentence doesn't have a BCP14 keyword, the second problem
shouldn't either.
A client can also explicitly probe for an alternative service
advertisement by sending a request that bears little or no sensitive
information, such as one with the OPTIONS method. Likewise, clients
with existing alternative services information could make such a
request before they expire, in order minimize the delays that might
be incurred.
Q: How is OPTIONS better than HEAD?
3. Server Authentication
...
When connecting to an alternative service for an "http" URI, clients
are not required to perform the server authentication procedure
described in Section 3.1 of [RFC2818]. The server certificate, if
one is proffered by the alternative service, is not necessarily
checked for validity, expiration, issuance by a trusted certificate
authority or matched against the name in the URI. Therefore, the
alternative service MAY provide any certificate, or even select TLS
cipher suites that do not include authentication.
s/MAY/can/ methinks.
4. Interaction with "https" URIs
When using alternative services, both "http" and "https" URIs might
use the same connection, because HTTP/2 permits requests for multiple
origins on the same connection.
s/"http" and "https" URIs/request for resources identified by..../
...
5. Requiring Use of TLS
...
The mechanism described in this specification is trival to mount an
active attack against, for two reasons:
s/trival/trivial/
o A client that doesn't perform authentication an easy victim of
server impersonation, through man-in-the-middle attacks.
s/an easy/is an easy/
o A client that is willing to use cleartext to resolve the resource
will do so if access to any TLS-enabled alternative services is
blocked at the network layer.
maybe s/cleartext/HTTP over cleartext/
...
When an alternative service is able to commit to providing service
for a particular origin over TLS for a bounded period of time,
clients can choose to rely upon its avilability, failing when it
cannot be contacted. Effectively, this makes the choice to use a
secured protocol "sticky" in the client.
s/avilability/availability/
5.1. The HTTP-TLS Header Field
...
HTTP-TLS = 1#parameter
Need to cite ABNF for parameter and HTTP/1.1 #list rule.
...
GET /index.html HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: 600
??? Broken Cache-Control header field...
Age: 30
Date: Thu, 1 May 2014 16:20:09 GMT
HTTP-TLS: ma=3600
This header field creates a commitment from the origin [RFC6454] of
the associated resource (in the example, "http://example.com"). For
the duration of the commitment, clients SHOULD strongly authenticate
the server for all subsequent requests made to that origin, though
this creates some risks for clients Section 5.2.
s/Section 5.2/(see Section 5.2)/
Authentication for HTTP over TLS is described in Section 3.1 of
[RFC2818], noting the additional requirements in
[I-D.ietf-httpbis-alt-svc]. The header field MUST be ignored if
The alt-svc citation should be more specific; is this about SNI?
...
The commitment made by the "HTTP-TLS" header field applies only to
the origin of the resource that generates the "HTTP-TLS" header
field. Requests for an origin that has a persisted, unexpired value
for "HTTP-TLS" MUST fail if they cannot be made over an authenticated
TLS connection.
Maybe these should be two paragraphs.
Note that the commitment is not bound to a particular alternative
service. Clients SHOULD use alternative services that they become
aware of. However, clients MUST NOT use an unauthenticated
alternative service for an origin with this commitment. Where there
is an active commitment, clients MAY instead ignore advertisements
for unsecured alternatives services.
Aren't alt-svc advertisements optional anyway?
6.4. Confusion Regarding Request Scheme
...
HTTP/1.1 MUST NOT be sent over HTTP/1.1 or earlier versions of the
protocol. Opportunistically secured HTTP requests MUST include an
explicit scheme identifier.
Doesn't compute.
Received on Tuesday, 16 December 2014 09:47:14 UTC