On Sat, Apr 30, 2016 at 10:29:30PM -0000, John Levine wrote:
> >> I'm quite uncomfortable with the bit that says you look up the policy
> >> at https://policy._mta_sts.example.com/current
> >
> >That's surely a mistake. It should have been a ".well-known"
> >URI at the domain with no prefixes.
>
> We talked about this at great length over dinner in Buenos Aires.
> Demanding a web server at the same domain name used in e-mail
> addresses is operationally a non-starter for large organizations.
STS is primarily for the large email providers authoring the draft,
for whom this is not a real obstacle. Making it convenient for
all other domains might be nice, but is less important. Not all
domains will adopt STS regardless of the specification.
> >> _sts._tcp SRV 0 0 443 sts-policy.example.com.
>
> > No, SRV records break the security model, because untrusted DNS now
> > supplies the reference identifier. The URI needs to be entirely
> > determined from the nexthop domain with no insecure inputs.
>
> In the absence of DNSSEC, there's *always* insecure inputs, such as
> the A or AAAA records that point to the web server.
Spoofing of A records are irrelevant, the WebPKI certificate binds
the name, and assures the client that the correct server has been
reached.
> As the next two sentences said:
>
> Bad guys could spoof your SRV record without DNSSEC, but they can also
> spoof the A record for policy._mta_sts.example.com so that horse left
> the barn.
Spoofing of A records is irrelevant, the client detects the forgery
when the certificate fails to match. Not so with SRV records,
because (presumably) the reference identifier becomes the target
hostname from the SRV record.
> You could require that the target of the SRV has to be a
> subdomain of the original domain which, along with the signed SSL
> certificate, would limit the scope of evil.
This does not adequately address the problem, domains do not
generally control (or trust) all the content hosted by their
sub-domains. This is why a well known URI anchored at the
original domain is needed.
> >This is not a good idea, such names will be rejected by some systems.
>
> Got any examples? I haven't looked very hard either way. Note that
> nothing should be trying to turn it into a U-label.
No example at my fingertips. All kinds of software performs hostname
validation, whether there's a conversion to U-labels or not. It
is not a good idea to tempt fate with invalid inputs.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
