From owner-freebsd-security@FreeBSD.ORG Wed Sep 11 02:57:36 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06C6A149 for ; Wed, 11 Sep 2013 02:57:36 +0000 (UTC) (envelope-from code@apotheon.net) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by mx1.freebsd.org (Postfix) with SMTP id C8CC22F32 for ; Wed, 11 Sep 2013 02:57:35 +0000 (UTC) Received: (qmail 2935 invoked by uid 0); 11 Sep 2013 02:57:06 -0000 Received: from unknown (HELO box543.bluehost.com) (74.220.219.143) by oproxy1.mail.unifiedlayer.com with SMTP; 11 Sep 2013 02:57:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=apotheon.net; s=default; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=rlgz2JQhRh7dvux/cGny7fg2Tnz/+PzifzJ+hr9+MVQ=; b=Roqjb7nmYyAumR67aWSuhARxE3/FhV8nmr/Bb+bq+USGYlRKquForPicEJxLTVn6Ch49K3xXKTHfmFTXoiz8PblHMWqQE0BhC/w5Uv0uywWfJP41UmOQbaULO1yjIOPf; Received: from [24.9.112.144] (port=61085 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VJac6-0000yY-Ht for freebsd-security@freebsd.org; Tue, 10 Sep 2013 20:57:06 -0600 Date: Tue, 10 Sep 2013 20:56:39 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: Anything in this story of concern? Message-ID: <20130911025639.GD1902@glaze.hydra> References: <20130909144142.J99094@sola.nimnet.asn.au> <94943.1378706943@critter.freebsd.dk> <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> <95933.1378712057@critter.freebsd.dk> <21038.32889.46054.73649@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21038.32889.46054.73649@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 24.9.112.144 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 02:57:36 -0000 On Mon, Sep 09, 2013 at 10:14:17PM -0400, Garrett Wollman wrote: > < said: > > > And as Garrett Wollman correctly pointed out on twitter: It remains > > yet to be seen if any implementation of SSL/TLS can be non-crap, > > given that they are stuck with X.509. > > I should say, by the way, that X.509 is not an inherent requirement of > SSL/TLS, *but* it's what the clients implement. You can do GSSAPI > authentication for the TLS key exchange, but there's little benefit in > doing that versus just doing straight GSSAPI sign/seal and leaving TLS > out of it completely. (Plus, there are only two options for GSSAPI; > one of them doesn't work at Internet scale and the other is back to > X.509 again.) You can also do OpenPGP-style Web of Trust > authentication for the TLS key exchange, but that doesn't work > at Internet scale either. GnuTLS supports both, however. It seems that you're saying something like Monkeysphere or Perspectives would somehow not work "at Internet scale", but it seems to me that the real weakness of these things would be a case of *small* scale, in that if either is not widely-enough used it will not suffice for many sites that are not popular enough to attract a sufficient percentage of the clients who actually use Monkeysphere or Perspectives. Granted, neither Monkeysphere nor Perspectives is *exactly* like PGP web of trust in how it works (both are more about merely achieving broad client agreements in practice, and not actual cryptographic trust relationships), so an actual direct port of PGP web of trust infrastructure to TLS key authentication might suffer other problems for scale, but I am not sure exactly what about the web of trust model you meant to indicate would not scale. > > What would work, would be better than the X.509 CA infrastructure we > have now, and has been demonstrated experimentally, is using DNSsec to > publish server public keys -- but that's hardly reducing the size of > the TCB, and it would significantly worsen the impact of bugs in > validating DNSsec implementations. The likely result, if browsers and > servers began to support this as a legitimate option, would be that > the existing rents collected by X.509 CAs would instead by paid to > domain registries and registrars instead. (On the other hand, it > seems unlikely that registries could get away with charging the same > premium for a secure delegation as CAs now do for a wildcard > certificate -- and the latter is a horrible idea anyway.) The real problem with CAs, honestly, is the fact that you have to *trust* the CAs . . . and I do not. They are simply not trustworthy. This seems like a problem that would make the transition to domain registries quite intact, based on what I know of the situation. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]