Re: #612: 9.2.2 requirements

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

> > Brian Smith <brian@briansmith.org> wrote:
> > 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.
>
> It’s close, but I think its still missing the ability to actually
> influence the handshake, which would require characteristic based priority
> ordering (or alternatively large white lists that hopefully match). Hey if
> its easy for all of them to address this problem, thats great, but IMO we
> should be asking them, not just assuming it will occur.
>

The TLS implementation should be configured to always prefer
9.2.2-compliant cipher suites over non-9.2.2 compliant cipher suites,
regardless of which application protocol is negotiated. Or, at least that
should be the case when the TLS implementation doesn't offer a mechanism to
choose the cipher suite based on the application protocol.


> > 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.
>
> That doesn’t help because the problem is the cipher selection happens
> independently of all of that (handshake precedes the ALPN selection), and
> its shared between H2 and H1 support thats the issue.
>

The handshake does not precede ALPN selection. With ALPN, the ServerHello
message contains the chosen protocol, and ServerHello is the first message
the server sends. The TLS implementation cannot send even the initial bytes
of the ServerHello message without knowing the chosen protocol because the
length is encoded at the start of the message, and the length is dependent
on the protocol chosen. If the TLS implementation provides a mechanism for
the application layer to choose a cipher suite based on the protocol, then
it needs to ask the application for the protocol before it chooses a cipher
suite. Otherwise, like I said before, it should always just choose an
9.2.2-compliant cipher suite.

> 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. I
>
> Since it does not know that XYZ is allowed by 9.2.2 it has no choice but
> to reject. Without a proper protocol negotiation the H2 implementation is
> required to either have in-synch consistency with the TLS stack (and also
> consistency with the peer TLS & H2 stack), or it needs the ability to ask
> and influence the TLS stack as part of the TLS stacks handshake, using some
> simpler set of rules.
>

No, it doesn't have to reject XYZ. It can carry on based on the assumption
that XYZ is OK. If it is, then the client will accept it. If it isn't, the
client will return INSUFFICIENT_SECURITY to the server. (Keep in mind that
this is only in the worse case where the server's HTTP/2 implementation is
based on a TLS stack that is too inflexible to do better things.)


> > f 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,
>
> Yes the best course of action will be for the administrator to add XYZ in
> the configuration. However, if a server implementer simply ignored 9.2.2,
> XYZ would have succeeded, without user intervention, leading to better
> security and performance. Until the proper TLS APIs exist (I’m not holding
> my breath), or TLS 1.3 occurs, this is the best action an implementer can
> take.
>

Like I said above, if the server HTTP/2 implementation is in the
unfortunate situation where it has no choice but to accept the cipher suite
and protocol that the TLS implementation chose, and it has no way of
learning the relevant properties of the unknown cipher suite XYZ, then it
should assume that XYZ is valid as far as 9.2.2 is concerned and rely on
the client to reject it, in the absence of better information.

However, again, this can only occur when the server software stack is
designed in the worst possible way that could possibly work AND when the
server software is configured poorly. Luckily, it is easy to change TLS
stacks and HTTP stacks to use a better design, and it is possible (perhaps
not so easy) to design things in a way that helps server administrators
migrate to good cipher suite configurations.

Cheers,
Brian