Subject: Re: [http-extensions] Refining the framing of the commitment (#157)

From: HTTP issue updates <[email-masked]>
Date: Thu, 10 Mar 2016 22:57:09 -0800

>  contacted. Effectively, this makes the choice to use a secured protocol "sticky".
>  
>  
>  ## Opportunistic Commitment
>  
> -An insecure origin can commit to providing a secured alternative by including a `commit` member in
> -the http-opportunistic well-known resource (see {{well-known}}), whose value is a number
> -representing an interval in seconds.
> +An origin can reduce the risk of attacks on opportunistically secured connections by committing to
> +provide an secured, authenticated alternative service. This is done by including the optional
> +`commit` member in the http-opportunistic well-known resource (see {{well-known}}). This feature is
> +optional due to the requirement for server authentication and the potential risk entailed (see
> +{{pinrisks}}).
> +
> +The value of the `commit` member is the duration of the commitment interval in seconds.

Saying it's a number clarifies what JSON is expected; perhaps "JSON number [ref]"

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/157/files#r55795409

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 10 Mar 2016 22:58:08 -0800

>  
>  The value of the `commit` member MUST be ignored unless the alternative service can be strongly
> -authenticated.  Minimum authentication requirements for HTTP over TLS are described in Section 2.1
> -of {{I-D.ietf-httpbis-alt-svc}} and Section 3.1 of {{RFC2818}}.  As noted in
> -{{I-D.ietf-httpbis-alt-svc}}, clients can impose other checks in addition to this minimum set.  For
> +authenticated. The same requirements that apply to `https://` resources SHOULD be applied to

I'm concerned that this is going to confuse people -- *which* same requirements?

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/157/files#r55795466

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 10 Mar 2016 22:59:51 -0800

>  instance, a client might choose to apply key pinning {{RFC7469}}.
>  
> -If a client is able to obtain a valid http-opportunistic resource (as per {{well-known}})
> -containing a `commit` member and a strongly authenticated alternative service is available, it can
> -assume that such an alternative will remain available for the indicated number of seconds past the
> -current time, less the current age of the http-opportunistic response (as defined in Section 4.2.3
> -of {{RFC7234}}). A client SHOULD NOT fall back to cleartext protocols prior to that interval
> -elapsing. Note however that relying on a commitment creates some potential operational hazards (see
> -{{pinrisks}}).
> +A client that receives a commitment and that successfully authenticates the alternative service can
> +assume that a secured alternative will remain available for the commitment interval. The commitment
> +interval starts when the commitment is received and authenticated and runs for a number of seconds
> +equal to value of the `commit` member, less the current age of the http-opportunistic response (as
> +defined in Section 4.2.3 of {{RFC7234}}. A client SHOULD avoid sending requests via cleartext

missing )

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/157/files#r55795575

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 13 Mar 2016 16:42:51 -0700

Merged #157.

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/157#event-588043398