Subject: [Jmap] Eric Rescorla's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Feb 2019 16:17:33 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-jmap-core-14: Discuss

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

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

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4155

I believe I have found a security issue, noted below. In addition, I
have noted a potential interop issue.

DETAIL
S 2.
>            "urn:ietf:params:jmap:contacts", while the second account would
>            just have the last of these.  Attempts to use the methods
>            defined in a specification with one of the accounts that does
>            not contain those data types are rejected with an
>            _accountNotSupportedByMethod_ error (see section 3.5.2: method-
>            level errors).

What happens if this changes after the user has logged in. So, for
instance, I log in and am told that account X has contacts, but later
calendars get added. Do requests have to fail?

S 7.2.2.
>      o  *pushSubscriptionId*: "String" The id of the push subscription
>         that was created.
>   
>      o  *verificationCode*: "String" The verification code to add to the
>         push subscription.  This MUST contain sufficient entropy to avoid
>         the client being able to brute force guess the code.

This doesn't actually guarantee permission. Consider the case where
the client provides a push URL for some sort of open server upload
endpoint. The client could then read the verification code off that
endpoint and confirm the push subscription. Off the top of my head,
requiring the push endpoint to respond in-band with a function of the
code would be better.

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

S 1.2.
>      the "URL and Filename safe" Base 64 Alphabet, as defined in section 5
>      of [RFC4648].  This is the ASCII alphanumeric characters ("A-Za-
>      z0-9"), hyphen ("-"), and underscore ("_").
>   
>      These characters are safe to use in almost any context (e.g.,
>      filesystems, URIs, IMAP atoms).  For maximum safety, servers should

SHOULD?

S 1.7.
>   
>   1.7.  The JMAP API model
>   
>      JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download
>      resources.  Implementations MUST support HTTP/1.1, and MAY support
>      later versions.  All HTTP requests MUST use [RFC8446] TLS (HTTPS)

You need to cite 2818 here too.

S 1.7.
>   
>   1.7.  The JMAP API model
>   
>      JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download
>      resources.  Implementations MUST support HTTP/1.1, and MAY support
>      later versions.  All HTTP requests MUST use [RFC8446] TLS (HTTPS)

At this point, do you think it should be SHOULD for H2

S 1.7.
>      and caching are assumed.
>   
>      All HTTP requests MUST be authenticated.  Servers MUST conform with
>      the [RFC7235] HTTP Authentication framework to reject requests that
>      fail authentication and inform the client of available authentication
>      schemes.

This seems pretty restrictive. I read it as forbidding TLS client auth
and/or PAKEs.

S 2.
>            something like "urn:ietf:params:jmap:mail",
>            "urn:ietf:params:jmap:calendars",
>            "urn:ietf:params:jmap:contacts", while the second account would
>            just have the last of these.  Attempts to use the methods
>            defined in a specification with one of the accounts that does
>            not contain those data types are rejected with an

Is this a MUST-level statement or something else?

S 2.
>      o  *downloadUrl*: "String" The URL endpoint to use when downloading
>         files, in [RFC6570] URI Template (level 1) format.  The URL MUST
>         contain variables called "accountId", "blobId", "type" and "name".
>         The use of these variables is described in section 6.2.  Due to
>         potential encoding issues with slashes in content types, it is
>         recommended to put the "type" variable in the query section of the

Should this be RECOMMENDED?

S 3.2.
>   
>         3.  A "String" *client id*: an arbitrary string from the client to
>             be echoed back with the responses emitted by that method call
>             (a method may return 1 or more responses, as it may make
>             implicit calls to other methods; all responses initiated by
>             this method call get the same client id in the response).

Do all the responses have to come back in the same package, so that I
know when I have received the last one?

S 3.2.
>         different servers.  For example it could send the first two method
>         calls to server A, then the third to server B, before sending the
>         fourth to server A again.  By passing the createdIds of the
>         previous response to the next request, it can ensure all of these
>         still resolve.  See section 5.8 for further discussion of proxy
>         considerations.

This is a bit hard to parse and would be improved by an example.

S 3.5.2.
>      and, unless otherwise specified, further processing MUST NOT happen
>      within that method call.
>   
>      Any further method calls in the request MUST then be processed as
>      normal.  Errors at the method level MUST NOT generate an HTTP-level
>      error.

So, what do I do if I want to have method 1 execute and then method 2
execute only if method 1 succeeded. E.g., copy an object and then
delete the original? Do two requests? it looks like maybe I can use
back-references for this, but will that always work?

S 5.4.
>      to copy them using the _Foo/copy_ method, then once the copy has
>      succeeded, delete the original.  The _onSuccessDestroyOriginal_
>      argument allows you to try to do this in one method call, however
>      note that the two different actions are not atomic, and so it is
>      possible for the copy to succeed but the original not to be destroyed
>      for some reason.

Can the other direction happen?

S 8.1.
>   8.1.  Transport confidentiality
>   
>      All HTTP requests MUST use [RFC8446] TLS (https) transport to ensure
>      the confidentiality and integrity of data sent and received via JMAP.
>      Clients MUST validate TLS certificate chains to protect against man-
>      in-the-middle attacks.

You should cite 7525. Also, you need to specify which versions are
acceptbale.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Feb 2019 12:55:52 -0500

> >      filesystems, URIs, IMAP atoms).  For maximum safety, servers should

