Per-Entity Metadata Working Group

[Scott Koranda <>]

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