Subject: Re: [Uta] draft-brotman-mta-sts/

From: Stephen Farrell <[email-masked]>
Date: Sun, 1 May 2016 11:29:44 +0100

On 01/05/16 02:26, John Levine wrote:
>>> 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.
> 
> They were there at dinner Buenos Aires, and that is most definitely
> not what they said.  Perhaps they'll chime in when they get to work
> on Monday.
> 
> Indeed, it's pretty much the opposite -- on my tiny FreeBSD box I can
> set up the web servers to do whatever I want, but at big organizations
> the mail and web operators are often in different silos.

Wouldn't the same argument tend to indicate SRV or a sub-domain are
as troublesome, given in many enterprises, mail and DNS can be in
different silos? After all, isn't that the core of the stated argument
for not doing DANE/DNSSEC? While putting up a sub-domain or an SRV
might be easier than signing the DNS, putting up a .well-known also
isn't hard.

I suspect we're in a place here where there's no answer that's not
a bit of work for someone whose job is primarily not email. And as
the pain involved will vary based on loads of things even down to
the specific personnel involved, I'm not sure how the WG can make a
good choice there other than by trying to poll operators or maybe
by measuring, if there's some other sufficiently similar webby
thing often done for email services.

S.

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

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 1 May 2016 13:50:26 +0200

Hi,

A few things:

1. Yes, this is a mistake. We had intended to move to a subdomain for the
reasons John stated and didn't realize that, despite being valid in A
records, underscores are not valid in HTTP URI hostnames (at least this is
as far as I can tell).

2. As Viktor says, the SSL certificate name is what mitigates the risk of a
DoS via a bad policy, not where it is served. We could, for example,
propose the certificate must be for "example.com", but be served from "
whatever.example.com"; as John says, the bare TLD lookup (for
https://example.com/.well-known) is also served via untrusted DNS. As a
result, it seems to me that what is important is what we require of the
certificate (i.e. that it be valid for "example.com"), not what we require
of the policy URI.

3. I agree with Stephen that there may be no one-size-fits-all solution
here, hence our changes. But I think having a subdomain generally makes
this more flexible and never less; in particular, it opens the door for
clients of hosted mail providers to defer the policy serving to their host.

My suggestion would be thus to *specify that the certificate used to serve
the policy be valid for the TLD ("example.com <http://example.com>") *and
that we *retain the ability to serve policies from a different endpoint
than the TLD* (via either a magic hostname in DNS or, I guess as a slightly
crude hack, sticking a URI in the policy-version TXT record).

Does this make sense? I think the security issues do not rely in any event
on the DNS scheme we choose (but instead on what we require of the policy
serving cert), so the only issue here is really one of convenience.

Dan

---

From: "John Levine" <[email-masked]>
Date: 1 May 2016 15:27:58 -0000

>serving cert), so the only issue here is really one of convenience.

Pretty much.  Here's the issues I can think of:

If the two names in the cert aren't in the same tree, how will you
get a CA to sign it?  For example, I have a customer philiphazan.com
whose mail is at Tucows' hostedemail.com.  Who's going to get the
cert, me or Tucows, and either way, how do I or they persuade a CA to
sign a cert with two unrelated names?

With typical https libraries, I don't know how hard it'd be to check
the second name in the certificate.  If we decide to do that, it'd be
a good idea to check how deep into openssl or whatever you have to go.

It's not clear to me how much extra security the second name in the
certificate actually gives you if they're in the same tree.  In my
experience, if you ask a CA to sign foo.bar.example.com, as often as
not they'll throw in example.com for free.  The extra example.com name
doesn't tell you anything about the relationship between the two names
since CAs assume they're under the same control anyway.

Finally, there's the question of how you find the other endpoint.  I
suppose you could stick it in a TXT record but that's really no better
than SRV.  If you want to use a magic hostname, people will get
extreme heartburn since as far as I can tell, nobody's ever reserved a
hostname component (as opposed to a non-host component with an
underscore) before.  My xn--sts0 kludge is probably as good as you're
going to get, but it's still a total kludge.

