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:
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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
