On Fri, Oct 21, 2016 at 03:24:35PM +0200, Hubert Kario wrote: > Currently TLS has two alert descriptions for when there is no intersection > between ciphers/sigalgs/groups advertises by client and ones that are enabled > in server. It's the handshake_failure and insufficient_security alerts. > > While it is a step in good direction in providing users with better messages > in case of connection failure, I think there is one edge case which may ruin > the effort. > > Let's say we have a client that advertises following signature methods: > rsa-ssa-sha256 > rsa-ssa-sha384 > > and this client is connecting to server which requires use of rsa-ssa-sha512 > signatures only, but does implement weaker hashes and the requirement is just > result of administrator requiring high security. > > I think that such connection attempt should end with insufficient_security. > > Problem is, what if the server does not implement some even never RSA > signature format, but client does advertise support for them? > > I think then the connection should end with handshake_failure.
So what about the case where the server does implement it, but it's been disabled? For instance because he wanted to disable MD5 he only enabled SHA-1 years ago, but then SHA-2 got implemented and only SHA-1 is enabled. Kurt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
