RE: Concluding discussion on #612 (9.2.2)

Our feedback on the proposals listed below is that we cannot live with 9.2.2 being in the HTTP/2 spec and favor Greg's proposal of "move 9.2.2 requirements to a document that applies to h1 and h2."  Implementers who enforce section 9.2.2 will require a new platform in the TLS layer to integrate HTTP/2 specific decision making. There have been responses in the list from implementers who implement on top of general purpose TLS platforms who may not be able to enforce this section.  Ironically, if this section did not exist or was written as a SHOULD, HTTP/2 would already negotiate to a modern crypto suite the majority of the time.  Making this mandatory will have detrimental effects:
 
- It will slow adoption of HTTP/2 as implementers have to wait for new TLS platforms which can enforce section 9.2.2.
- It increases the likelihood that there will be non-conformant implementations of HTTP/2 in the wild.
- It creates more fragility in the negotiation of HTTP/2 and increases the likelihood of interop issues.
 
Historically this type of document is separate from the core protocol, either a standard from the TLS working group (ala 2818) or a BCP from the UTA working group like what is being defined for HTTP 1.1.

-Rob

-----Original Message-----
From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Tuesday, October 7, 2014 6:39 AM
To: Eric Rescorla
Cc: Mark Nottingham; HTTP Working Group; Martin Thomson; Greg Wilkins
Subject: Re: Concluding discussion on #612 (9.2.2)

I still don't like having this kind of requirement since, at present, there is no way for me to enforce it and still support HTTP/1.1 without some after-the-fact oops code that shuts things down.


> On Oct 7, 2014, at 3:30 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> As I said before, I don't really have a dog in this fight, but I note 
> that one of Greg's proposals is to write 9.2.2 more precisely:
> 
>    - rewrite 9.2.2 in more precise language (no 'such as')
> 
> In that spirit, I suggest the following text which I believe fits Note 
> that this is not a claim that it addresses Greg's concern -- that is 
> for Greg to decide -- but merely an attempt to formalize what I 
> believe the current text already implies.
> The last sentence is arguably too conservative, but is intended to 
> resolve potential ambiguities about future non-AEAD ciphers and in any 
> case will be easy to deal with.
> 
> 
>   HTTP2 MUST NOT be used with cipher suites that use stream [RFC5246;
>   Section 6.2.3.1] or block [RFC5246; Section 6.2.3.2]
>   ciphers. Authenticated Encryption with Additional Data (AEAD) modes
>   [RFC 5246; Section 6.2.3.3]) are acceptable.  At present, the only
>   such modes defined for TLS are the Galois Counter Model (GCM) mode for
>   AES [RFC5288] [RFC5289; Section 3.2] and Counter with CBC-MAC Mode
>   (CCM) [RFC665] [RFC7251], but any future AEAD modes are also
>   acceptable. Any future TLS modes that are not of the AEAD form MUST
>   NOT be used without an RFC updating this document.
> 
> Hope this helps.
> 
> -Ekr
> 
> 
> On Tue, Oct 7, 2014 at 1:57 AM, Mark Nottingham <mnot@mnot.net> wrote:
> I'd like to get to a call for consensus on <https://github.com/http2/http2-spec/issues/612> very soon.
> 
> To help get us there, I've prepared a wiki page that I think summarises the issues that have been raised:
>   https://github.com/http2/http2-spec/wiki/TlsRequirements
> 
> Martin has made a proposal in the form of a pull request:
>   https://github.com/http2/http2-spec/pull/615
> ... and it looks like there's general support for incorporating it. Does anyone have a reason not to?
> 
> Greg has made a number of proposals, listed in short form at:
>   
> http://www.w3.org/mid/CAH_y2NH=skUXk0QwCs4uVqWE=iOLhi5K+kvARDUQ7uMeogr
> w9A@mail.gmail.com
> 
> Martin and Greg, do you need time to develop your proposals any further?
> 
> Greg, you made quite a few proposals -- did I miss any others, or do you want to selectively nominate one or more of them for consideration?
> 
> Finally, does anyone else wish to make a proposal?
> 
> Regards,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 7 October 2014 20:14:08 UTC