I think so, as it speaks to a choice related to interoperability.

> At this point, do you think it should be SHOULD for H2

Yes.  "Implementations MUST support HTTP/1.1, SHOULD support HTTP/2,
and MAY support later versions.

And this will come up again when QUIC is ready.

> Is this a MUST-level statement or something else?

It's a style choice in writing out a protocol.  There are times, I
think, when you want to use MUST to highlight that there are multiple
ways one might handle something, and this is the one you have to use.
Here, it's just saying, "This is how the protocol works."  If you
don't do this, it's not this protocol.  I don't think it's necessary
to use "MUST" here.

That said, of course (1) it doesn't hurt to say MUST and (2) we're
inconsistent, in general, with when we say, "this is what happens,"
and when, "this is what you MUST do."

Barry

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 18 Feb 2019 22:25:09 -0500

> calendars get added. Do requests have to fail?

Requests as a whole would not fail, no. In the case of just now having access to calendars for account X, methods operating on contacts would behave exactly as before. However, the `sessionState` property of the API responses will change so the client will know it needs to refetch the session information (and thus discover it now has more access). Of course in the inverse case, say if you used to have access to contacts and calendars in account X and now only have access to contacts, then calling a calendar method for account X would then return an `accountNotSupportedByMethod` error.

> requiring the push endpoint to respond in-band with a function of the

This would kill interoperability. The current specification is designed to work with a push server that supports RFC8030 <https://tools.ietf.org/html/rfc8030>, but doesn't necessarily know anything about the JMAP server (so cannot do custom processing or in-band replies). So in a browser, you should be able to use Web Push <https://developer.mozilla.org/en-US/docs/Web/API/Push_API> to get an endpoint and encryption key, then register this with the JMAP server. 

If you believe this is a significant security issue, could you suggest any way of mitigating this while still maintaining compatibility with existing push servers (as supported by Firefox, Chrome etc.)?

Yes, will change.

> You need to cite 2818 here too.

OK. I've changed this to:

*All HTTP requests MUST use HTTPS (RFC2818 HTTP over TLS) with TLS 1.2 (RFC5246) or later, following the recommendations in RFC7525. Servers SHOULD support TLS 1.3 (RFC8446) or later.*

> At this point, do you think it should be SHOULD for H2

Sure, I have adopted Barry's suggested wording.

> This seems pretty restrictive. I read it as forbidding TLS client auth

Sure. I have changed the MUST to a MAY. Is that sufficient? Enumerating all "acceptable" authentication schemes would be too limiting, but not mentioning it at all seems likely to hamper interoperability.

> Is this a MUST-level statement or something else?

As Barry said, this is just describing how the protocol works. Since the definition is elsewhere (referenced just below where you cut off the quote), I thought this a better stylistic choice here.

> Should this be RECOMMENDED?

Yes, will fix.

> know when I have received the last one?

Yes. This whole section, as described above in 3.1, is describing the format of the body of an HTTP request and, the format of the response if that request completes successfully.

