Subject: [Uta] DEEP: permanent latching for TLS and domain name reputation

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 11 Nov 2014 16:44:06 -1000

I was asked to echo my comments to the list about timeouts for TLS
latching in the discussion about DEEP.

One of the main reasons that people seem to want timeouts for TLS
latching is because they're worried about "bricking" their domain, or
about setting policies that will affect the domain after it transfers
"ownership" to a new registrant.

Domain names have reputation already, which affects both the current
registrant and any future registrant.  Some examples of domain name
reputation includes inclusion in spam and malware blacklists.

In this case, the possibility of "latching" a domain name into TLS is
just one more piece of reputation that a domain name is likely to carry
across a registration transfer.

The idea that we can have an ongoing reputation that a domain has opted
*into* stronger security guarantees than the default doesn't seem
particularly troubling, given the other reputational factors that zone
registrants already have to deal with.

            --dkg

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 12 Nov 2014 09:29:09 +0200

Hi Daniel,

IMHO, this is a bug in the reputation system rather than a feature. 
Ideally we would like a new domain owner to start with a "clean slate", 
though clearly there is no reasonable way to implement such a scheme.

Moreover, reputation systems also include damping, i.e. reputation may 
change over time.

A few other reasons why I think we should support a timeout for TLS 
latching:

- HSTS has one, and we should be consistent.

- Admins should have a way to deal with server misconfiguration: you 
don't want to support some policy or configuration parameter forever 
just because someone turned it on once.

- This would limit (to some degree) the amount of client-side state. On 
the other hand, if clients implemented their own timeout for cache 
entries, we would get the same effect on security - a window of 
vulnerability - without the server-side benefits.

- If we ever come up with an even more secure mechanism and it gets 
deployed on a particular system, we would like this one to silently expire.

Thanks,
	Yaron

On 11/12/2014 04:44 AM, Daniel Kahn Gillmor wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>