[datacatalogs] SSL and DCIP v2

[Will Pugh]

On Thu, Nov 22, 2012 at 8:24 AM, Rufus Pollock <rufus.pollock at okfn.org>wrote:

> On 21 November 2012 07:01, Will Pugh <will.pugh at socrata.com> wrote:
> > Hey folks,
> >
> > I was looking at the DCIP spec, and had a couple of issues with the HTTP
> vs.
> > HTTPS section in here.  My primary concern is that the approach eluded
> to in
> > the spec does NOT seem to address many of the things SSL addresses (such
> as
> > Man in the Middle attacks).
> >
> > If an attacker were able to poison a DNS cache, or intercept traffic in
> any
> > other way, there is nothing that prevents them from creating a SHA-256
> of my
> > bogus response and adding that in the header.  The spec mentions the
> > Facebook API, but I believe that API requires a secret key and uses an
> HMAC
> > to sign the response.  However, even if you wanted to put something like
> > that in, you still need to make sure to not have any potential Man In The
> > Middle attacks when getting the secret key.  Normally, this is done
> through
> > communication over HTTPS.
>
> Good point Will. The issue here I think arose in preparing version 2.0
> in which some proposed material  re signing got dropped but the
> reference did not get removed - this is definitely something to
> explore but it was felt to add significant complexity.
>
> Be interested to hear what you or others think regarding enhancing the
> security aspects of the DCIP as it stands.


My take here would be to stay out of the security game.  I would say that
DCIP is about interoperability and not about security.



> > HTTPS provides a much better trust chain than you are going to get with
> any
> > other "homespun" mechanisms.
> >
> > I don't think we should mandate HTTPS, but I think that catalogs that
> don't
> > support HTTPS are going to be open to spoofing and MITM attacks.  I'd
> rather
> > not give folks a false sense of security and discourage vendors from
> > providing real protection against MITM and tampering.
>
> Agreed.
>
> > HTTP is a well layered protocol.  It is made that way so that standards
> like
> > this can focus on interoperability and leave the security and trust up to
> > the experts.
>
> So your preference here would be to stick with HTTP and remove the
> possibly confusing discussion around HTTP / HTTPS?
>

Yes.  I would say that the standard sits above HTTP/HTTPS and that which
one us used is orthogonal.  Providers that want to provide protection are
free to use HTTPS, but providers are not compelled to.

>
> Rufus
>
> >     --Will Pugh
> >        CTO Socrata
> >
> >
> > _______________________________________________
> > data-catalogs mailing list
> > data-catalogs at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/data-catalogs
> > Unsubscribe: http://lists.okfn.org/mailman/options/data-catalogs
> >
>
>
>
> --
> Co-Founder, Open Knowledge Foundation
> Promoting Open Knowledge in a Digital Age
> http://www.okfn.org/ - http://blog.okfn.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/data-catalogs/attachments/20121123/219d198e/attachment-0001.html>