Skip to Content.
Sympa Menu

metadata-support - Re: [Metadata-Support] MDQ format options?

Subject: InCommon metadata support

List archive

Re: [Metadata-Support] MDQ format options?

Chronological Thread 
  • From: Tom Poage <>
  • To: "" <>
  • Subject: Re: [Metadata-Support] MDQ format options?
  • Date: Wed, 7 Dec 2016 22:22:50 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:y+zTbRS459gzKNPdmOTh2rPiQ9psv+yvbD5Q0YIujvd0So/mwa6ybByN2/xhgRfzUJnB7Loc0qyN4vumBDZLvs3JmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanb75/KBu7oR/Ru8UIjodvKKg8wQbVr3VVfOhb2XlmLk+JkRbm4cew8p9j8yBOtP8k6sVNT6b0cbkmQLJBFDgpPHw768PttRnYUAuA/WAcXXkMkhpJGAfK8hf3VYrsvyTgt+p93C6aPdDqTb0xRD+v4btnRAPuhSwaMTMy7WPZhdFqjK9DoByvuQFxw5Labo+WOvpxfKTTfdIGSmROUclcTDBBDZi5b4cTD+oNIeRVoo/grFUOtxu+AgysCfvxxD9Pg3/9wLc00+M7HgHJwgMrAtUDsGjarNXtM6cdS++1w7fTwDXec/xZxC3y6JbJchA6u/2DQ69/cdfIxEQpCgjLgFKQqYn/MDOU0OQAq2mb7+x8Ve2xkW4nrR9+oiSxyss2lIbGm58Vx1bZ/it62IY4PcC0RFB4bNK+DZdcqT2WO5F4T888WW1kpjs2x74etZKmYiQHy44rywPBZ/CbaYSE/xDuWPyMLTp3mn5pYK+zihe2/ES61OHxVsa53ExIoyZfjNXBuXYA3AHJ5MedUPty5EKh1C6P1w/N7uFEJlg5lbHeK5492r48i4AfsVnfESDrgkr2kq6Wdl4+9ue29uvnf63qpp6aN4BqlgHzKrkiltK8DOgiLwQCQXSX9f6y2bH950H1XqhGg/4unqncqp/aJMAbpqCjAw9S14Yu8wq/Dzm+0NQfh3YHI0xKdQmaj4f1Jl7BOu74Dfakg1i2jjhk2u3GMqX7AprRNnjDjKvhfbFl5k5dzgo80ddf55dRCrEGJvL/QEjxtMbXDhMgNgy73frnB89g2YwERWKAGLaVMLjPsV+Q/uIvJPOMZJMOtTb5Kvgl/OLujWQnlVMHfKmp24cXZ26iHvRgPUqZfWTgjs0fHmgXowptBNDt3ReHXCJaa3+uVucn+ykjD5i6JYbFTYeohbuHmiChEdceMmVLFlmAGGvhMp6ZQ+8Lcj66I8lqlTkBUr7nTJUug0KArgj/noZgK6Ls/SQXuNq3yNZt4OTcmDkv/jB9EcWGlWyBUjcnzSszWzYq0fUn8gRGwVCZ3P0gjg==
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

> On Dec 6, 2016, at 1:43 PM, Tom Scavo
> <>
> wrote:
> The consultation of the Final Report from the Per-Entity Metadata WG
> [1] ended yesterday, otherwise I'd ask you to weigh in on the
> following issue:
> Should the MDQ server serve entities over TLS? Most people say yes but
> then that raises a more interesting question: Should the TLS
> certificate be self-signed OR signed by a commercial CA OR signed by
> an internal CA created specifically for that purpose?
> Thoughts?
> Tom
> [1]

Assuming this is not an either-or proposition, I'm not sure I understand the
problem (wrt risk management) layering in TLS here tries to solve.

I haven’t gone through the final report in any detail, but to me a/the core
issue (which has always been there) seems to come down to how trust is
established, anchoring/pinning the authenticity of a public (hence proof of
possession of a private) key. To me, whether that’s a top-level CA in a
server cert or an XML signing key in a way seems immaterial.

I think one of the benefits of signing the payload, as done currently (and
once signing key trust is established), is that the content also remains
trustworthy at rest. I can sort of "walk away" from the content, leaving it
exposed to who knows what, come back later and still verify its authenticity
and integrity. In a way, then, it doesn’t matter from where I get this
content if it can still be validated. There’s no requirement for
confidentiality, and it’s not like the metadata consumer sends/posts anything
of substance to the MDQ server where it’s important to validate the
destination server to which one connects.

One case I can think of where layering in TLS may help is when the consumer
fails to validate the XML signature against the independently-obtained
signing certificate. And I would hope metadata consumers do not validate by
comparing the signature against the public key in the XML (my first thought
is remove the public key from the XML, but that would seem to leave a
bootstrapping problem identifying which key encrypted the signature ...
unless the consumer is independently shown or just knows which cert/key to
use. Hmm).

I seem to recall mention in the report of how TLS might help mitigate
man-in-the-middle, but don’t recall seeing how so. I could guess that if a
MiTM intercepts an MDQ response and either strips it of the signature or adds
some other signature, any “conforming” consumer would detect that and abort.
If a MiTM intercepts the request and alters it (currently being in clear
text), I can see how that could force the return of the wrong metadata.
That’s seems a form of DoS, so in this case I can see some added benefit of
using TLS, especially if the consumer fails basic due diligence: am I getting
what I requested?

So does layering in TLS then have tangible benefit reducing risk for metadata
consumers, or foster/enable laziness on the part of the data consumer? :-)

If the (COMODO?) cert costs “nothing” extra, and infrastructure suitably
scaled at modest cost to handle encrypted data in motion, what does it hurt?

Whether TLS uses commercial vs. self-signed, the only difference seems to be
a minor difference in effort to establish trust, given the typical bundle of
known (presumably trusted) CAs on most operating systems. I do see using a
self-signed certificate as presenting an obstacle to the typical skill set of
vendors I’ve been working with recently, even if it does force them to do the
“right thing” (which they habitually wish to avoid). That said, if attackers
are buying commercial certificates and somehow passing any identity checks,
that could spell some trouble.

Nothing is risk-free, so it comes down to risk management. My off-the-cuff
thoughts, right or wrong, aside, what precisely does TLS get us, in addition
to XML encryption, to improve the management of risk?


Archive powered by MHonArc 2.6.19.

Top of Page