Re: #612: Adopting pull #644

Its not actually part of the change list, but we say "Implementations of
HTTP/2 MUST support <xref target="TLS12">TLS 1.2</xref> for HTTP/2 over
TLS."..

I think we actually mean must only use versions >= TLS 1.2

1] tls-1.2-die-die-die is certainly a possibility down the road
2] support is more ambiguous than "use"..  let's not leave room for some
kind of twisted reading in favor ssl3 intolerance fallback just because
each side supports 1.2.

hth.



On Fri, Nov 21, 2014 at 2:15 AM, Mark Nottingham <mnot@mnot.net> wrote:

> BTW, for reviewing, I use:
>   https://github.com/http2/http2-spec/pull/644/files
> ... selecting the "split" view and turning off "Show notes".
>
> YMMV.
>
>
> > On 21 Nov 2014, at 6:05 pm, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> > tl;dr: new PR:
> > On 20 November 2014 15:47, Mark Nottingham <mnot@mnot.net> wrote:
> >> What do people thing about changing this text:
> >>
> >> """
> >> A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher
> suites that are only be used with cipher suites that are listed in <xref
> target="BadCipherSuites"/>
> >> """
> >>
> >> to a SHOULD NOT?
> >
> > I've prepared the draft with a SHOULD.  And noted the risks...
> >
> > On 20 November 2014 15:50, Mark Nottingham <mnot@mnot.net> wrote:
> >> On 18 Nov 2014, at 7:36 pm, Yoav Nir <ynir.ietf@gmail.com> wrote:
> >>> Regardless, unlike MAY and MUST, you can’t just use “SHOULD” and
> “SHOULD NOT” in a document. They require an explanation of why you should
> not, and under what circumstances your are allowed to do that something
> that your should not do.
> >>
> > [...]
> >>> So, if we agree with you, we need to complete the sentence, “HTTP/2.0
> clients and server SHOULD NOT use ciphers from this list unless …”
> >>
> >> "... unless the server is deployed to communicate with a known
> population of clients, or is willing to accept that some clients will
> refuse to communicate with it."
> >
> > I've not chosen that precise form (it's clunky without the connection
> > error being introduced).  But I think that I've framed it in a way
> > that should avoid a DISCUSS target.
> >
> >>> Finally, we should say something about why we need this functionality:
> endpoints typically will support both HTTP/1.1 and HTTP/2, and TLS does not
> allow either endpoint to restrict the list of negotiated cipher suites
> based on the ALPN negotiated protocol (i.e. ALPN just allows the client to
> send a list of protocol identifiers, not identifiers + cipher suites).
> >>
> >> I think that's good editorial input for Martin.
> >
> > Text to that effect has been in the document for ages, though it was
> > removed in the PR.  I'll try to find a way to have it return in some
> > fashion.
> >
> > ...I've also tried to fix some wording contortions around the TLS
> > 1.2/1.3+ split here.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>