- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 12 Nov 2014 23:09:57 -0600
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: Yoav Nir <ynir.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
I agree that this would be the best way to specify this new approach. The reality is even if stricter language is used, it won’t be any more enforceable than what you propose. Perhaps this is already what Martin intended to specify? > On Nov 12, 2014, at 12:56 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > > I think this is moving in a better direction, but Yoav's note is one of the biggest reasons why I think rather than trying to introduce a new concept of "mandatory to deploy," we should use the well-tested model of MUST implement, SHOULD use. This is one of many situations in which a deployment will know better than this WG which ciphers are appropriate to their environment. SHOULD means that if you don't, you're likely to have interop pain, which seems exactly applicable here. If you have local knowledge that leads you to depart from this behavior, you do that knowing clients outside your control won't talk to you as easily. > > Also, having the spec mandate *capabilities of the TLS stack you choose* and *HTTP/2 behaviors based on the TLS outcome* makes me much happier than having the spec mandate behaviors that happen inside the TLS stack. Let's keep the layers clean. > > -----Original Message----- > From: Yoav Nir [mailto:ynir.ietf@gmail.com] > Sent: Tuesday, November 11, 2014 6:29 PM > To: Mark Nottingham > Cc: HTTP Working Group > Subject: Re: #612: 9.2.2 and ALPN > > I think making a ciphersuite “mandatory to deploy” is weird. In Russia, all traffic for certain kinds of information (financial, personnel records, etc) is required to be encrypted using GOST-sanctioned algorithms. > > A requirement like this would mean that what they’ll be doing in Russia is somehow “not HTTP/2” even though it looks exactly the same as HTTP/2. Mandatory to implement is fine, but turning HTTP/2 into "not-HTTP/2" because of the configuration of the TLS server seems wrong. > > >> On Nov 11, 2014, at 4:03 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> We had a wide-ranging discussion in about this issue in Honolulu today. After an introductory presentation <http://httpwg.github.io/wg-materials/ietf91/922.pdf>, and then much discussion/iteration, we ended up with this on the screen: >> >> -8<- >> If the ciphersuite selected for h2 is... >> BAD = peer MAY INADEQUATE_SECURITY >> !BAD = peer MUST NOT INADEQUATE_SECURITY >> >> Peers probably shouldn't negotiate BAD >> >> where BAD is a fixed in-spec blacklist >> ->8- >> >> Using the straw-man proposal on the last page of the PDF, this implies #5 (relax requirement to generate INADEQUATE_SECURITY) and a modification of #2 (Nominate a fixed list of suites for use with H2+TLS12) to a blacklist rather than a whitelist. >> >> Not explicit here but implied (and seemingly not controversial) were #1 (making all cipher suite requirements specific to TLS 1.2), #3 (keep the required interop suite as mandatory to deploy) and #4 (Clarify that cipher suite requirements apply to deployments, not impl). >> >> Note that there is NOT a requirement to use or not use particular cipher suites; only a prose note that if you do so, you may encounter problems. This is somewhat in the spirit of #4. >> >> #6 didn’t seem to get significant support, so I think the plan is to drop it. >> >> >> Martin is going to prepare a pull request with exact text, using the requirements currently in 9.2.2 to create the blacklist. >> >> Based on the reaction in the meeting (which included some but not all stakeholders) as well as some 1-to-1 discussions I’ve had with people who weren’t there, I believe that this is likely to be as close to a consensus position that we can get. >> >> Please ask comment or questions if need be, and indicate your support or lack thereof (now if you’re comfortable doing that, or after Martin shows exact text). >> >> Regards, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> > > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 13 November 2014 05:10:35 UTC