Per-Entity Metadata Working Group

[Tom Scavo <>]

On Thu, Sep 8, 2016 at 1:51 PM, IJ Kim 
<>
 wrote:
> 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.

+1

(IJ and I have always been on the same page with respect to this issue)

> 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.

I don't think it's that simple. There are at least three distinct
groups of deployments to consider:

1) Deployments that refresh and verify metadata at least daily
2) Deployments that do not refresh and verify metadata because their
SAML software is misconfigured (intentionally or otherwise)
3) Deployments that do not refresh and verify metadata because their
SAML software doesn't support it

The first group of deployments would (marginally) benefit from
commercial TLS that prevented man-in-the-middle attacks. Btw, a
similar benefit could be obtained by shortening the validity window on
metadata, so we need to include that open issue with this TLS issue.

The third group of deployments include AD FS, Ping, and perhaps
others. There aren't very many of these in InCommon but we do want to
be inclusive. In any case, commercial TLS is not the answer for this
group of deployments. I believe something stronger is needed.

The second group of deployments includes many of the deployments we
were discussing in the other thread. A significant proportion of site
administrators just don't get it, so they throw up their hands and do
nothing. It's probably too much to expect that a TLS option will
address this group as well, but that's the hope.

> 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.

I won't rule out any option at this point but at first glance that
seems iffy to me.

Tom

> 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