Re: #612: 9.2.2 requirements

Jason Greene <jason.greene@redhat.com> wrote:

> > The question at hand is what interoperability cost is involved in 9.2.2.
> If it is a cost paid by a few implementations who don’t have adequate APIs
> immediately at hand, that is emphatically *not* a technical issue.
>
> AFAIK there is exactly *one* TLS implementation out there that has nearly
> adequate facilities, NSS.
>

If NSS's facilities are adequate, then that is a very good sign for other
implementations, because NSS's facilities for this are very simple, were
very simple to implement, and were deployed without any (AFAIK) disruption
to any production systems.


> Ilari’s use case is a great example of where it all goes wrong:
>
http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html


He wrote, in part:

> 4) Server TLS stack picks ALPN "h2" and ciphersuite
> XYZ (must be 9.2.2 compliant because of 1).
> 5) The HTTP/2 stack has no (or only partial[1]) idea what XYZ is.

First of all, it is almost always going to be a bad idea to have the server
TLS stack choose which application protocol to use. Instead, it should
defer that choice to the server application. Second of all, if the server
doesn't take that advice, and the TLS stack has already chosen h2, then the
HTTP/2 layer might as well keep going on the assumption that XYZ is OK,
because it hasn't given itself any better choice, due to not taking that
advice. If things don't work, the server administrator will likely fix it
by improving the cipher suite configuration, probably by reading section
9.2.2 of the specification or documentation derived from it. Of course,
it's better for the server software implementation to just automatically do
the right thing, but that's a quality-of-implementation issue, not a
protocol issue.

Cheers, Brian