Re: [VOTE] Improved TLS Defaults RFC

On Wed, Feb 12, 2014 at 7:17 AM, Pádraic Brady <padraic.brady@gmail.com>wrote: > Hi, > > On 11 February 2014 21:53, Daniel Lowrey <rdlowrey@gmail.com> wrote: > > On Tue, Feb 11, 2014 at 4:16 PM, Stas Malyshev <smalyshev@sugarcrm.com > >wrote: > >> - What is the motivation for verify_depth default of 3? RFC does not say > >> anything on it. > >> > >> > > I admit this one is a somewhat arbitrary limit (which explains the lack > of > > explanation in the wiki text). OpenSSL will default to a limit of 9 if we > > don't specify one ourselves, so there's not really that much to be gained > > by using a default of 3. After considering this a bit more I think it > best > > to eliminate the addition of a default value in this area altogether. I > > will update the RFC and patch accordingly. > > It's partly arbitrary. The main reason for minimising depth, as far as > I'm aware, is to minimise the cost of TLS. It's an expensive operation > (even for the client) and having an infinite depth may, as far as I > know, be a potential DOS risk. The general values used are 3-6 > reflecting real world use. A requirement for a value above this would > indicate potential issues with the server. This may be something of a > historical artifact since I cannot remember where I heard it. I do > know that DOS against SSL servers used to justify limiting this value > for certain. > > Paddy may need a memory upgrade... > > -- > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > Zend Framework Community Review Team > Zend Framework PHP-FIG Representative > This was my original line of thinking. However in my research I was unable to find any real discussion centering around this issue as a significant DoS vector. A couple of things to consider ... 1. Infinite descent is not an issue because, if unspecified, OpenSSL will default to a verify depth of 9 as documented here: https://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html 2. If you're a client (far and away the more frequent use case in PHP) this is really a non-issue. Servers aren't in the business of DoS'ing clients and if they are doing something nefarious the solution is to simply not connect to those servers. 3. I think it's generally safe to expect a bit more knowledge from developers writing servers than those writing clients. 4. Servers verifying client certificates is only common in very specific environments (e.g. corporate intranets). In these sorts of implementations the verify depth will almost always be 0 for self-signed or 1 for an internal/organizational CA. For these cases a feasible low default verify depth setting is still not useful. For these reasons I think it's best to leave out the additional default setting for now. It would likely only result in failed transfers that would otherwise have succeeded without adding very much real tangible security benefit. Daniel