Re: TLS certificate verification policy?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 11/08/2014 07:12 PM, Mikael Nordfeldth wrote:
> 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).

Interesting data point.

> 
> 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.

This discussion is definitely in scope but is also larger than just
this Working Group. Note there is a larger discussion about when to
require TLS and validation and when not to in the TAG and across all
W3C APIs - see www-tag@w3.org for details of the discussion. The
general move seems to be to try to mandate TLS enforcement whenever
necessary.

While I think many people agree the CA system is badly broken and
efforts are ongoing to try to provide some checks on it such as IETF's
CertTrans, we do have a problem as there is also no consensus on an
alternative to the  CA system.

> 
> 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.

See Owen's email.

> 
> 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.

Off the top of my head, I'm happy to see CA verification normatively
left out and TLS normatively left in, but CA verification should be
listed as at least one amongst many trust models and we should
probably informatively ask specify some authentication mechanism with
a clear trust model should be used. Happy to hear other opinions.

   cheers,
      harry

> 
> -- Mikael Nordfeldth XMPP/mail: mmn@hethane.se
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUX8FnAAoJEPgwUoSfMzqcfzEP/A9soJSpZ79MB7KE56PZ0RQ8
ePdX56ViEQKwMdbkSbpMXAQi15FDCqRDjtsLfsTNZPj93qYQ9Vqf3Iu3rcar3fnl
W7RASfxW8KU5Kl64RwGmdYD7+nMZP1l918GfpbyLY033RvFKKfq97/PTOWIxy5hM
rP0oNsc0peY5nws6kDMtv+UFqBArxATcPEZLO21Zs0kplT69jsKwA8N/OrZ48ZDl
wGRjD8H3V08N2dqnVuRAjuPoRGn5UQVbWCb7vpemZ1SHbfDtm0GJiBUi1XYxSB+1
KQJqPd4rdQM2q3B64dEoY8WG1FctvRQAx7OBA1+OAJ8bzhdGjxRDdaF4eJ+Nq2JY
hVwZZvxJHWBsqirX1waSWC1yvqjZcQrzGMjnKQxh5a950VliBNnqmdYVCeClfHQ+
sPzrMwDIN4cIRokbn2YRAeeZVEjoUsBbM6aAjYYKtj5nobe3GuLE7Qqcn11ouC2z
vJSrC9Fl4eJWNvT3YBvJfRjld729tHpJLUziJdXMskMJsGPAig6FXfQOJvewtzdi
BnyKjbLnnU0CC51Lktc6DMR58Z89NeKO5aQ7x5Mi/8elZ0zfvIdXqboR7jdLav4B
LlMaYcw/6KSzSyONH3BJ6KJmesnSkkwTCtW+mY1i0Rqk4+O9vxVbIPWvinWzblIr
aVNu5z45dZvz5yE37XLH
=5kQz
-----END PGP SIGNATURE-----

Received on Sunday, 9 November 2014 19:33:08 UTC