Re: [TLS] Server abort because of unrecognised vs rejected client provided parameters
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
Re: [TLS] Server abort because of unrecognised vs rejected client provided parameters
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
[TLS] Server abort because of unrecognised vs rejected client provided parameters
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 signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
