Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

[Jim Fenton <[e-mail]>]

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 [e-mail], 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