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