Subject: -encryption draft -01

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Dec 2014 16:44:37 -0800

I've just pushed out a small revision to this based on the discussion
we had at the last meeting.  The changes are smaller than they might
appear.

 - Prohibit the use of this over HTTP/1.1
 - Tighten the language around the interaction with alternative services
 - Make the pinning on the "HTTP-TLS" header field a SHOULD, not a MUST

I think that we still need:

 - A better header field name
 - Some better language in alt-svc regarding its interaction with this
doc; that is, to avoid the case where an implementation of alt-svc
that is ignorant of this doc assumes that the server will be
authenticated (which is a non-fatal, but probably annoying, failure
mode)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Dec 2014 10:04:41 +0100

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Dec 2014 09:46:58 -0800

Feedback, structured or not, is always welcome.

I didn't realize just how riddled this was with little bugs.

> Q: How is OPTIONS better than HEAD?

I believe that either is fine.  This is a f'rexample only.  I think
that we had a discussion where (and I'm going to rely on bad memory)
Roy suggested OPTIONS over HEAD.  OPTIONS * allows a client to learn
things without perhaps revealing what resource it might be interested
in.

>    explicit scheme identifier.

Whoa, I was in a hurry, but I didn't realize it was that bad.  That's
awful.  Here's what the next version will say.

"HTTP/1.1 MUST NOT be used for opportunistically secured requests."

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Dec 2014 18:56:46 +0100

> things without perhaps revealing what resource it might be interested

I don't think that doing a request for "/" will reveal more than a 
request for "*".

Anyway, I'd like to avoid anything that might get people to think that 
"OPTIONS *" is anything but a bad design mistake. In particular I don't 
want any new specs to rely on it, when it's known to be hard to 
implement (as the asterisk form doesn't map to a proper URI).

> "HTTP/1.1 MUST NOT be used for opportunistically secured requests."

OK, that parses now :-)

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Dec 2014 10:32:40 -0800

On 16 December 2014 at 09:56, Julian Reschke <[email-masked]> wrote:
> "OPTIONS *" is anything but a bad design mistake. In particular I don't want
> any new specs to rely on it, when it's known to be hard to implement (as the
> asterisk form doesn't map to a proper URI).

I agree.  That's why I didn't mention the asterisk form at all.  And
you are right that HEAD / is not going to reveal anything of note.  I
can say HEAD or OPTIONS, any safe method.  Maybe the best way to
express a preference here is to generate a pull request :)

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 16 Dec 2014 20:58:19 +0100 (CET)

On Tue, 16 Dec 2014, Martin Thomson wrote:

> I agree.  That's why I didn't mention the asterisk form at all.  And you are 
> right that HEAD / is not going to reveal anything of note.  I can say HEAD 
> or OPTIONS, any safe method.  Maybe the best way to express a preference 
> here is to generate a pull request :)

I'd prefer HEAD as well for the reasons stated by Julian.

-- 

  / daniel.haxx.se

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Dec 2014 13:31:40 -0800

On Dec 16, 2014, at 9:56 AM, Julian Reschke wrote:
> I don't think that doing a request for "/" will reveal more than a request for "*".
> 
> Anyway, I'd like to avoid anything that might get people to think that "OPTIONS *" is anything but a bad design mistake. In particular I don't want any new specs to rely on it, when it's known to be hard to implement (as the asterisk form doesn't map to a proper URI).

It isn't hard to implement.  Please stop with the FUD.  OPTIONS is
preferred because it does not cause the server to do a retrieval
(HEAD is usually implemented as an internal retrieval that gets
truncated after the header fields, so it has almost as much cost on
the backend as a GET).

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Dec 2014 22:36:16 +0100

> truncated after the header fields, so it has almost as much cost on

"OPTIONS uri" is fine, "OPTIONS *" is a problem...

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Dec 2014 13:48:27 -0800

> "OPTIONS uri" is fine, "OPTIONS *" is a problem...

No, it isn't.  I have implemented it.  Yes, it is a special case,
but that's exactly why it was created -- to not look like a normal
request, not increment hit counts, not be blindly forwarded, and
not cause potentially expensive processing on the server.

OPTIONS should be used whenever a NO-OP style of request is desired.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Dec 2014 22:56:59 +0100

> OPTIONS should be used whenever a NO-OP style of request is desired.

The problem with "OPTIONS *" is that id doesn't work in many frameworks. 
Thus it's a bad idea to *require* it's use anywhere.

Is there a particular thing in this spec where "OPTIONS /" is worse than 
"OPTIONS *"?

Best regards, Julian