> back-references for this, but will that always work?

To cover all cases, you may need to do two HTTP requests, yes. In some situations you may be able to use back references with the ifInState <https://jmap.io/spec-core.html#/set> argument. The copy then delete original is handled specially, as you saw later.

> Can the other direction happen?

No. Because the Foo/copy is executed first and succeeds or fails. If it fails, the Foo/set call to destroy the original never happens, so you cannot have the copy not succeed but the original still destroyed.

> You should cite 7525. Also, you need to specify which versions are

I have amended this to match the earlier section requiring TLS:

*To ensure the confidentiality and integrity of data sent and received via JMAP, all HTTP requests MUST use HTTPS ([@!RFC2818] HTTP over TLS) with TLS 1.2 ([RFC5246]) or later, following the recommendations in [@!RFC7525]. Servers SHOULD support TLS 1.3 ([@!RFC8446]) or later.*

Does that sound reasonable? (We could make TLS 1.3 or later be required, although RFC7525 explicitly says its recommendations may not be valid for versions of TLS after 1.2…)

Thanks for all the detailed feedback.
Neil.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Feb 2019 20:41:36 -0800

On Mon, Feb 18, 2019 at 7:27 PM Neil Jenkins <[email-masked]> wrote:

> Requests as a whole would not fail, no. In the case of just now having
> access to calendars for account X, methods operating on contacts would
> behave exactly as before. However, the sessionState property of the API
> responses will change so the client will know it needs to refetch the
> session information (and thus discover it now has more access). Of course
> in the inverse case, say if you used to have access to contacts and
> calendars in account X and now only have access to contacts, then calling a
> calendar method for account X would then return an
> accountNotSupportedByMethod error.
>

OK. Perhaps you could clarify this in the text.

S 7.2.2.
> This would kill interoperability. The current specification is designed to
> work with a push server that supports RFC8030
> <https://tools.ietf.org/html/rfc8030>, but doesn't necessarily know
> anything about the JMAP server (so cannot do custom processing or in-band
> replies). So in a browser, you should be able to use Web Push
> <https://developer.mozilla.org/en-US/docs/Web/API/Push_API> to get an
> endpoint and encryption key, then register this with the JMAP server.
>
> If you believe this is a significant security issue, could you suggest any
> way of mitigating this while still maintaining compatibility with existing
> push servers (as supported by Firefox, Chrome etc.)?
>

I'm not sure if it's a significant security issue. My understanding is that
RFC 8030 endpoints don't normally involve a round-trip check. CCing Martin
Thomson for his thougths.

> *All HTTP requests MUST use HTTPS (RFC2818 HTTP over TLS) with TLS 1.2
> (RFC5246) or later, following the recommendations in RFC7525. Servers
> SHOULD support TLS 1.3 (RFC8446) or later.*
>

LGTM

> Sure. I have changed the MUST to a MAY. Is that sufficient? Enumerating
> all "acceptable" authentication schemes would be too limiting, but not
> mentioning it at all seems likely to hamper interoperability.
>

I'm not sure quite what you're trying to achieve. I think requiring
authentication is good, but I'm not sure why you need to require any
specific type of authentication.

> As Barry said, this is just describing how the protocol works. Since the
> definition is elsewhere (referenced just below where you cut off the
> quote), I thought this a better stylistic choice here.
>

OK.

S 3.2.
> Yes. This whole section, as described above in 3.1, is describing the
> format of the body of an HTTP request and, the format of the response if
> that request completes successfully.
>

OK.  Saying that somewhere would have helped me.

S 5.4.
> No. Because the Foo/copy is executed first and succeeds or fails. If it
> fails, the Foo/set call to destroy the original never happens, so you
> cannot have the copy not succeed but the original still destroyed.
>

OK.

> *To ensure the confidentiality and integrity of data sent and received via
> JMAP, all HTTP requests MUST use HTTPS ([@!RFC2818] HTTP over TLS) with TLS
> 1.2 ([RFC5246]) or later, following the recommendations in [@!RFC7525].
> Servers SHOULD support TLS 1.3 ([@!RFC8446]) or later.*
>
> Does that sound reasonable? (We could make TLS 1.3 or later be required,
> although RFC7525 explicitly says its recommendations may not be valid for
> versions of TLS after 1.2…)
>