R's,
John

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 1 May 2016 21:40:30 +0200

On Sun, May 1, 2016 at 5:27 PM, John Levine <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

My suggestion wasn't to have two names, but merely to have a cert valid for
philiphazan.com (in your example). Tucows can serve the policy with the
cert you upload to them via SNI, or you can serve the policy yourself on a
host you control.

> since CAs assume they're under the same control anyway.

I think it's worth requiring the CN/SAN to match "example.com" to avoid
someone.tumblr.com being able to serve a policy for tumblr.com, even if CAs
are sometimes silly about this, no?

> going to get, but it's still a total kludge.

Right. This is sort of back where we started. You can have a magic TXT (or
SRV) record that points to it, or a magic A/CNAME. No strong feeling about
this here--we're already proposing a magical TXT record, after all.
Functionally, having the endpoint be a URI in the TXT record doesn't really
change the system at all, so I think the best options are that, the SRV
record you propose, or just to...remove the underscores from the proposed
hostname? ;)

I don't mean to be indecisive about this one, but I think the functional
difference between those three options is (as far as I can see) small, so
I'm fairly happy to defer here to someone with stronger feelings on the
aesthetics (and, obviously, more familiarity with the RFC 3986 ABNF!).

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 May 2016 20:01:59 +0000

> cert you upload to them via SNI, or you can serve the policy yourself on a

Have the expected certificate be different from the authority is
going to make it much more difficult to use "off-the-shelf" HTTPS
libraries to access the underlying HTTPS resource.

> > a good idea to check how deep into openssl or whatever you have to go.

Yes, if one wants to write code directly against OpenSSL, it can
certainly make it possible to support a variety of matching
strategies, but I rather expect that people will just want to use
some existing HTTPS library.  (GET an HTTPS URI, and the details
are hidden from the layer than wants the content).

> are sometimes silly about this, no?

Yes, which is why I strongly suggested a fixed URI whose authority
is the exact next-hop domain, with no sub-domains, and a fixed
well-known path.  The parent domain should not depend on the security
of all possible sub-domains.

While that might make it necessary for the email folks to coordinate
with the HTTPS folks, I'm sure they are quite capable of doing so.

> aesthetics (and, obviously, more familiarity with the RFC 3986 ABNF!).

STS is kludgey enough already, let's keep the kludges down to a
minimum.  So no dragging in of SRV records or requiring new forms
of certificate matching for HTTPS.  Reserving a hostname prefix is
kind of ugly also.  Domain owners who delegate sub-domains will
need to avoid delegating this prefix, and we have no registry for
such prefixes.

So using the domain as-is and dealing with any provisioning politics
looks to be the only sensible option.

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 1 May 2016 16:49:09 -0400

> cert you upload to them via SNI, or you can serve the policy yourself on a

SNI where you open a connection to www.hostingprovider.com and ask for a 
cert for customer.org seems like a stretch, but I expect it wouldn't be 
too hard to make the cert for customer.org and sts-policy.customer.org and 
CNAME the latter to the host's server.

> are sometimes silly about this, no?

The cert matching should be OK, give or take library oddness, 
if we have a reasonable way to set things up.

> this here--we're already proposing a magical TXT record, after all.

I'd like to avoid inventing anything that feels significantly unlike stuff 
the IETF has done before.  There's lots of TXT records with _prefix names, 
since those don't have to be hostnames.  I don't think there's anything 
with a reserved hostname component, which is why I like SRV -- this is 
exactly the sort of thing it was designed to do, add a level of naming 
indirection when finding a service.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 1 May 2016 21:00:23 -0000

>looks to be the only sensible option.

Not to put Daniel on the spot, but since he happens to work for one of
the largest mail providers in the world, would it be a problem to put
the STS stuff at URLs like these?

https://google.com/.well-known/sts-policy
https://gmail.com/.well-known/sts-policy

