Per-Entity Metadata Working Group

[Scott Koranda <>]

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

To accomodate InCommon Participants that use ADFS as either
their IdP or SP and who want to obtain metadata for specific
entities in what is considered by them as the "natural way".

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

There is a cost in latency only to those who decide to use
HTTPS as the transport.

It is unlikely those same consumers will be at all concerned
about the extra latency using HTTPS transport since, as was
pointed out, they will not really be doing "per entity"
metadata (at least not initally).

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

That was my thinking.

The InCommon MDQ service would operate both HTTP and HTTPS,
and serve XML signed per-entity from both, but only recommend
the HTTPS transport for ADFS clients.

I brought up the issue to try and understand if the benefits of
*additionally* offering HTTPS as a transport (primarily making
it easier for ADFS to consume some InCommon metadata) was
worth the costs.

It is probably not within scope for this working group to make
that recommendation, but it would be nice if we could offer in
the report enough information and frame the issue clearly
enough so that another group (TAC?) could make the decision on
whether the costs are worth the benefits.

Thanks,

Scott K

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