Yep, this LGTM.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Feb 2019 22:38:21 -0800

On Mon, Feb 18, 2019 at 8:42 PM Eric Rescorla <[email-masked]> wrote:
>> This would kill interoperability. The current specification is designed to work with a push server that supports RFC8030, but doesn't necessarily know anything about the JMAP server (so cannot do custom processing or in-band replies). So in a browser, you should be able to use Web Push to get an endpoint and encryption key, then register this with the JMAP server.
>>
> I'm not sure if it's a significant security issue. My understanding is that RFC 8030 endpoints don't normally involve a round-trip check. CCing Martin Thomson for his thougths.

This uses the design in RFC 8291 as I understand it.  But the
verification code is something on top of that.  The intent is to
perform a routeability check on the subscription.  In that way it is
like the QUIC PATH_CHALLENGE, verifying that the client can receive
messages.  This opens the client to collusion: one client forwards
messages for another, but the effect is that the JMAP server will send
updates to the wrong client.  The client that should be receiving
those messages can be duped into doing that if they can be convinced
to set a subscription URI (and keys) that are controlled by an
attacker and the attacker has the subscription URI (and keys) for the
client.  The attacker can forward the string along and have the client
verify its string.

This doesn't have the same constraints as ACME, but the challenge
there is not dissimilar.  The server sets a large random value (ACME
has 128 bits of entropy, similar to this, though this has no hard
lower bound, which might be worth correcting).  The supplicant echoes
that value, and includes the identity adjacent to that value.  The
added identity prevents the simple hack of echoing a value.  This
system is analogous, assuming that the client is authenticated when it
makes the PushSubscription/set request.

Now, ACME is completely open to on-path attacks, so maybe you could
decide that you wanted to care about that.  You could include the
identity of the push subscription in the message in a way that can be
authenticated by the client so that it could verify that the message
was sent to it.  For instance, you could add a key when creating the
subscription and include a MAC of the token and subscription URL in
the message.  That might be too much complexity given the nature of
the request (and it's a fairly narrowly targeted fix).

The problem Ekr cites here is a different one, where the client
doesn't care who receives its messages.  I think that suffers from
problems of alignment of incentives (the client could also just
broadcast all of its messages as it receives them), so I'm less
concerned about that.  I'm not sure that I even care about the
forwarding thing enough to recommend any fix at all.

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 19 Feb 2019 22:40:41 -0500

On Tue, 19 Feb 2019, at 17:38, Martin Thomson wrote:
> verification code is something on top of that.

Yes, the verification code was added at the request of the secdir review.

> The intent is to perform a routeability check on the subscription.

This was a secondary intent, however the primary intent was to prevent a JMAP server from being used as a DDOS amplification vector (a client registers a URL for a victim server rather than a push service, and that server responds with some kind of success code to the HTTP requests made for pushes; the client may now be able to get the JMAP server to make many requests to the victim server).

> In that way it is like the QUIC PATH_CHALLENGE, verifying that the client can receive messages. This opens the client to collusion: one client forwards messages for another, but the effect is that the JMAP server will send updates to the wrong client.

This is an entirely orthogonal issue.

> The client that should be receiving those messages can be duped into doing that if they can be convinced
> to set a subscription URI (and keys) that are controlled by an attacker and the attacker has the subscription URI (and keys) for the client. The attacker can forward the string along and have the client verify its string.

Well, sure. But this seems a slightly far-fetched scenario. And even then, the push data in JMAP contains very little (just tells you that the state of a collection of objects for a particular data type has changed; the actual changes are fetched via standard API requests).

> forwarding thing enough to recommend any fix at all.

So, can we conclude that the current spec is fine here then; no changes are required? :)

Neil.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Feb 2019 20:39:00 -0800

On Tue, Feb 19, 2019 at 7:41 PM Neil Jenkins <[email-masked]> wrote:

