Subject: [Uta] SMTP STS: Indicating policy for subdomains

From: Vladimir Dubrovin <[email-masked]>
Date: Sat, 14 May 2016 02:37:56 +0300

Sorry if it was already discussed,

Few notes:

1. Current draft does not allow to control STS policy for subdomains. It
means every subdomain which can be used as a recipient's domain must
have it's own policy.mta-sts A-record and _mta_sts TXT record. There are
situations where this is practically impossible, e.g. wildcard domains.
For example, I want MX to accept mail for *.example.com and support STS.
Having policy.mta-sts.*.example.com can be problematic if *.example.com
already exists as e.g. CNAME. In addition, it can lead to overhead in
reporting, because every subdomain generates it's own report as a
separate message.

The proposal is, to include additional field, e.g. "s" with possible "y"
and "n" values into _mta_sts record

sts-subdomains-flag = "y" / "n"
sts-subdomains = "s" *WSP "=" *WSP sts-subdomains-flag

and

"subdomains": boolean (true or false) - apply policy to subdomains.

into STS policy JSON.

 and extend policy search procedure to request / use cached policy from
parent domains (e.g. example.com) if no _mta_sts exists in subdomain (eg
sub.example.com). If nearest parent domain with pubished _mta_sts policy
has s=y in the TXT record and "subdomains":true  in the policy - use
this policy for subdomain and aggregate reporting into parent domain's
report.

2. Standard should specify recommended time for negative policy response
caching for existing domains, overwise it can lead to overload for
DNS/Web infrastructure.

3. Because caching is used, security considerations should mention cache
exhausion attacks by sending messages to a huge number of different
subdomains with STS policies published with  recommendations to limit
records number / cache size per organizational domain (an example of
such limitation can be taken from e.g. RFC 6265 or W3C HTML 5 local
storage specification).

4. Because policy is requested via https from predefined location,
".well-known" URI (RFC 5785) should be used and registered via IANA
instead of "current", e.g. "/.well-known/mta-sts", so IANA
considerations section is required. Using of non-standard locations like
/current makes it harder to maintain / monitor / provide security for
web resources. Using of "policy.mta-sts" hostname prefix is questionable.

P.S. sorry for off-list CC'ing, it looks like list is not DMARC friendly.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 May 2016 00:02:04 +0000

On Sat, May 14, 2016 at 02:37:56AM +0300, Vladimir Dubrovin wrote:

> have it's own policy.mta-sts A-record and _mta_sts TXT record.

And this is unavoidable with STS.  When sending mail to:

	[email-masked]

It would be rather unsafe for the client to "walk up the tree"
looking for STS records in parent domains.  Where should it stop?
"com."?  What about "name." where there are delegations of the
form "foo.name" and "foo.bar.name"?

> There are
> already exists as e.g. CNAME.

That's actually not a problem, CNAMEs have no effect on sub-trees,
so you can have a sub-domain of a CNAME, just not a delegated one:

	*.example.com. IN CNAME ...
	foo.*.example.com.	IN TXT ...

> In addition, it can lead to overhead in

Yes, mail to wildcard sub-domains is mostly a bad idea, and leads
to all sorts of problems.

> sts-subdomains = "s" *WSP "=" *WSP sts-subdomains-flag

Easy enough, but...

> this policy for subdomain and aggregate reporting into parent domain's

This is the part I think is a bad idea.  It is inefficient, and it
is unclear where to stop the search.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 May 2016 00:31:06 -0000

>form "foo.name" and "foo.bar.name"?

This is the issue that the DBOUND working group currently is not
solving.  The usual advice for situations like these is to use the
Mozilla Public Suffix List, which is widely agreed to be the least bad
option if that's what you really want to do.  We all agree that "least
bad" does not mean "good".

>	foo.*.example.com.	IN TXT ...

That probably doesn't do what people want, since foo.*.example.com isn't
a hostname and isn't a wildcard.

DMARC does approximately what has been suggested here, but that's because
it's trying to deal with bad guys forging random subdomains.  STS is dealing
with actual MTAs.  Does anyone really use wildcarded domains in incoming
mail?  I honestly don't know, but I don't think I've ever seen it.

R's,
John

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sat, 14 May 2016 03:44:53 +0300

