per-entity - RE: [Per-Entity] implementing a cache on the client
Subject: Per-Entity Metadata Working Group
List archive
- From: "Cantor, Scott" <>
- To: Tom Mitchell <>, "" <>
- Subject: RE: [Per-Entity] implementing a cache on the client
- Date: Thu, 28 Jul 2016 17:26:06 +0000
- Accept-language: en-US
- Authentication-results: spf=pass (sender IP is 164.107.81.216) smtp.mailfrom=osu.edu; bbn.com; dkim=none (message not signed) header.d=none;bbn.com; dmarc=bestguesspass action=none header.from=osu.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> [Apologies, I’ve realized this week that our corporate mail filters are
> stopping
> Tom Scavo’s emails to InCommon lists from getting to me. I anticipate no
> resolution.]
Can I start putting "I anticipate no resolution" in my sig? That's all
purpose.
> This seems to me to be a much larger concern. In my mind verifying the
> server is not in any way comparable to, or a sufficient substitute for,
> verifying
> the XML signature. And if a client is willing to trust the XML without
> verifying
> the signature, what’s to stop them from failing to verify the server against
> the certificate sent over TLS?
It is in fact essentially guaranteed. Most software "uses TLS" by blindly
assuming their HTTP client works right and does "stuff for security".
Tom's not wrong, though, that is in fact what they will do.
The question has always been: Do no harm? Or actively prevent it? By hosting
over http only, you can force the issue, at the cost of guaranteeing no
security at all for a wide range of software. It's a trade off with no clear
answer. The ornery side of me favors no TLS as a means of stripping people of
fig leafs, but the pragmatist says "improve security when you can" and that
standing on principle just makes your legs tired.
-- Scott
- Re: [Per-Entity] implementing a cache on the client, (continued)
- Re: [Per-Entity] implementing a cache on the client, Ian Young, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 07/27/2016
- Re: [Per-Entity] implementing a cache on the client, Jorj Bauer, 07/27/2016
- Re: [Per-Entity] implementing a cache on the client, Nick Roy, 07/27/2016
- Re: [Per-Entity] implementing a cache on the client, Jorj Bauer, 07/27/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 07/27/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 07/28/2016
- RE: [Per-Entity] implementing a cache on the client, Cantor, Scott, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Mitchell, 07/28/2016
- RE: [Per-Entity] implementing a cache on the client, Cantor, Scott, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, David Walker, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, David Walker, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Nick Roy, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Jorj Bauer, 07/28/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 07/28/2016
Archive powered by MHonArc 2.6.19.