> This was a secondary intent, however the primary intent was to prevent a
> JMAP server from being used as a DDOS amplification vector (a client
> registers a URL for a victim server rather than a push service, and that
> server responds with some kind of success code to the HTTP requests made
> for pushes; the client may now be able to get the JMAP server to make many
> requests to the victim server).
>
> In that way it is like the QUIC PATH_CHALLENGE, verifying that the client
> can receive messages.  This opens the client to collusion: one client
> forwards messages for another, but the effect is that the JMAP server will
> send updates to the wrong client.
>
>
> to set a subscription URI (and keys) that are controlled by an attacker
> and the attacker has the subscription URI (and keys) for the client.  The
> attacker can forward the string along and have the client verify its string.
>
>
> Well, sure. But this seems a slightly far-fetched scenario. And even then,
> the push data in JMAP contains very little (just tells you that the state
> of a collection of objects for a particular data type has changed; the
> actual changes are fetched via standard API requests).
>

I'm not sure of that, no. To the extent to which this mechanism is supposed
to prevent DoS, it's not clear to me that it does that.

-Ekr

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 20 Feb 2019 01:36:44 -0500

On Wed, 20 Feb 2019, at 15:39, Eric Rescorla wrote:
> I'm not sure of that, no. To the extent to which this mechanism is supposed to prevent DoS, it's not clear to me that it does that.

This doesn't seem to be a JMAP-specific problem to me though. Anyone integrating with web push (i.e. RFC8030) is going to get an arbitrary URL from the browser registered with them. They will need to make requests to this URL in order to push data back to the client. A malicious user could always replace the URL; so what are you meant to do? The verification step we've added vastly reduces the potential targets for this attack. I think the remaining risk is minimal and acceptable. There is no guidance on this as far as I can see in RFC8030 (which only discusses denial-of-service possibilities against the user agent) or in the W3 Push API <https://www.w3.org/TR/push-api/> spec.

Neil.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Feb 2019 05:42:10 -0800

On Tue, Feb 19, 2019 at 10:36 PM Neil Jenkins <[email-masked]>
wrote:

> I'm not sure of that, no. To the extent to which this mechanism is
> supposed to prevent DoS, it's not clear to me that it does that.
>
>
> This doesn't seem to be a JMAP-specific problem to me though. Anyone
> integrating with web push (i.e. RFC8030) is going to get an arbitrary URL
> from the browser registered with them.They will need to make requests to
> this URL in order to push data back to the client. A malicious user could
> always replace the URL; so what are you meant to do? The verification step
> we've added vastly reduces the potential targets for this attack. I think
> the remaining risk is minimal and acceptable. There is no guidance on this
> as far as I can see in RFC8030 (which only discusses denial-of-service
> possibilities against the user agent) or in the W3 Push API
> <https://www.w3.org/TR/push-api/> spec.
>

It's probably worth starting by trying to scope the risk, which is that you
have a system in which the attacker configures an alleged push URL that is
actually a third party victim server and the result is that the mail server
now spams that server with notifications about message changes to the
user's mailbox. Do we agree on that?

There are two primary mitigation mechanisms one might have against this
kind of attack:

1. Have a whitelist of known push servers
2. Have a mechanism where the recipient proves that this URL is actually
under their control in some positive sense.

My sense is that in WebPush (whatever RFC 8030 says) there was an
expectation that you would know which were valid push servers or not (i.e.,
the first design). This would still leave the residual risk of pushing to
someone else's account, which might or might not be a big deal but
presumably push servers can deal with. The design in this document is of
the second type, but what you're actually proving is not *control* of the
endpoint but rather that you can access the data sent to it, which is a
slightly different property. You'll note that ACME requires control, not
this. I agree that this reduces the risk, but that doesn't mean that
there's not one.

Given the desire to have this work with existing 8030 endpoints, I think
this is something we can live with, as long as you document it properly in
Security Considerations.

-Ekr

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 20 Feb 2019 19:57:32 -0500

On Thu, 21 Feb 2019, at 00:42, Eric Rescorla wrote:
> It's probably worth starting by trying to scope the risk, which is that you have a system in which the attacker configures an alleged push URL that is actually a third party victim server and the result is that the mail server now spams that server with notifications about message changes to the user's mailbox. Do we agree on that?

Yes.

> Given the desire to have this work with existing 8030 endpoints, I think this is something we can live with, as long as you document it properly in Security Considerations.

