Per-Entity Metadata Working Group

[Paul Caskey <>]

OK, I can’t disagree with you in that case.

 

I wonder how we could analyze just how much latency would be “acceptable” (whatever that word means)…

 

 

 

From: David Walker
Sent: Tuesday, September 06, 2016 5:44 PM
To: Paul Caskey <>;
Subject: RE: [Per-Entity] HTTPS transport and TLS trust

 

I'm not saying we don't need caching, only that we also need to worry about latency.

David

On September 6, 2016 2:50:37 PM PDT, Paul Caskey <> wrote:

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: [] 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

 

 

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.