Re: TLS certificate verification policy?

> Mikael Nordfeldth <mailto:mmn@hethane.se>
> 08 November 2014 20:22
> On 2014-11-08 19:34, Owen Shepherd wrote:
>> WebFinger does not mandate CA verification. It mandates certificate
>> verification. This does not necessarily require CAs as the trust roots.
>
> My bad. Nevertheless, it effectively excludes (today) anything that is
> not the CA system since just about every implementation will validate
> against the Mozilla CA list or similar. So Monkeysphere, self-signed
> etc. cannot compete at the same level as friends of too-big-to-fail
> companies like Verisign or Comodo.
>
>> I think it is important for us to require HTTPS and validation. We need not
>> specify the mechanism of validation.
>
> If we don't define a validation procedure but _do_ require validation it
> will cause confusion and incompatibility. I'd gladly see the protocol
> specification _allow_ for certificate validation but not forcefully
> require it.
It seems to work well enough for the web.
> Nodes in the network which want to explicitly validate TLS certs
> according to their preferred threat models or company policies can do
> so. If they want, they can integrate some feedback to their users about
> which other nodes are operating with non-validated services or simply
> not interoperate.
"Validation" could be as simple as "verify that the certificate hostname 
matches the ___domain name." Such lax validation should be discouraged, of 
course, because of all the associated security issues implied by it.
> Just my 2 cents.
>
> --
> Mikael Nordfeldth
> XMPP/mail: mmn@hethane.se
>
> Owen Shepherd <mailto:owen.shepherd@e43.eu>
> 08 November 2014 18:34
>
>> Mikael Nordfeldth <mailto:mmn@hethane.se>
>> 08 November 2014 18:12
>> Hi all, I'm the current maintainer of GNU social (formerly StatusNet).
>>
>> I figured I'll try to install Diaspora to work out some kinks that are
>> making it hard for Diaspora and GNU social to federate, despite very
>> similar protocols in use.
>>
>> During my installation I found that Diaspora by default requires CA
>> validation on HTTPS connections. This requires everyone running Diaspora
>> to purchase (or trust StartSSL not to start charging) a TLS certificate
>> - and I guess we all know what a fishy and awful business that is. Sites
>> are not able to use self-signed certificates or even CAs like CAcert.org.
>>
> CACert haven't even yet successfully passed the audits required to be 
> a CA included in any of the various browsers. While I believe the 
> CACert guys are honest, why should anybody trust an organization which 
> is unable to pass an audit verifying the secure management of its' 
> trusted root certificates?
>
> The CA model is a problematic one, though CACert isn't the answer. 
> Techniques like certificate pinning can mitigate the downsides somewhat.
>> Relatedly, the XMPP community has recently decided to use a baseline of
>> required TLS encryption but _not_ required CA verification. (sidenote:
>> this leaves out the already doomed Google Talk from wide XMPP federation
>> since Google won't enable server-to-server TLS).
>>
>> Diaspora has a reason not to immediately change their default
>> configuration, since they _hotlink_ a lot of data such as remote users'
>> avatars etc. This would cause many problems for today's web browsers
>> since they are following their own CA root certificate databases, giving
>> out errors for anything "unverified". (GNU social caches everything
>> locally and publishes from the user's already trusted server)
>>
> I don't think its reasonable to cache every social object locally - 
> what about shared videos, which can be quite sizable? It seems 
> reasonable to postulate that hotlinking is a necessity in this case.
>>
>> Either way, this got me thinking on whether TLS enforcement of any kind
>> is within the scope of this working group when working out a protocol
>> and deciding on security models.
>>
>> Unfortunately, WebFinger (RFC7033) was standardised with enforced HTTPS
>> + CA verification (without referencing a list of trusted CAs, thus
>> ensuring total chaos in which trust chains to use). That's something to
>> be consider if WebFinger becomes part of a Social Web protocol.
>>
> WebFinger does not mandate CA verification. It mandates certificate 
> verification. This does not necessarily require CAs as the trust roots.
>> Also I have no idea how (or whether at all) the linked data web folks -
>> which might be relevant if we're using some LD interface) have any idea
>> how to address HTTP vs. HTTPS, given there's no good migration policy.
>>
> The ActivityPump draft I have submitted requires everything be served 
> over HTTPS. This is a policy I'd encourage - non-secure HTTP should be 
> deprecated, especially for potentially private data.
>>
>> If the discussion on TLS/HTTPS is within the scope of the working group,
>> I suggest we set it as a requirement - but leave out CA verification,
>> just like the XMPP community has done and for the same reasons.
> I think it is important for us to require HTTPS and validation. We 
> need not specify the mechanism of validation.
>
> For the time being, that is likely to be CA based. What we should 
> encourage is the adoption of DNSSEC DANE or a similar technology, 
> which specifies the server's certificate and enables validation of 
> its' authenticity via DNS.
>
> DANE doesn't solve all problems (it will still be time for a trip to a 
> CA if you want an EV certificate, for example), but it does solve the 
> big one.
>
> Unfortunately, I don't know of DANE being on any browser's near-term 
> road map.
>
>     - Owen
>
>     - Owen
> Mikael Nordfeldth <mailto:mmn@hethane.se>
> 08 November 2014 18:12
> Hi all, I'm the current maintainer of GNU social (formerly StatusNet).
>
> I figured I'll try to install Diaspora to work out some kinks that are
> making it hard for Diaspora and GNU social to federate, despite very
> similar protocols in use.
>
> During my installation I found that Diaspora by default requires CA
> validation on HTTPS connections. This requires everyone running Diaspora
> to purchase (or trust StartSSL not to start charging) a TLS certificate
> - and I guess we all know what a fishy and awful business that is. Sites
> are not able to use self-signed certificates or even CAs like CAcert.org.
>
> Relatedly, the XMPP community has recently decided to use a baseline of
> required TLS encryption but _not_ required CA verification. (sidenote:
> this leaves out the already doomed Google Talk from wide XMPP federation
> since Google won't enable server-to-server TLS).
>
> Diaspora has a reason not to immediately change their default
> configuration, since they _hotlink_ a lot of data such as remote users'
> avatars etc. This would cause many problems for today's web browsers
> since they are following their own CA root certificate databases, giving
> out errors for anything "unverified". (GNU social caches everything
> locally and publishes from the user's already trusted server)
>
>
> Either way, this got me thinking on whether TLS enforcement of any kind
> is within the scope of this working group when working out a protocol
> and deciding on security models.
>
> Unfortunately, WebFinger (RFC7033) was standardised with enforced HTTPS
> + CA verification (without referencing a list of trusted CAs, thus
> ensuring total chaos in which trust chains to use). That's something to
> be consider if WebFinger becomes part of a Social Web protocol.
>
> Also I have no idea how (or whether at all) the linked data web folks -
> which might be relevant if we're using some LD interface) have any idea
> how to address HTTP vs. HTTPS, given there's no good migration policy.
>
>
> If the discussion on TLS/HTTPS is within the scope of the working group,
> I suggest we set it as a requirement - but leave out CA verification,
> just like the XMPP community has done and for the same reasons.
>
> --
> Mikael Nordfeldth
> XMPP/mail: mmn@hethane.se
>

-- 
Sent using Postbox:
http://www.getpostbox.com