That sounds reasonable to me. I have added the following paragraph to the relevant section of the security considerations:

*The verification code does not guarantee the URL is a valid push server, only that the client is able to access the data submitted to it. While the verification step significantly reduces the set of potential targets, there is still a risk that the server is unrelated to the client and being targeted for a denial of service attack.*

Is this sufficient for you?

Neil.

---

From: "Chris Newman" <[email-masked]>
Date: Wed, 20 Feb 2019 18:50:18 -0800

> And this will come up again when QUIC is ready.

I'm opposed to saying "SHOULD support HTTP/2" in this specification.

There are likely two classes of JMAP implementations:

1. Implementations that use an HTTP library of choice, likely in an OS 
or language runtime. Nothing this specification says is going to change 
whether that OS or language runtime HTTP library supports HTTP/2. So for 
these implementations, the only thing this accomplishes is forcing a 
diligent implementor to spend a lot of time on extra tests, which might 
be a barrier to deployment of JMAP (since it will take longer to finish 
those tests).

2. thin client JMAP applications that use a minimal stripped down 
version of HTTP for applications like IoT-mail-submission. Implementing 
more than one version of HTTP is contrary to thin-client goals, so 
implementers will either ignore the SHOULD or ignore JMAP altogether and 
use a protocol that can be implemented without the need for HTTP/2 code 
(like SMTP submission or one of the many existing ad-hoc HTTP submission 
JSON APIs).

So a "SHOULD support HTTP/2" is likely to accomplish nothing useful with 
respect to HTTP/2 deployment and may deter deployment of JMAP. Like it 
or not, JMAP is competing with existing deployed protocols. I consider 
JMAP technically better than the deployed alternatives (IMAP, SMTP 
submission) so I'd like to see it gradually replace them. As a result, I 
generally oppose requirements and recommendations that create barriers 
to JMAP deployment.

As a compromise, I could live with: servers are encouraged to support 
HTTP/2.

		- Chris

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Feb 2019 20:35:44 -0800

Yes, I can live with this.

-Ekr

On Wed, Feb 20, 2019 at 4:58 PM Neil Jenkins <[email-masked]> wrote:

> It's probably worth starting by trying to scope the risk, which is that
> you have a system in which the attacker configures an alleged push URL that
> is actually a third party victim server and the result is that the mail
> server now spams that server with notifications about message changes to
> the user's mailbox. Do we agree on that?
>
>
> Yes.
>
> That sounds reasonable to me. I have added the following paragraph to the
> relevant section of the security considerations:
>
> *The verification code does not guarantee the URL is a valid push server,
> only that the client is able to access the data submitted to it. While the
> verification step significantly reduces the set of potential targets, there
> is still a risk that the server is unrelated to the client and being
> targeted for a denial of service attack.*
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Feb 2019 09:24:46 -0800

The testing issue that Chris brings up is a notable one.  On the other point:

> implementers will either ignore the SHOULD

See, I would say that that's not *ignoring* the SHOULD, but, rather,
doing exactly what the SHOULD is there for: considering it, being
aware of the issues, and having a good reason not to implement it.

On the other hand, I can't really say that it's an interoperability or
safety/security issue.  We're saying "SHOULD" because we want to
encourage deployment of HTTP/2.  So I'm good with Chris's suggestion
of changing it to "encouraged", or perhaps even "strongly encouraged".

Barry

---

From: "Neil Jenkins" <[email-masked]>
Date: Sun, 24 Feb 2019 23:36:59 -0500

> of changing it to "encouraged", or perhaps even "strongly encouraged".

I note the latest draft of "Building Protocols with HTTP" from the HTTP Bis working group, says <https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08#section-4.1>:

   Applications using HTTP SHOULD NOT specify a minimum version of HTTP
   to be used; because it is a hop-by-hop protocol, a HTTP connection
   can be handled by implementations that are not controlled by the
   application; for example, proxies, CDNs, firewalls and so on.
   Requiring a particular version of HTTP makes it difficult to use in
   these situations, and harms interoperability for little reason (since
   HTTP's semantics are stable between protocol versions).

In light of this, I'm inclined to remove the sentence altogether?

Neil.