Re: Concluding discussion on #612 (9.2.2)

On Sat, Oct 11, 2014 at 06:00:56PM +1100, Greg Wilkins wrote:
> On 11 October 2014 09:23, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> wrote:
> 
> > Nope, all ciphers it gave are both acceptable for it and 9.2.2-compliant.
> 
> 
> So there is no problem.  Any cipher the server picks is acceptable to the
> client for h2, so the handshake will succeed.

But the server won't know that.

> If the server does not know XYZ and thus decides to not accept it according
> to 9.2.2, then the handshake will fail unless there is another cipher suite
> (or protocol) that the server is prepared to talk. 

Only if it rejects XYZ at TLS handshake time, which it was assumed not to.

> If failure occurs in
> this circumstance, then it is because there is not a mutually acceptable
> cipher/protocol pair.  

There may be. But the time server replies to TLS handshake attempt from
client, the number of ciphers is already down to 1.

>  The server is entitled to reject XYZ if it does
> not know it. Or the server can be more trusting and say that it does not
> know XYZ, but the client is prepared to speak it for h2, so it will also.

The whole point is that after TLS stack has negotiated XYZ, the server
can't reject it anymore without interop. failure against correct client
implementation unless the server actually knows it is not 9.2.2.-acceptable.

Obviously, if server had powerful enough cipher introspection[1], then the
this case could not arise, because server could classify every cipher
to either 9.2.2.-acceptable or 9.2.2.-unacceptable with 100% accuracy and
100% precision.

And unless server supports variant ALPN (which is the second thing that
can't be assumed[1]), then one can't disable XYZ just for h2.


> That all depends on the server security policy - which it is entitled to
> enforce.

Yes, if server admin wants to disable ciphers they think are insecure
or they have to disable for compliance reasons[2], let them.

 
> Handshake failures may still happen if there are no mutually acceptable
> cipher/protocol pairs.   The issue I want to see fixed is the handshake
> failures when there are mutually acceptable cipher/protocol pairs.

In the above example, the client and server might have another cipher
that both think is acceptable, but TLS cipher selection resulted a
problematic one.



[1] If TLS stacks reliably had variant ALPN and powerful enough cipher
introspection, then the only real problems in 9.2.2 as originally written
would be ECDHE min-key-length requirements[3] and that it is written in
confusing way.


[2] E.g. taking "sensitive cardholder data", one should disable SSL
3.0 and TLS 1.0 as per PCI DSS.


[3] One can interpret the "minimum of 128 bits" as DQing P-256, as
security measured as resistance against combined rho and PH would
be ~127.8 bits (and indeed, "Safecurves" says that P-256 has
security of 127.8 bits).



-Ilari

Received on Saturday, 11 October 2014 08:35:56 UTC