On 4/11/16 1:45 PM, Stephen Farrell wrote: > - We can, and probably will, define a "webby" to achieve > the same desired effect of getting beyond opportunistic > security. Daniel and co's STS aprooach (as outlined for > the next revision in B-A) is one such, and seems like > it's one that can work.
As I remember, there were still some issues with how the lookup would take place (what the URL would be): some sort of reserved hostname was seen to be a non-starter, and I seem to remember that there was some issue with .well-known as well, but can't remember the specifics. Another issue I'm not sure we discussed is the handling of wildcard MX records: if I send a message to [email protected], and there is an MX record for *.example.com, do I look for the policy at foo.example.com, or do I notice that there was a wildcard MX and use the next higher domain? I suppose that might work. But I'm still not 100% comfortable that there's a good "webby" approach to finding the policy in all cases. > - Any such webby approach will inherently involve us in > re-inventing a lot of what we get from DANE/DNSSEC. That's > a bit of a pain, but inevitable and not a reason to not > do STS. (The goal here is not perfection but to enable > folks to do better than opportunistic security after all.) > - My guess is that the webby approach will end up being > a bit less secure/safe compared to the DANE/DNSSEC way > of doing things, mostly due to it having to depend on > some kind of TOFU step that gets repeated whenever DNS > without DNSSEC is used (i.e. when something cached > expires). The risk is that the sender won't find the policy at all if the web address lookup fails. But can we agree that the long MTU approach described in the current draft isn't an effective mitigation to that problem? Several people pointed out in the meeting that caches don't typically hold things for very long times; the MTU specifies how long records MAY be cached, not how long they SHOULD be cached. My concern here is that if it's possible for intermediaries (for example, firewalls at the enterprise and national level that currently interfere with STARTTLS negotiation) to interfere with STS lookups, all we will have done is to ask them to implement a new blockage feature, and we haven't actually improved security. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
