Per-Entity Metadata Working Group

[Paul Caskey <>]

Glad to hear that we're coming to the conclusion that latency is a non-issue. 
 I agree about the user experience, though I wouldn't mind much if the first 
user (only) noticed a minor difference (and I would assume that caches could 
be pre-loaded with important SPs).

To the extent that's true, then I would question the need for a CDN, as 
opposed to a normal highly-available infrastructure (which would be less 
expensive to operate).



> -----Original Message-----
> From: Scott Koranda 
> [mailto:]
> Sent: Tuesday, September 06, 2016 5:52 PM
> To: Paul Caskey 
> <>
> Cc: David Walker 
> <>;
>  
> 
> Subject: Re: [Per-Entity] HTTPS transport and TLS trust
> 
> Hi Paul,
> 
> I don't think the CDN latency is a problem.
> 
> My first reaction when I saw Patrick's quick numbers was "great--that helps
> us understand that the latency is not really going to be an issue".
> 
> I thought that not only because the numbers were relatively small, but also
> because their overall contribution to the time it takes for a relying party 
> to
> complete a SAML SSO web flow is minor.
> 
> My argument is this: the only truly important metric is the user experience.
> Users simply cannot notice a difference between using an aggregate and
> per-entity metadata.
> 
> The time the user "sees" and cares about is the time it takes to go through 
> a
> SSO flow start to finish.
> 
> That time is not going to be dominated by the latency involved in either (or
> both) the IdP or the SP performing an MDQ query running on the types of
> infrastructures we have been quickly investigating.
> 
> There are a lot of steps in the flow that take about the same amount of time
> or longer than a single MDQ query.
> 
> And as you point out, that is especially true since the codes (Shibboleth 
> and
> SimpleSAMLphp initially and others eventually) will be caching so there will
> be many flows that do not involve any MDQ query at all.
> 
> If anyone disagrees with that simple analysis please let me know.
> 
> The continued discussion on latency and gathering more numbers and more
> data is fine, but I don't see that they change anything about the approach 
> we
> will recommend.
> 
> Again, if anyone disagrees please say so, but my conclusion after seeing the
> numbers and understanding how clients will cache (per our earlier
> discussions) is that an InCommon MDQ service built on a commercial CDN is
> going to work well.
> 
> Thanks,
> 
> Scott K
> 
> > True, but I’m struggling to understand why we seem to be making
> > metadata retrieval more fragile than DNS.
> >
> > From: David Walker
> > Sent: Tuesday, September 06, 2016 4:44 PM
> > To: Paul Caskey 
> > <>;
> >  
> > 
> > Subject: Re: [Per-Entity] HTTPS transport and TLS trust
> >
> >
> >
> > Caching helps only for entities that are used more often than the
> > cache timeout, and it helps only a little unless those entities are
> > used a lot more often.
> >
> > David
> >
> >
> >
> > On 09/06/2016 02:28 PM, Paul Caskey wrote:
> >
> >     IMHO, we must get over the latency-as-a-problem with this model
> (clients
> >     should cache).
> >
> >
> >
> >
> >
> >
> >
> >     From: 
> > 
> >  [
> >     
> > mailto:]
> >  On Behalf Of David Walker
> >     Sent: Tuesday, September 06, 2016 4:24 PM
> >     To: 
> > 
> >     Subject: Re: [Per-Entity] HTTPS transport and TLS trust
> >
> >
> >
> >     Stepping back a bit...
> >
> >     I don't see why we need to provide multiple ways for clients to 
> > verify the
> >     metadata, particularly since we consider one to be reasonably strong,
> and
> >     the other not so much.  We have no guarantee that a metadata client
> >     (per-entity or aggregate) is checking signatures, anyway.  Since 
> > there's a
> >     cost to https (in terms of latency), I would say don't support it.
> >
> >     However, it's my understanding that ADFS requires https, independent
> of
> >     security or trust.  If that's the case, I'd be tempted to tell people 
> > they
> >     can use either http or https, but that they'll get lower latency with 
> > http,
> >     and the authenticity of the metadata they get should be verified from
> the
> >     signatures it contains, not from the transport.
> >
> >     David
> >
> >
> >
> >     On 09/06/2016 01:52 PM, Cantor, Scott wrote:
> >
> >             Just for the background information, another concern was
> > the server
> >
> >             security which is assumed in TLS.  I'm not suggesting
> > md.incommon.org is
> >
> >             not secure but it was difficult to quantify and it was
> > certainly less
> >
> >             secure than the signing operation.  Ops also wanted to
> > reserve the
> >
> >             flexibility of hosting its stand-by servers in
> > co-locations without
> >
> >             special requirements on its physical security.
> >
> >
> >
> >         Right, that's the fundamental difference.
> >
> >
> >
> >         Signing Pro:
> >
> >         - self-contained / portable security model
> >
> >         Con:
> >
> >         - subject to MITM threats
> >
> >
> >
> >         Transport Pro:
> >
> >         - end to end security
> >
> >         Con:
> >
> >         - highly dependent on physical deployment characteristics that
> > are difficult to replicate widely
> >
> >
> >
> >         I wouldn't necessarily argue that both don't have their place, 
> > but we
> implement both and long experience has led us to believe that it's better to
> attack the MITM problem with signing somehow than give up the flexibility.
> >
> >
> >
> >         I think probably the best option is to sign, use TLS, but not go
> overboard trying to lock down the TLS part. That provides reasonable
> protection against low-cost active attacks without relying on it 
> exclusively.
> >
> >
> >
> >         -- Scott
> >
> >
> >
> >
> >
> >
> >