Re: #612: 9.2.2 requirements

On Sat, Nov 1, 2014 at 7:55 PM, Michael Sweet <msweet@apple.com> wrote:

> Nicholas,
>
> > On Nov 1, 2014, at 12:42 PM, Nicholas Hurley <hurley@todesschaf.org>
> wrote:
> >
> >
> >> On 1 Nov, 2014, at 05:14, Michael Sweet <msweet@apple.com> wrote:
> >>
> >> However, in this case it seems that some feel that the mandatory cipher
> suite in TLS/1.2 is inadequate, and that a specific set of cipher suites is
> now preferred (and MAY be a requirement in TLS/1.3). Therefore, the proper,
> RFC 2119, approach would be to require support for one or more cipher
> suites that are seen as providing adequate security - that ensures
> interoperability and that the two end points will be able to negotiate a
> "secure" connection without requiring layering violations or causing
> interoperability problems.
> >
> > Good news! Quoting 9.2.2:
> >
> > "To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST
> support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256
> [FIPS186].”
>
> I have no problem with this.  I *do* have a problem forbidding all of the
> other TLS/1.2 cipher suites (including the mandatory cipher suite in RFC
> 5246) which is a) not necessary for interop and b) causes interop and
> implementation problems.
>
> Also, based on the traffic on the TLS WG list, it looks like TLS/1.3 will
> still include cipher suites that are not allowed by the current HTTP/2
> text, but are otherwise considered "secure".  And thanks to the current
> wording, they will be valid when TLS/1.3 is negotiated but not TLS/1.2.
> (think of the interop issues there!)
>

Which cipher suites do you believe those will be?

-Ekr