On Thu, Aug 27, 2015 at 12:26:03PM -0700, Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The
> way that many stacks work (for instance NSS) is that they negotiate the
> cipher suite *first* and then they check for the presence or absence of
> the relevant extensions.
>
> It's not clear to me that it's an improvement to require them to check
> for error conditions that are not otherwise relevant.
One issue related to "layered" negotiation, in which one first
chooses X, then with X already chosen, chooses Y, ... is that some
choices of X are not compatible with any available Y, while other
choices of X might work.
A specific example may help: Many libraries will first choose the
highest mutually supported protocol version, and only then select
a mutually supported cipher suite. However, not all ciphersuites
are compatible with all protocols versions.
So we can have situations in which TLS 1.2 and TLS 1.3 are offered
by the client and TLS 1.3 is selected by the server, but none of
the ciphers offered by the client are AEAD. Should the server have
chosen TLS 1.2, or MUST the client figure out that it can't do TLS
1.3 and not offer it.
There will undoubtedly be clients that naively give the server
"impossible" options along with other options that work. Should
servers try to handle this gracefully?
Note that in the above scenario the client might offer *some* TLS
1.3 compatible ciphers, but it may happen that none are shared by
the server, while they both share common TLS 1.2 ciphers.
One way to avoid such problems is to suggest that clients that
don't offer the MTI ciphers for a particular protocol version (and
thus can't generically expect interoperability with servers that
implement that protocol) SHOULD NOT offer the protocol version.
Libraries might then have an option that is on by default, and
suppresses protocols for which the MTI ciphers are not enabled.
Clients that really want to offer only non-MTI ciphers would have
to clear the option explicitly.
Half-baked ideas aside, some discussion of the problem may be
relevant so that servers or clients avoid negotiating impossible
partial choices.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
