Subject: [TLS] Server abort because of unrecognised vs rejected client provided parameters

From: Hubert Kario <[email-masked]>
Date: Fri, 21 Oct 2016 15:24:35 +0200

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 I think we should add to the insufficient_security description the 
following sentence:

   In case the connection peer advertised security parameters not recognized 
   or unsupported by the implementation, the implementation MUST send
   "handshake_failure" alert instead.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 27 Oct 2016 19:46:40 +0200

> 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

---

From: Hubert Kario <[email-masked]>
Date: Thu, 27 Oct 2016 20:22:55 +0200

On Thursday, 27 October 2016 19:46:40 CEST Kurt Roeckx wrote:
> > 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.
> > 
> > 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.
> > 

handshake_failure

ideally because server recognizes that client hello includes values
it implements that are stronger than what it has enabled

the main point is to differentiate failures caused by too weak/old clients 
from regular lack of overlap between server and client implemented parameter 
set

in short, server should never send insufficient_security if all parameters 
included in client hello are ones that have been defined at the time when 
server was implemented