> form "foo.name" and "foo.bar.name"?
At least DMARC (RFC 7489) already uses recursion like this and it's
generally considered as a safe, because public registries (including
.name) do not allow domains / records with underscores, so _mta_sts can
not be registered in a public registry (see RFC 3696). Generally, it's
safe to stop at second level domain, but in addition, list of known
public suffixes (https://publicsuffix.org/) can be used to avoid
recursion to public domain and above.
> 	foo.*.example.com.	IN TXT ...

DNS RFCs only allow wildcards in leftmost position, so
foo.*.example.com.
doesn't conform to existing standards and AFAIK this syntax is not
supported in bind.

> to all sorts of problems.

There are public mail servers where users historically were allowed to
register subdomains to receive mail in addition to mailboxes.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: "John Levine" <[email-masked]>
Date: 14 May 2016 02:09:43 -0000

>register subdomains to receive mail in addition to mailboxes.

That's true, but that doesn't mean they use wildcards.  The one ISP I know
of that has user subdomains, panix, doesn't use wildcards.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 May 2016 04:07:45 +0000

On Sat, May 14, 2016 at 03:44:53AM +0300, Vladimir Dubrovin wrote:

> > > There are situations where this is practically impossible, e.g. wildcard
> > > domains.  For example, I want MX to accept mail for *.example.com and
> > > support STS.  Having policy.mta-sts.*.example.com can be problematic if
> > > *.example.com already exists as e.g. CNAME.
> >

This is not true.  See this live for example at:

    $ dig +noall +ans +nocl +nottl -t a "*.foo.msmuxy.org."
    *.foo.msmuxy.org.       CNAME   mx1.msmuxy.org.
    mx1.msmuxy.org.         A       38.117.134.19

    $ dig +noall +ans +nocl +nottl -t txt "_smtp-sts-policy.*.foo.msmuxy.org."
    _smtp-sts-policy.*.foo.msmuxy.org. TXT "This is a test"

The BIND source of the zone file has:

    *.foo                   IN CNAME mx1
    _smtp-sts-policy.\*.foo IN TXT "This is a test"

> > > In addition, it can lead to overhead in reporting, because every subdomain
> > > generates it's own report as a separate message.
> >

There should be a specific registration of each such domain.
Instead of wildcard MX records, publish explicit MX records for
each such domain, and STS records as necessary.

DANE works better here, because the security data is published with
the MX host, not the nexthop domain, which only needs (DNSSEC
validated) MX records, wildcards are OK.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 May 2016 04:13:18 +0000

> a hostname and isn't a wildcard.

Indeed this definitely not a wildcard, it is just an atypical DNS
name.  Any queries for this name have to use a literal "*".  So
indeed if the intention was to have this match any sub-domain in
the middle, that won't work.

-- 
	Viktor.

---

From: Gihan Dias <[email-masked]>
Date: Sat, 14 May 2016 12:00:33 +0530

On 2016-05-14 පෙ.ව. 9:43, Viktor Dukhovni wrote:
> name.
Is it an *atypical* DNS name, or an *invalid* DNS name?

Gihan

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 May 2016 02:38:38 -0400

> On May 14, 2016, at 2:30 AM, Gihan Dias <[email-masked]> wrote:
> 

It is completely valid, just not a valid hostname.  DNS supports
arbitrary binary data in record owner labels.  In any case, since
this does not do what the OP wanted from it, further dissection of
this is moot.  I should have followed up with a technically correct,
but irrelevant correction.  Sorry about that.

-- 
	Viktor.

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sat, 14 May 2016 12:02:17 +0300

Anyway, having ability to apply STS to subdomains is important to
protect hostnames and domains unused for mail or non-existant. This kind
of attack is possible:

Bob has this DNS (quite typical) records for example.org zone:

@ MX 10 mx1
mx1 A 10.1.1.1

and additional STS records:

policy.mta-sts A 10.1.1.2
_mta_sts TXT "v=STS1 id=42"

Alice has active MitM for Bob's MX.

1. Alice makes certificate request for mx1.example.org to any public CA
choosing [email-masked] as a validation address
Because Bob does not expect any mail to be received for
@mx1.example.org, he has no separate STS policy for this domain. 'A'
record is enougth to receive mail for @mx1.example.org.
2. Alice hijacks validation e-mail for [email-masked] and
confirms certificate.  Now she has valid certificate for mx1.example.org
3. Now, Alice can intercept any mail for example.org despite of STS

Having STS applied to subdomains, allows certificate authorities to
pre-load /  pre-cache  SMTP STS policies for SMTP STS preloaded domains
/ HSTS preloaded domains / domains with issued certificates /
top-1000000 domains / etc to mitigate attack.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Gihan Dias <[email-masked]>
Date: Sat, 14 May 2016 17:44:58 +0530

On 2016-05-14 ප.ව. 12:08, Viktor Dukhovni wrote:
> arbitrary binary data in record owner labels.
Viktor,

Thanks.

Gihan

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 15 May 2016 14:58:52 +0200

> 3. Now, Alice can intercept any mail for example.org despite of STS

Interesting point.

I think you're right that this would work for many (most? all?) CAs that do
email-based domain ownership validation. Whether this is within the scope
of what STS should address (in that we generally are assuming CA certs are
trustworthy) I am not sure. And domain walking (as Viktor said) seems a bit
crude to me, after all.

---

From: "John R Levine" <[email-masked]>
Date: 15 May 2016 09:48:19 -0400

> email-based domain ownership validation.

I was surprised to find he's right -- if you ask for a cert for 
foobar.example.com, typical CAs will let you validate via any of the WHOIS 
contacts for example.com or else [email-masked].

That makes sense under the assumption that mail to that address is no less 
secure than mail to [email-masked].  This is still a fairly exotic 
threat, since it still requires some fairly good DNS or route hijacking 
against the CA.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 15 May 2016 16:14:49 +0200

Vladimir:

Presumably policy.mta-sts could be redirected to the bare domain. I guess
indicating to use this or not in the TXT would save people who have trouble
configuring sub-domains; it's not clear to me how hard this is in most
domain management tools and whether that justifies the complexity of adding
this in the TXT. (The counterargument to any subdomain is that we may wish
to specify that the cert matching on the HTTPS endpoint should match
example.com and *not* the subdomain, which was also discussed in some prior
threads.)

I have no qualms about using .well-known in all cases. We just omitted that
when we switched to the specific host. But there's no downside, I agree,
and a potential upside if the host redirects to the bare domain.

John:

Yes, I think one could argue that this is a flaw in the cert validation,
but it's also a flaw that comes into focus largely because of the STS
scheme. (It's a facet of not requiring a specific cert for the MX and not
having a policy that applies to sub-domains, basically.)  So who should
change what to fix it is not clear to me--we can expect CAs to be more
cautious or we can change STS in some manner to address this. But parent
domain walking strikes me as a rather unpleasant fix, still. (Key pinning,
as discussed in "Future Work", would be another option here, but it has its
own downsides, mostly in the realm of self-inflicted foot injuries, I
think.)

On Sun, May 15, 2016 at 3:48 PM, John R Levine <[email-masked]> wrote:

> foobar.example.com, typical CAs will let you validate via any of the
> WHOIS contacts for example.com or else [email-masked].
>
> secure than mail to [email-masked].  This is still a fairly
> exotic threat, since it still requires some fairly good DNS or route
> hijacking against the CA.
>
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 15 May 2016 10:42:21 -0400

> So who should change what to fix it is not clear to me--we can expect 
> CAs to be more cautious or we can change STS in some manner to address 
> this. But parent domain walking strikes me as a rather unpleasant fix, 
> still.

Agreed.  You can do what DMARC does, use the PSL or approved replacement 
to figure out where the parent is.  It's gross, but it works pretty well.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 May 2016 12:06:46 -0400

> On May 15, 2016, at 8:58 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Interesting point. 
> 
> I think you're right that this would work for many (most? all?) CAs that do email-based domain ownership validation. Whether this is within the scope of what STS should address (in that we generally are assuming CA certs are trustworthy) I am not sure. And domain walking (as Viktor said) seems a bit crude to me, after all. 

Domains with wildcard MX records that want active-attack resistant SMTP
transport security should do DANE.  This works without requiring any
parent-domain policy walking.

	*.example.net. IN MX 0 smtp.example.net.
	smtp.example.net. IN A 192.0.2.1
	_25._tcp.smtp.example.net. IN TLSA 3 1 1 <server-public-key-digest>
	_25._tcp.smtp.example.net. IN TLSA 2 1 1 <issuer-piblic-key-digest>

DNSSEC protects the integrity of the wildcard MX and the TLSA RRs for the shared
MX host.  No kludgey tree-walking required.

STS should not specify parent-domain lookups, it is already complex/fragile
enough.

-- 
	Viktor.

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sun, 15 May 2016 23:44:30 +0300

Viktor Dukhovni пишет:
> Domains with wildcard MX records that want active-attack resistant
> SMTP transport security should do DANE.  
I may be wrong (please correct me), but as far as I can see, DANE does
not provide any additional caching mechanism and relies on DNS caching
only. DNS caching is usually very limited in time (e.g. 7 days by
default in bind, 1 day in Microsoft DNS server, see max_cache_ttl /
MaxCacheTtl and even less for local caching) and DANE does not explains
what to do if TLSA records lookup fails due to MitM. For me, DANE is a
way to avoid authentication with public CA infrastructure (it sounds
funny, but currently public CA infrastructure is not protected against
even passive MitM, because domain validation process is vulnerable to
MitM) but DANE does not replace STS in any way, because long time policy
caching is a main feature of STS.

That's additional reason for subdomains in STS, because it increases a
change for policy to be obtained from cache.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 May 2016 17:00:56 -0400

> On May 15, 2016, at 4:44 PM, Vladimir Dubrovin <[email-masked]> wrote:
> 
> I may be wrong (please correct me),

Not so much wrong as "not even wrong".  The DANE TTL is largely irrelevant
and should be reasonably short to allow mistakes to be fixed quickly.

> but as far as I can see, DANE does
> only.

This is a feature, changes to the record propagate as the TTL expires.

> DANE does not explains
> what to do if TLSA records lookup fails due to MitM.

*This* is where you're wrong, see https://tools.ietf.org/html/rfc7672#section-2.1
The error behaviour for SMTP with DANE *is* specified, and avoids
downgrade attacks.

> For me, DANE is a way to avoid authentication with public CA
> infrastructure

Many DANE domains have certificates from public CAs, though DANE
clients don't use the local trust-store when checking these...

> (it sounds funny, but currently public CA infrastructure is not protected against
> MitM)

Indeed, DV is weaker than DNSSEC, where at least control of the domain is
established via the registrar account that controls the domain.

> but DANE does not replace STS in any way, because long time policy

This conclusion is based on an incomplete/incorrect knowledge of DANE SMTP.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 May 2016 17:50:23 -0400

> On May 15, 2016, at 5:00 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
>> DANE does not explains

By way of example, the folks at isphuset.no host a handful of DNSSEC
domains, but use an outdated version of PowerDNS that is not capable of
correct DNSSEC denial of existence.  Therefore, when they report that
TLSA records don't exist for one of those domains, it looks like an MiTM
attack ("bogus" denial-of-existence proof).

http://dnsviz.net/d/_25._tcp.amihotel.no/dnssec/

With DANE enabled, Postfix connections to these domains fail.

$ posttls-finger amihotel.no
posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.amihotel.no type=TLSA: Host not found, try again
posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.amihotel.no type=TLSA: Host not found, try again
posttls-finger: Failed to establish session to amihotel.no via amihotel.no: TLSA lookup error for amihotel.no:25

I reported the problem to them on 4/Aug/2015, they're "working on it".
I expect there's a chance it'll be fixed by 4/Aug/2016.

Similarly, the nameservers of patriotguard.org are misguidedly configured to
drop TLSA queries as a security^Wignorance feature in a firewall to
protect^Wbreak the nameservers.  This too resembles an MiTM attack:

http://dnsviz.net/d/_25._tcp.svcs.patriotguard.org/dnssec/

$ dig -t tlsa _25._tcp.svcs.patriotguard.org ...
;; connection timed out; no servers could be reached

$ dig -t a _25._tcp.svcs.patriotguard.org ...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1607
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
;_25._tcp.svcs.patriotguard.org.        IN A
patriotguard.org.       SOA     ns1.patriotguard.org. root.patriotguard.org. 2016033101 1200 120 2419200 60
... signatures, NSEC3 RRs, ...

And again Postfix avoids the downgrade attack:

$ posttls-finger patriotguard.org
posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.svcs.patriotguard.org type=TLSA: Host not found, try again
posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.svcs.patriotguard.org type=TLSA: Host not found, try again
posttls-finger: Failed to establish session to patriotguard.org via svcs.patriotguard.org: TLSA lookup error for svcs.patriotguard.org:25

Out of ~530,000 DNSSEC domains surveyed, I have a list of ~200 that fail due
to defective DNS support that is indistinguishable from a downgrade attack.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 16 May 2016 05:40:05 +0200

On Sun, May 15, 2016 at 6:06 PM, Viktor Dukhovni <[email-masked]>
wrote:

> transport security should do DANE.
>

I don't think the attack has anything to do with wildcard MXs, though I may
be mistaken. To be a little more concrete, what I think would work (at
least with some CAs) is:

Given example.com with some fairly mundane STS policy and a (valid) MX for
example.com of "mx1.example.com" and an attacker who can temporarily inject
arbitrary DNS records for the example.com zone, the attacker:

1. Creates an MX for mx1.example.com that points to the attacker's MX
2. Receives some domain validation email at "[email-masked]"
3. Receives a valid cert for "mx1.example.com"

So this looks something like

example.com. IN MX 0 mx1.example.com.  # Legit.
> mx1.example.com. IN MX 0 evilsmtp.attacker.com.   # EVIL!

The point is that because example.com had no STS policy for subdomains, the
attacker is able to temporarily create a subdomain that overlaps with the
actual hostname of the valid MX, receive a cert for it, and thus be able to
receive mail for the parent domain by impersonating the MX.

Is there some reason that doesn't work?

(Anyway, like I said before, I agree domain walking is pretty terrible; one
could also consider this a fixable problem with domain ownership
validation.)

Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 May 2016 00:01:20 -0400

> On May 15, 2016, at 11:40 PM, Daniel Margolis <[email-masked]> wrote:
> 
> I don't think the attack has anything to do with wildcard MXs, though I may be mistaken.

The original discussion was how to provide transport security for domains that
have lots of sub-domains receiving mail via a wildcard MX record.  My point is
that DANE handles this.

As for CAs, their DV validation outbound MTAs very rarely (typically just once
and never again) send traffic to any given domain, and STS policy simply does
not help with first contact against an active attack at time of certificate
issue.

I don't think STS can address this problem, certificate transparency is your
main hope for catching the problem after the fact.

One might attempt to convince the CAs to implement DNSSEC-validating resolvers
and do DANE outbound... Then some domains would have better protection against
DV forgery.  Though there's the leap of faith via unauthenticated HTTPS.

DV certificate issuance is fundamentally insecure against MiTM at time of issue.

-- 
-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 16 May 2016 06:04:30 +0200

Yes, agreed. To be very slightly nitpicky, I would say this is ever so
slightly worse in that even if the CA has sent mail to example.com in the
past, they probably did not send mail to "mx1.example.com", so the
opportunity to create a bootstrapping scenario remains. But in general I
think we're saying the same thing--that this is a problem with domain
verification, and not something to solve here.

Dan

On Mon, May 16, 2016 at 6:01 AM, Viktor Dukhovni <[email-masked]>
wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 May 2016 04:22:19 +0000

On Mon, May 16, 2016 at 06:04:30AM +0200, Daniel Margolis wrote:

> But in general I

Yes, except that I would put it more strongly. This is a problem
which we do and must pretend does not exist with "domain validated"
certificates.  DV is a leap-of-faith by design, and the problem
must simply be swept under the rug as outside the thread model.

The only "solutions" are EV, which fails to scale, or CT which only
provides forensic evidence after the fact.  The latter might deter
attackers who are reluctant to leave a trail of evidence of their
activity, though in practice all one learns is which CA got fooled,
not who did it.  If the CA was not negligent or complicit, there's
little recourse.  One learns of the existence of MiTM, but not
who's behind it.

-- 
	Viktor.

---

From: Vladimir Dubrovin <[email-masked]>
Date: Mon, 16 May 2016 12:04:19 +0300

Daniel Margolis пишет:
> slightly worse in that even if the CA has sent mail to example.com
> <http://example.com> in the past, they probably did not send mail to
> "mx1.example.com <http://mx1.example.com>", so the opportunity to
> create a bootstrapping scenario remains. But in general I think we're
> saying the same thing--that this is a problem with domain

You can not rely on CA for SMTP security and deny the problem  of
insecure validation due to inability to provide secure domain
verification via SMTP by CA in the same time.

The problem of domain verification can (and is intended to) be mitigated
with STS for http/smtp validation, but it means CA must be capable to
use STS with STS preloading or STS precaching. You can require CAs to
e.g. use Mozilla STS preloaded list to be included into Mozilla root CAs
in future, but STS policy preloading is only useful if you can specify
policy for subdomains.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 May 2016 08:32:13 -0400

> On May 16, 2016, at 5:04 AM, Vladimir Dubrovin <[email-masked]> wrote:
> 
> You can not rely on CA for SMTP security and deny the problem  of insecure validation due to inability to provide secure domain verification via SMTP by CA in the same time.

Sure we can.  The emperor's clothes are spectacular!  The WebPKI
manufactures DV trust ex nihilo and the subject pays accordingly.
And the ACME tailoring company's machinery makes the finest cloth.

This spectacle is not restricted to STS. HTTPS, except for a few
large sites with EV certs, has exactly the same security model.
The MiTM needs to be on path between the CA and the remote server
at the time the DV leap of faith is performed and notarized by the
CA.

> The problem of domain verification can (and is intended to) be
> mitigated with STS for http/smtp validation, but it means CA
> must be capable to use STS with STS preloading or STS precaching.
> You can require CAs to e.g. use Mozilla STS preloaded list to be
> included into Mozilla root CAs in future, but STS policy preloading
> is only useful if you can specify policy for subdomains. 

Now you're saying the emperor has no clothes, you must not be looking
hard enough!

-- 
-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 May 2016 17:56:35 +0000

> http://dnsviz.net/d/_25._tcp.svcs.patriotguard.org/dnssec/

Wow!  Just one day after posting the above the domain's nameservers
no longer block TLSA lookups. Though they still mishandle denial
of existence for the AAAA records of the MX host:

    http://dnsviz.net/d/svcs.patriotguard.org/dnssec/?rr=28&a=all&ds=all&ta=.&tk=

that error does not impede mail delivery.  So sometimes the best
notification channel is a public forum.  I first tried WHOIS, ...
over a year ago with no luck).  Sadly, turning the UTA WG list into
a broadcast DNS misconfiguration notification system would not be
appropriate, but this does demonstrate the importance of effective
notification channels.

