Re: Kathleen Moriarty's No Objection on draft-ietf-httpbis-http2-16: (with COMMENT)

On 20 January 2015 at 12:26, Kathleen Moriarty
<Kathleen.Moriarty.ietf@gmail.com> wrote:
> Editorial suggestion: 3.3, 2nd paragraph:
>    HTTP/2 over TLS uses the "h2" application token.  The "h2c" token
>    MUST NOT be sent by a client or selected by a server.
>
> It might be helpful to show an example using the application token so the
> differences between the upgrade token specific to h2c is readily seen
> from the use of the application token for h2.  There is a similar
> statement in 3.2 and I think this would prevent any confusion, but that
> might just be me, so ignore if you think it's clear enough.

I think that I'd rather rely on the example in RFC 7301 (ALPN) for this case.

Understanding this has not turned out to be a problem for implementers so far.

> Editorial consideration: Section 9.2
> Towards the end, would a reference to
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ be helpful?  I
> think it would and suggest towards the end as this draft is specific on
> requirements and you'd want those to stand out.

There is already a reference right up front:

The general TLS usage guidance in [TLSBCP] SHOULD be followed, with
some additional restrictions that are specific to HTTP/2.

> Editorial consideration: Section 9.2.2
> There is a conflict in the document in that this section says the list in
> Appendix A SHOULD NOT be used.  The next sentence says the list in the
> Appendix is prohibited and in Appendix A, the following text appears:
> The following cipher suites are prohibited for use in HTTP/2 over TLS.
>
> Is there a reason why the first sentence doesn't say MUST NOT?
>
> Then the following sentences says:
>   Consequently, when clients offer a cipher suite that is not
>    prohibited, they have to be prepared to use that cipher suite with
>    HTTP/2.

The "SHOULD NOT" is definitely the consensus position.  I think I
mucked up by using language that is too strong.  Would a change from
"prohibited" to "black-listed", with appropriate framing, help?

Here:
https://github.com/http2/http2-spec/pull/697/files

> Followup from last IETF meting:
> Section 9.2.2 - I'll note first that there is clear WG consensus for
> using blacklists.
> Is there a limit to what must be supported?
> I do think you'd be better off in the long run with a list of permitted
> cipher suites instead of a blacklist.  The blacklist included is lengthy
> and repeats a pattern in information security where you start out with a
> blacklist and later switch to a white list for manageability (firewalls,
> AV, etc.).  I see you have the start of a kind-of whitelist with one
> cipher suite being required (MTI):
>  To avoid this problem, deployments of HTTP/2
>    that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>    [TLS-ECDHE] with the P256 elliptic curve [FIPS186].
>
> Any cipher suite that's new (not yet blacklisted), which includes
> regional cipher suites can be supported in other words.  With the
> government focus on crypto at the moment this opens up room for
> requirements to be set country by country outside of the protocol.  Good
> luck to the vendors, I think it could be difficult in time.

We had some very strong objections to a white list.  A white list
would prevent the use of off-list suites and that would prevent all
new suites from being used, regardless of any value-judgment we might
make.

With a black list, we still have the option of not implementing the
stuff we don't want (if the UK government mandates the use of their
great new rot13 cipher, folks in the Phillipines can still use AES or
ChaCha).

Received on Tuesday, 20 January 2015 23:33:29 UTC