InCommon metadata support

[Tom Poage <>]

> 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] https://spaces.internet2.edu/x/q4FFBg

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?

Tom.