So anyone trying to reproduce bad DNS responses will need a new
test domain.  The list below incudes 121 TLSA RR qnames for which
at least some of the nameservers malfunction.  This should provide
enough examples for a while.  I doubt the whole list will be fixed
by tomorrow!  (For example, I first notified truman.edu in Nov
2014, I don't expect a miracle today. :-)

    _25._tcp.ccbfinancial.bank
    _25._tcp.countryclub.bank
    _25._tcp.countryclubbank.bank
    _25._tcp.marquettesavings.bank
    _25._tcp.mail.mit-solutions.be
    _25._tcp.synn.be
    _25._tcp.bb.b.br
    _25._tcp.mailhost1.dpf.gov.br
    _25._tcp.mailhost2.dpf.gov.br
    _25._tcp.pf.gov.br
    _25._tcp.mail.m3ganet.net.br
    _25._tcp.86francisstreet.com
    _25._tcp.mail.act85.com
    _25._tcp.mail.bernheimmansion.com
    _25._tcp.mail.bestregistrar.com
    _25._tcp.mail.bmwlemon.com
    _25._tcp.mail.c-a-s-i.com
    _25._tcp.mx1.conso-acteur.com
    _25._tcp.dmgznet.com
    _25._tcp.dnssec-fisglobal.com
    _25._tcp.doorgroeikansen.com
    _25._tcp.mail.dotshop.com
    _25._tcp.fluxometer.com
    _25._tcp.fnfis.com
    _25._tcp.gearfun.com
    _25._tcp.howbacha.com
    _25._tcp.mailip.lease-admin.com
    _25._tcp.ouracnetreatment.com
    _25._tcp.mailip.pfsc.com
    _25._tcp.procodis-france.com
    _25._tcp.psychomario.com
    _25._tcp.mail.realmansolympics.com
    _25._tcp.mail.relyapawn.com
    _25._tcp.safeoffice.com
    _25._tcp.mailip.servicerplus.com
    _25._tcp.short-street.com
    _25._tcp.slowlicks.com
    _25._tcp.thedashingbadger.com
    _25._tcp.upmccancercenter.com
    _25._tcp.mail.watchevents.com
    _25._tcp.878.cz
    _25._tcp.administruji.cz
    _25._tcp.autokey.cz
    _25._tcp.bdsoft.cz
    _25._tcp.botanix.cz
    _25._tcp.canson.cz
    _25._tcp.dido.cz
    _25._tcp.fermontplus.cz
    _25._tcp.fosfa.cz
    _25._tcp.hnatik.cz
    _25._tcp.hobbypoint.cz
    _25._tcp.hvideo.cz
    _25._tcp.klempirsky-eshop.cz
    _25._tcp.mediastyle.cz
    _25._tcp.obleceni-hracky.cz
    _25._tcp.pastorovi.cz
    _25._tcp.pod1.cz
    _25._tcp.pozorkliste.cz
    _25._tcp.silper.cz
    _25._tcp.talka.cz
    _25._tcp.toxik.cz
    _25._tcp.mail.solarscale.de
    _25._tcp.pilot.jhuapl.edu
    _25._tcp.piper.jhuapl.edu
    _25._tcp.barracuda.truman.edu
    _25._tcp.bed4baby.eu
    _25._tcp.demius.eu
    _25._tcp.upanel.eu
    _25._tcp.ironport1.jobcorps.gov
    _25._tcp.ironport2.jobcorps.gov
    _25._tcp.23systems-dev.net
    _25._tcp.mx.admings.net
    _25._tcp.mailky.b2.net
    _25._tcp.mailky.cas-com.net
    _25._tcp.mail.ecwr.net
    _25._tcp.mail.mcso.net
    _25._tcp.vps1.mctherealm.net
    _25._tcp.mx1.psyclonecontacts.net
    _25._tcp.mx2.psyclonecontacts.net
    _25._tcp.twitterdex.net
    _25._tcp.cameras-kopen.nl
    _25._tcp.xchange.caramelo-media.nl
    _25._tcp.mail.de-garage.nl
    _25._tcp.mail.denver-electronics.nl
    _25._tcp.g13.nl
    _25._tcp.gdl.nl
    _25._tcp.mail.howit.nl
    _25._tcp.htbl.nl
    _25._tcp.mail.jecom.nl
    _25._tcp.mail.mautiv.nl
    _25._tcp.mail.mediagardeserver.nl
    _25._tcp.smtp.mwalet.nl
    _25._tcp.o365.nl
    _25._tcp.pe1br.nl
    _25._tcp.mail.simbi.nl
    _25._tcp.mail.studentrecruiter.nl
    _25._tcp.studiobeerens.nl
    _25._tcp.mail.time2track.nl
    _25._tcp.tt-forum.nl
    _25._tcp.ttclub.nl
    _25._tcp.ttforum.nl
    _25._tcp.upanel.nl
    _25._tcp.vrijeuitgevers.nl
    _25._tcp.mail.vvbeta.nl
    _25._tcp.mail.wheelking.nl
    _25._tcp.xnyhps.nl
    _25._tcp.mail01.sigterm.no
    _25._tcp.mail.roffe.nu
    _25._tcp.magister.ovh
    _25._tcp.exedge1.saudipost.post
    _25._tcp.smtp.saudipost.post
    _25._tcp.mailgw.ap2.se
    _25._tcp.cloud.ekenberg.se
    _25._tcp.dator.ekenberg.se
    _25._tcp.12.mindsolution.se
    _25._tcp.nllplus.se
    _25._tcp.shellvik.se
    _25._tcp.mail.statskontoret.se
    _25._tcp.mail.stm.com.tw
    _25._tcp.mail.mof.gov.tw

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 19 May 2016 18:30:34 +0700

> On 16 May 2016, at 11:22, Viktor Dukhovni <[email-masked]> wrote:

Which is exactly the reason why I've repeatedly pushed for an extensible feedback mechanism in for the related reporting draft.

...

Aaron