Re: null ciphers in 9.2.2

On 7 October 2014 15:14, Greg Wilkins <gregw@intalio.com> wrote:
> You are saying that we will be OK if endpoints "just comply with 9.2.2", yet
> that "clients and servers routinely have hidden switches to override
> specification requirements".     Thus you are saying we will routinely be
> exposed to a fragile handshake that might not work.

That's a logical fallacy called a category mistake.  The switches
exist only for private deployments.

I know of many places where standardized protocols are broken in
various ways when there are private agreements between the
communicating parties.  This is what Ekr refers to when he talks about
switches like this.

The document we produce does not apply in those situations, and it
should not attempt to apply.

> 9.2.2 interpretation is and will be subject to configuration.  Initially the
> configuration might be made non compliant only for testing or for niche
> deployments.  But in future, who know how ciphers will evolve and how that
> configuration will be changed in real deployments.

As I have said, this is also incorrect.  9.2.2 is unambiguous and
deterministic (modulo the sort of aggressive qualification that ekr
proposed upthread).  This allows for new ciphers, so the set of
ciphers can vary on configuration.  That's a feature.

Received on Tuesday, 7 October 2014 22:37:54 UTC