On Thursday, 27 October 2016 19:46:40 CEST Kurt Roeckx wrote:
> 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.
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
--
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
signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
