Per-Entity Metadata Working Group

[David Walker <>]

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

Attachment: signature.asc
Description: OpenPGP digital signature