My impression from the converstation in B.A. was that it'd be
a big problem.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 May 2016 18:55:44 -0400

> On May 1, 2016, at 5:00 PM, John Levine <[email-masked]> wrote:
> 

We need to put the organizations behind this draft on the spot to
not shirk this issue.  There's no free lunch.  I think it is fair
to ask the email folks at the large providers to negotiate with
others in their organization to deploy this in a manner that results
in a simpler security model.

SRV is very much not "webby".  HTTPS libraries don't do SRV lookups,
or else when asked to connect to a hostname resolved via SRV outside
the library, will authenticate the insecurely obtained target name.

So either the above ".well-known", or a kludgey reserved hostname
prefix, but there's no precedent for such reservations.

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 2 May 2016 00:57:08 +0000

>From what I know of my organization, it would be easier to create a separate hostname (policy._mta_sts.comcast.net) than to get some content served by the main domain's realm (comcast.net/foo/bar/sts-policy).  I'm not saying it can't be done, just that I interact often with the DNS group I would need to contact to get records published versus the web team.

--
Alex Brotman
Engineer, Anti-Abuse
Comcast
x5364

________________________________________
From: Uta <[email-masked]> on behalf of John Levine <[email-masked]>
Sent: Sunday, May 1, 2016 5:00 PM
To: [email-masked]
Subject: Re: [Uta] draft-brotman-mta-sts/

R's,
John

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 2 May 2016 07:06:42 +0200

> > My impression from the converstation in B.A. was that it'd be

Probably the most likely answer is that it would be easier than deploying
DNSSEC and harder than deploying at a custom host. For us it's probably
doable; for some organizations I would imagine it to be substantially
harder (if, for example, their  email domain doesn't have an HTTPS presence
today).

> the library, will authenticate the insecurely obtained target name.

Just to be clear, your point is not really that doing SRV or TXT resolution
of the policy server's hostname is a problem; it's that short of overriding
some HTTPS library's certificate matching, we would be potentially matching
a cert for (say) "sts_policy.example.com", which removes some of the
intended guarantees of "certificate matches the email domain," right?

---

From: Neil Cook <[email-masked]>
Date: Mon, 2 May 2016 11:07:17 +0100

> On 1 May 2016, at 11:29, Stephen Farrell <[email-masked]> wrote:
> 

In my experience with large service providers, the mail team are often responsible for DNS, or if not, then at least close to the DNS team. Not so with the web team, which (again in my experience) is typically in a completely different part of the organisation.

Neil

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 May 2016 13:52:12 +0000

