Skip to Content.
Sympa Menu

per-entity - Re: [Per-Entity] deploying TLS on the MDQ server

Subject: Per-Entity Metadata Working Group

List archive

Re: [Per-Entity] deploying TLS on the MDQ server


Chronological Thread 
  • From: IJ Kim <>
  • To: Tom Mitchell <>
  • Cc: Per-Entity Metadata Working Group <>
  • Subject: Re: [Per-Entity] deploying TLS on the MDQ server
  • Date: Thu, 8 Sep 2016 13:51:54 -0400
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:c4jRQxcUIU8x+JTNIrbGy7+tlGMj4u6mDksu8pMizoh2WeGdxc2yYR7h7PlgxGXEQZ/co6odzbGJ4+a9AidZvN6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUj22Dwd+J/z0F4jOlIz3krnqo9yAKzlP0Qa6ZPtXLQm9rQjVsoFCnY5jNq0xxx/hqHFOPe9RwDU7C0iUmkPdxI+T/ZsrpyVSk/Mn68NaV6jmJeI1QaEOX2duCHw8+MC+7UqLdgCI/HZJFzxOyhc=
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

IMO, enabling TLS, specially when the word Trust is attached to it,
might mislead. The current mechanism for delivering metadata securely
is for Ops to sign it and the clients to verify its signature. It's
shared responsibility between Ops and the clients. I think all agrees
on enabling TLS is beneficial to complement the current mechanism for
something like mitigating stale metadata injection attacks. OTOH,
enabling TLS in order to provide *some* trust anchor for the clients
that are not verifying signature might involve more and I think that's
what we are debating about. Compromises on the metadata distribution
server implies compromises on the metadata for them and the security of
the server is the security of the metadata. The concerns with the
server security might include handling of unencrypted TLS private key on
the server, physical access to the server in a co-location, difficulty
of proving the integrity of the metadata on server at any given moment,
and occasional OpenSSL/TLS bugs like Heartbleed. So, the concern is
more people are skipping signature verification believing TLS is good
enough without realizing these weaknesses and probably other
dependencies like DNS or CAs.

I think enabling TLS would be a good thing as long as it can be
communicated that it's not to provide a solution to the clients that not
verifying the signature but to complement the current mechanism. We
might even consider starting with TLS only mdq server since the benefit
is clear and it might be simpler to communicate assuming the overhead on
response time is negligible. A side benefit might be that it eliminates
the possibility of using http without signature verification.

--IJ

On Thu, Sep 08, 2016 at 09:19:20AM -0400, Tom Mitchell wrote:
> I feel like I’m missing something in this TLS debate. Like why there’s
> even a debate. Please illuminate me if that’s the case, and I apologize
> in advance for being dense.
> To me, TLS is standard stuff. I don’t think we’re talking about
> anything more than a TLS certificate like that used
> for [1]https://www.internet2.edu .
> My answers to the relevant deployment questions below would be:
> 1) Any CA in the generally trusted set, with “InCommon RSA Server CA”
> being a likely candidate
> 2) 3 years like the TLS certificate at [2]https://www.internet2.edu is
> fine, whatever is normal for the chosen CA
> 3) Revocation is handled by the CA just as it handles revocation of any
> other TLS certificate
>
> On Sep 8, 2016, at 8:51 AM, Paul Caskey
> <[3]>
> wrote:
> To me, it feels like you may be reading too much into the requirements.
>
> Why not just use a regular InCommon server SSL cert like all the other
> websites?
>
> It mitigates certain attacks, which is what Scott (and others) was
> talking about yesterday.
>
> -----Original Message-----
> From:
> [4]
>
> [[5]mailto:]
> On Behalf Of
> Tom
> Scavo
> Sent: Thursday, September 08, 2016 7:47 AM
> To: Per-Entity Metadata Working Group
> <[6]>
> Subject: [Per-Entity] deploying TLS on the MDQ server
>
> The key word on the subject line is "deploy." Personally, I'm not
> convinced
> that the benefits of TLS outweigh the costs (especially if we tighten
> validUntil) but in order to advance the discussion, let me ask the
> relevant
> deployment questions:
>
> 1) What CA signs the TLS server certificate?
> 2) What is the expiration date on the TLS certificate?
> 3) How do we handle revocation?
>
> I'll give one possible deployment scenario:
>
> 1) The metadata signing key also signs the TLS server certificate.
> 2) TLS certificates are short-lived, on the order of days.
> 3) Revocation is not necessary (since TLS certificates are
> short-lived).
>
> The above deployment has teeth but I'm afraid it is nontrivial to
> implement.
> Are there other deployment scenarios that are easier to implement yet
> meet
> our needs?
>
> Tom
>
> References
>
> Visible links
> 1. https://www.internet2.edu/
> 2. https://www.internet2.edu/
> 3.
> mailto:
> 4.
> mailto:
> 5.
> mailto:
> 6.
> mailto:

--
IJ Kim, Technical Services Group
100 Phoenix Drive, Suite 111
Ann Arbor, MI 48108

Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook



Archive powered by MHonArc 2.6.19.

Top of Page