> harder (if, for example, their  email domain doesn't have an HTTPS presence

So far, that sounds like "doable" to me.  If a sub-domain turns
out to be critically important, then despite lack of precedent it
should be a fixed prefix name that is a valid hostname.  The prefix
might not be "reserved" exclusively for STS, but would be unlikely
to be used for another purpose in practice.  Think "www.", "ftp.",
...

Organizations that delegate arms-length sub-domains would need to
be careful about delegating that particular prefix to an unstrusted
sub-entity, or ceding control of the content published at
"https:<prefix>.<parent-email-domain>".  Then path component of
the URI would still need to be well-known (fixed).

> intended guarantees of "certificate matches the email domain," right?

Yes, that's my point, and with SRV indirection that derived hostname
would be obtained from an insecure source (unauthenticated DNS).

By "TXT" resolution do you mean publishing the target URI in the
DNS TXT record?  If so, I thought that idea was abandoned.

[ FWIW, that hypothetical hostname can't have any "_" characters
  in it and remain a valid hostname. ]

-- 
	Viktor.

---

From: [email-masked]
Date: Mon, 02 May 2016 10:58:00 -0700 (PDT)

> In my experience with large service providers, the mail team are often
> responsible for DNS, or if not, then at least close to the DNS team. Not so
> with the web team, which (again in my experience) is typically in a completely
> different part of the organisation.

The fact that operational changes to the DNS are likely to be needed on
a regular basis by any large email deployment more or less insures this
is the case. 

Of course this doesn't translate to DNSSEC magically deploying when needed.

Web services, OTOH, only intersect with webmail, and since that's usually
delivered by a separate application-specific infrastructure, the intersection
may be limited to getting the necessary certificates. And DNS names, of course.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 2 May 2016 23:33:42 -0000

>> the second name in the certificate.

I tried writing a python script to fetch an https URL and check a
different domain name against the subjectAltNames in the site's
certificate.  It turned out to be really easy, viz. the tiny script
below.  So at first glance, that doesn't seem to be a big problem.

R's,
John

--- snippo, python3 below ---

import http.client
import argparse
import re

parser = argparse.ArgumentParser('Fetch an https thing and also check an alt name')
parser.add_argument('url', help='URL to fetch')
parser.add_argument('name', help='Other domain name to check')

args = parser.parse_args()

if not args:
    exit(1)

r = re.match(r'https://([-a-z0-9.]*)(/.*)', args.url)
if not r:
    print ("Doesn't look like an https url: ",r)
    exit(1)
domain = r.group(1)
path = r.group(2)

c = http.client.HTTPSConnection(domain)
if not c:
    print("cannot set up ",domain)
    exit(1)

c.request('GET', path)
r = c.getresponse()
if r.status != 200:
    print ("status is", r.status)
    exit(1)

data = r.read()
cert = c.sock.getpeercert()
c.close()

# check for alt name
matched = False
if 'subjectAltName' in cert:
    for t, n in cert['subjectAltName']:
        if t == 'DNS' and n == args.name: # should check wildcards, too.
            matched = True
            break

if not matched:
    print("no dice for",name)
    exit(1)
            
print ("data is", data)

---

From: Mark Risher <[email-masked]>
Date: Mon, 2 May 2016 16:36:57 -0700

Cool, thanks for sharing that, John.

I should note that even we are considering fetching these policies from
outside the MTA, so a script like this running in its own cron job against
the last hour's unique domains could be a totally viable option. I offer
this for those who were reluctant to open port 80/443 on their production
MTAs.

/m

--
Mark E. Risher |  Group Product Manager |  [email-masked] |  650-253-3123

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 May 2016 19:39:41 -0400

> On May 2, 2016, at 7:33 PM, John Levine <[email-masked]> wrote:
> 

Cute, but likely completely insecure.  I see no check that the
certificate chain is trusted.  Users should probably use existing
test HTTPS libraries, rather than roll their own.

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 2 May 2016 20:47:05 -0400

> this for those who were reluctant to open port 80/443 on their production

I was planning to do more or less the same thing, put the checking in a 
daemon that the MTAs can query.  I do that now for greylisting and it 
works well.  The MTAs are written in C for speed, but the daemons can be 
written in anything.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 May 2016 01:06:46 -0000

>certificate chain is trusted.

Is it really that hard to look at the documentation for the python
libraries?  It's right here: https://docs.python.org/3/library/http.client.html

By default, the https library checks the certificate chain against the
usual pile of CAs and throws an exception if the validation fails.
You can turn off the checks for applications that want to do something
special, but we didn't do that.

R's,
John

---

From: Binu Ramakrishnan <[email-masked]>
Date: Tue, 3 May 2016 01:23:09 +0000 (UTC)

Whether we use sub-domain or .well-known URL path to serve STS policies, I'm not sure whether we can guarantee uniqueness with the resource. I think sub-domains are better because it helps the Mail admins to control those policies - means they can make updates to these endpoint without depending on web admins.
I would prefer a well known sub-domain based URL endpoint, that removes the need to stick another record in DNS. Regarding certificate validation, it is better to validate against the STS sub-domain based URL only (not parent/email domain).
thanks,-binuYahoo Inc.

    On Monday, 2 May 2016 6:52 AM, Viktor Dukhovni <[email-masked]> wrote:

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 May 2016 21:39:58 -0400

> On May 2, 2016, at 9:06 PM, John Levine <[email-masked]> wrote:
> 

The documentation says:

    Changed in version 3.4.3: This class now performs all the necessary certificate
    and hostname checks by default. To revert to the previous, unverified, behavior
    ssl._create_unverified_context() can be passed to the context parameter.

So it seems that you either get both chain verification and hostname checks or
neither.  Perhaps I am reading the docs incorrectly?

In any case, doing atypical things risks people doing the wrong thing, even if
one particular library makes it comparatively painless to do the right thing.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 3 May 2016 03:08:17 -0000

>neither.  Perhaps I am reading the docs incorrectly?

Aw, come on.  This is a code example I wrote in ten minutes.  If you
believe it's that important to make this example work in older
versions of python, feel free to add the three or four lines of code
that turn on certificate verification explicitly.  It is really not
rocket science.

>one particular library makes it comparatively painless to do the right thing.

We seem to have extreme variation in our thresholds of pain -- writing
small amounts of code to check SSL certificates causes crippling
agony, while forcing the production web departments of large
organizations to add odd stuff of use only to the mail department is a
barely perceptible pinprick.  I think we've made all the points we're
going to make.

R's,
John

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 3 May 2016 23:57:40 +0200

> DNS TXT record?  If so, I thought that idea was abandoned.

It was, but only because we had been thinking we would just use a
hard-coded hostname instead. The two have the same security properties. (Of
course the TXT approach and the SRV approach are basically equivalent.)

In any event, since I think we all agree that the certificate probably has
to match the bare TLD, it seems like the discussion could be rephrased to
be closer to how John just formulated it, i.e. the security and operational
tradeoff of:

1. Writing code in the policy fetcher to check the CN/SAN against "
example.com"
2. Having to host in the TLD

I think the pros and cons of both have been well stated.

Assuming WG adoption of the draft, we would then...take a vote?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 May 2016 22:08:28 +0000

> be closer to how John just formulated it, i.e. the security and operational

If a fixed (but valid as a hostname) prefix is specified, then it
neither needs to be sent via TXT or SRV records, nor does the
certificate have to patch the parent domain, and it would be better
if the certificate matched the authority of the implicit HTTPS URI.

Thus, though the name would be not exclusively reserved for STS,
the simplest approach if sub-domains are so important is to choose
a prefix, say "smtp-sts-policy", and when sending mail to example.com,
look for policy at something close to:

    https://smtp-sts-policy.example.com/.well-known/smtp-sts-policy

with a certificate that matches the prefixed name.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 4 May 2016 00:19:58 +0200

Yeah, that's basically what's in the current draft (albeit with
underscores-d'oh!).

The security tradeoff of allowing the cert to match the fixed hostname is
somewhat unclear to me, though, so it makes a similar tradeoff to what I
stated: do we want to force senders to validate the certificate manually
(with a bit of code like John shared) against example.com, or do we just
assume the second-level host is basically trusted (if you have an SSL cert
that covers it) and use generic cert validation (allowing  smtp-sts-policy,
*.example.com, etc)?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 May 2016 22:24:50 +0000

> Yeah, that's basically what's in the current draft (albeit with

Yes, with a valid hostname.

> somewhat unclear to me,

It is not much of a trade-off.  A domain owner of example.com who
wants to do STS should not delegate or otherwise cede control of
the host or certificates for "smtp-sts-policy.example.com".

> do we want to force senders to validate the certificate manually

Though I am sure that John can whip up safe Python code to do HTTPS
with a hostname<->certificate mismatch, making this necessary is
best avoided.

--
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 4 May 2016 01:38:22 +0200

Yeah, I agree on the two points. But is it safe for us to assume that
"smtp-sts-policy" is not an untrusted host? This was our concern, given
examples like dyndns.org or tumblr.com. Of course, an attacker also has to
do DNS injection, but with insecure DNS that's in our threat model.

This is the argument for imposing this specific (nonstandard) certificate
requirement (that it match the bare domain), albeit with the implementation
risk that you point out. I think this is a real tradeoff--the risk of
someone screwing up cert validation versus the risk of someone ceding the
host to an untrusted person.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 May 2016 23:43:27 +0000

> do DNS injection, but with insecure DNS that's in our threat model.

I think that tumblr.com and dyndns.org can figure out a way to
avoid delegating that particular prefix.

> host to an untrusted person.

I think the implementation screwup risk is higher.  The more vanilla
the design requirements, the more likely implementors are to get
it right.

-- 
	Viktor.

---

From: Mark Risher <[email-masked]>
Date: Tue, 3 May 2016 17:48:00 -0700

> avoid delegating that particular prefix.

Has there been any effort to standardize or register the "special"
subdomains, e.g. something like *well-known*.domain.com? Having seen large
companies fail to secure the abuse@, webmaster@, security@, and other local
parts that allow "proving" domain ownership, I'm not as sanguine that
tumblr and dyndns (and wix and squarespace and wordpress and ..) will
remember to block off all the pertinent subdomains in advance.

/m

---

From: "John Levine" <[email-masked]>
Date: 4 May 2016 23:12:52 -0000

>with a hostname<->certificate mismatch, making this necessary is

Though I am sure that some domains can delegate
smtp-sts-policy.<whatever> without trouble, putting a new and
unprecented requirement on the DNS operator of every domain that uses
STS is best avoided.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 4 May 2016 23:10:37 -0000

>remember to block off all the pertinent subdomains in advance.

Dave Crocker is working on a registry of special tags like _dmarc but they
all contain underscores so they're not hostnames.

ICANN has some rules about second-level hostnames in contracted TLDs,
but they're not very relevant here.

There's a somnolent WG called DBOUND whose goal is to publish
boundaries in the DNS, perhaps along the lines of the Mozilla PSL, but
it's going nowhere.

So the answer is no, and that's why I expect there'd be a lot of
heartburn if we wrote a spec that used a fixed label in a hostname,
since as far as I can tell nobody's done that before.  The IETF way to
look up a hostname for a service is to use DNS SRV, and it's widely
used. For example, approximately 100% of SIP providers use it. it
works fine.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 May 2016 23:41:14 +0000

> used. For example, approximately 100% of SIP providers use it. it

Yes, but layering security on SRV records absent DNSSEC is unsolved
problem.  Your proposed solution is to require the target host to
sport a certificate for the service domain, rather than the target
hostname.  Yes, that addresses the security gap, and can use a
reserved "_smtp-sts-policy" prefix rather than a fixed "smtp-sts-policy"
hostname prefix.

The downside that vanilla HTTPS libraries in their default validate
and retrieve mode can will no longer work without custom overrides
for certificate validation.  I've seen that done incorrectly in
many creative ways, ...

At this juncture I think we've both explained our views and understand
each other.  I think the rest is up to the draft authors and the
rest of the WG.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 5 May 2016 01:38:42 -0000

>for certificate validation.  I've seen that done incorrectly in

If history is a guide, the number of implementations of whatever hack
we do will be a dozen or two, while with any luck it'll be rolled out
across tens of thousands of domains or more.  So, apparently, the
programmers who work on mail servers are so incompetent and it would
be so hard to get those few implementations debugged, that it's easier
to tell those thousands of domains that they all have to reserve a
fixed name and hope it doesn't collide?

I've seen my share of incompetent programming (I used to teach
undergrads), but really, now.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 May 2016 01:54:03 +0000

> undergrads), but really, now.

Yes, because of that dozen or two, most will be broken, and nobody
competent will bother to check.  Failure to perform the checks
correctly will not be obvious, everything will appear to work
securely.

Additionally I am guided by the principle that opportunistic (yes
DANE, STS for SMTP are still opportunistic) security must be as
simple as possible for the client, perhaps at an acceptable cost
increment to the server.

We clearly disagree on the relative importance of two valid concerns,
and neither of us is saying anything new, or is missing the other's
point.  So we should stop here.

-- 
	Viktor.