Subject: UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

From: Harald Alvestrand <[email-masked]>
Date: Tue, 1 Dec 2015 15:34:32 +0100

If I understand this draft correctly, I object.

It says:

   2.  When using email service discovery procedure specified in
       [RFC6186] the client MUST also use the right hand side of the
       email address as another "reference identifier" to compare
       against SRV-ID identifier in the server certificate.

If I understand RFC 6186 correctly, a (possibly large scale) IMAP email
service provider that wishes to serve a new domain "example org"
according to RFC 6186 must do two things:

- Update internal tables of its servers with inforamation about that domain.
- Populate the DNS of the domain served with an _imap record.

If I understand this draft correctly, the server will have to do one
more thing:

- Change its certificate to include a complete list of all the domains
it is serving, and have its CA sign off on that certificate.

The reason it cannot provide one certificate per served domain is that
neither this specification nor any other specification I have found says
that the client MUST include any distinguishing information (such as a
Server Name Indication) that says what name it is expecting the server
to provide service for.

Given the popularity of multi-domain mail servers (my own tiny little
mail servers has 9 domains it calls its own, some of which I do not wish
to advertise), I see this as a problem.

If I have misunderstood the issue, I apologize.

Harald Alvestrand

Den 20. nov. 2015 15:29, skrev The IESG:
> 
> The IESG has received a request from the Using TLS in Applications WG
> (uta) to consider the following document:
> - 'Updated TLS Server Identity Check Procedure for Email Related
>    Protocols'
>   <draft-ietf-uta-email-tls-certs-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-12-04. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document describes TLS server identity verification procedure
>    for SMTP Submission, IMAP, POP and ManageSieve clients.  It replaces
>    Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates
>    Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2015 15:50:19 -0000

>it is serving, and have its CA sign off on that certificate.

That's how I read it too, and it's a problem for two reasons.

One is that large mail systems handle vast numbers of domains.  I wouldn't
be surprised if there were 100,000 small domains all pointed at Google's
servers.  That would make the certificate, ah, bulky.

The other is that there is no reasonable way for a CA to verify that
the list of mail domains in a certificate is correct, which means that
SNI wouldn't help.  For example, one of my customers quarteracre.net
has a few mailboxes at hostedemail.com.  The usual CA validation
wouldn't help, since there is nothing in the WHOIS for quarteracre.net
or any of the other stuff that CA's normally check that tell you where
their mail is.

But there's no need to put this in the cert since RFC 6186 already tells you:

;; QUESTION SECTION:
;_imaps._tcp.quarteracre.net.	IN	SRV

;; ANSWER SECTION:
_imaps._tcp.quarteracre.net. 3600 IN	SRV	1 1 993 mail.a.hostedemail.com.
_imaps._tcp.quarteracre.net. 3600 IN	RRSIG	SRV 8 4 3600 20160201000000 20151201054531 36633 quarteracre.net. bCSLoiCnQcftwclKRbVXxP8c8nsX+TtgGpDCMQUR1AM+gjejgQ9bzU0v ZWKW44whg1mXwN79FwArNEZ/6/B77w4PVjvVBOWW6ZIhIq9AawIplUXU CdZ43dhNR/oVdFbp/g7H4h1U5+JJJWt4hqiCG7NEoRp7/jT0l4y4ndxW YBo=

My suggestion would be to remove the email domain SRV-IDs from the
certificates since they don't tell you anything useful, and to advise
clients to use SRV and DNSSEC to get the name of the server if they
want to be sure they have the right one.  I suppose the CA could make
the DNS checks, but that seems like a bad idea since certs are
typically signed once a year, and a large mail system will add and
drop client domains every day.

This does leave open the loophole that a domain can point at servers
that aren't expecting to handle its mail, but we've had that problem
since MX records were invented.  The usual advice is "don't do that."

R's,
John

---

From: Dave Cridland <[email-masked]>
Date: Tue, 1 Dec 2015 16:12:38 +0000

And RFC 6125 already gives a useful set of guidelines for clients to use to
securely derive reference identifiers which includes precisely this.

The alternate solution is something like POSH, which effectively gives you
Attribute Certificates on the cheap.

On 1 December 2015 at 15:50, John Levine <[email-masked]> wrote:

> _imaps._tcp.quarteracre.net. 3600 IN    RRSIG   SRV 8 4 3600
> 20160201000000 20151201054531 36633 quarteracre.net.
> bCSLoiCnQcftwclKRbVXxP8c8nsX+TtgGpDCMQUR1AM+gjejgQ9bzU0v
> ZWKW44whg1mXwN79FwArNEZ/6/B77w4PVjvVBOWW6ZIhIq9AawIplUXU
> CdZ43dhNR/oVdFbp/g7H4h1U5+JJJWt4hqiCG7NEoRp7/jT0l4y4ndxW YBo=
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Dec 2015 17:37:24 +0000

>        against SRV-ID identifier in the server certificate.

The key word in that text is "another".  This does not require the
server to have a certificate that matches this identifier, provided
there is some other some suitable identifier.  It provides additional
flexibility, not a constraint.

NOTE HOWEVER, that use of the server name from the SRV record as
a DNS-ID reference identifier offers no security at all absent
DNSSEC.  So "another" might become "only" in that case.  The 6186
approach to address lack of trustworthy identifiers basically boils
down to "ask the user".  Once the user confirms the SRV record it
becomes pinned, and the server name becomes one of the reference
identifiers.

My question upthread was whether this draft continues that legacy,
or departs from it.

> according to RFC 6186 must do two things:

I am not aware of any adoption of RFC 6186.  Are there are any MUAs
actually doing RFC 6186 SRV lookups?  If there are none, is it worth
debating?

> it is serving, and have its CA sign off on that certificate.

Not needed in the "ask the user" approach, which is what 6186
entails.  Also not needed with SRV records protected with DNSSEC.
With plain-old SRV records, and no user confirmation, one is left
with no trustworthy identifiers other than SRV-ID (_imap.domainpart
of user's email address and the like).

So, if indeed MUAs want to implement this draft, and "ask the user"
is acknowledged as denial of reality, then they MUST use SNI.

For example RFC7671 and RFC7672 mandate SNI for DANE clients.

Indeed in TLS 1.3 SNI becomes mandatory to implement and send:

    https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-8.2

> Server Name Indication) that says what name it is expecting the server

See above.

-- 
	Viktor.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 2 Dec 2015 13:06:48 +0100

> becomes pinned, and the server name becomes one of the reference

Which server name? I couldn't tell from this draft either which would be
presented or which would be stored (I assume you'd want them to be the
same).

Actually this highlights another problem: The draft claims to replace
section 2.4 of RFC 2591, "Server identity check", but fails to provide
replacement text for a crucial part of that document:

"If the match fails, the client SHOULD either ask for explicit user
   confirmation, or terminate the connection and indicate the server's
   identity is suspect."

This document doesn't say anything about what should happen once the
match is finished.

> actually doing RFC 6186 SRV lookups?  If there are none, is it worth

The draft claims to have a normative dependency on RFC 6186. If the use
of RFC 6186 is not worth debating, the reference is worth deleting.

>     https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-8.2

As I read that spec, it says mandatory to implement, not mandatory to
use (it's up to the application whether it claims to be capable of using
it or not) - but it permits servers to mandate its use. *Almost* there -
but if this draft wishes to mandate its use, it will have to say so (and
say which identifier it's going to send - AFAIK, it only gets to send one.)

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2015 12:16:40 +0000

> This document doesn't say anything about what should happen once the
It does by reference, see RFC 6125.
> of RFC 6186 is not worth debating, the reference is worth deleting.
There are some uses of RFC 6186. How widespread? I don't know.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2015 12:29:06 +0000

Hi Harald,

> it is serving, and have its CA sign off on that certificate.
Yes, or alternatively, one can do one of two other things:
1) use Server Name Indication TLS extension. At the moment none of the 
email specs requires it. But maybe it is something that the draft should 
encourage.
2) run each domain on its own IP/port, then each IP/port can use 
separate certificate with a single domain.

As Dave Cridland pointed out, POSH (RFC 7711) is trying to solve the 
problem of hosting multiple domains, but its use is not defined for 
email yet. I think it is out of scope for this document.
> Server Name Indication) that says what name it is expecting the server
That is correct, see above.
> If I have misunderstood the issue, I apologize.
Best Regards,
Alexey

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2015 14:28:19 -0000

>say which identifier it's going to send - AFAIK, it only gets to send one.)

Even with SNI, we still have the problem that there's no way for the
CA to tell what SRV-IDs it should sign other than using RFC 6186
lookups.  But the MUA can do the same 6186 lookup, and that scales a
lot better for the many mail systems that handle large and changing
sets of client domains.

R's,
John

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 2 Dec 2015 15:57:32 +0100

> It does by reference, see RFC 6125.

OK, now I see it: It says (3.3 intro) "Matching is performed according
to the rules specified in Section 6 of [RFC6125], including "certificate
pinning" and the procedure on failure to match". Consider this issue
satisfied.

> There are some uses of RFC 6186. How widespread? I don't know.

Note - I don't have an opinion on the use or non-use of 6186. What I'm
saying is that if we reference it, we need to have something the
providers will be able to practice.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 2 Dec 2015 16:02:01 +0100

> lot better for the many mail systems that handle large and changing

I don't think having the certificate changed and signed every time you
turn up a new customer scales anyway. With an in-house CA, it's possible
to generate a new certificate for every new customer - but signing your
customer list and publishing it? That seems like a Bad Idea, as well as
unscaleable.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Dec 2015 21:03:03 +0000

> lot better for the many mail systems that handle large and changing

You're basically saying that WebPKI cannot provide security for
hosted email.  Perhaps this is so.  In which case transport security
for hosted email requires DNSSEC to do what WebPKI cannot.

Or are you suggesting "ask the user", or that the MUA just assume
that plain old DNS (not DNSSEC) is secure enough, and use the SRV
target hostname to check the peer certificate, despite the fact
that the SRV target name is trivial to MITM?

Basically, I don't how this draft changes the situation with respect
to the problems with 6186.  My understanding of current practice
is that 6186 is not widely used, and the server names for IMAP,
SMTP, ... are explicitly configured, sometimes without asking the
user to specify them, because knowledge of the settings for user's
domain is wired into the MUA software.

My view (as noted in Section 7 of 7672) is that 6186 is defective
in that it glosses over a critical security issue by suggesting
asking the user to confirm data gleaned from SRV records.  If the
user is in fact knowledgeable, and the settings are only obtained
once at account setup and hence remain frozen, this is roughly
similar to the situation with the baked-in settings for Gmail et.
al. in MUAs.  In which case, one would use the frozen name as a
reference identifier for the server, since after the initial leap
of faith, it is a pinned "trusted" name.

This leaves the problem of making the pinned names "portable" (not
tied to the provider's domain).  For that, the only sensible solution
is DANE.  As you've noted CA's are very poorly positioned to able
to say anything about the authenticity of this type of arrangement.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2015 01:03:56 -0000

>> lookups. ...

>for hosted email requires DNSSEC to do what WebPKI cannot.

Yup, for the reasons I laid out, notably that there is no way other
than RFC 6186+DNSSEC to tell mechanically what servers handle what
mail domains.  (I suppose it's possible I'm wrong, but if so, please
lay out the steps to use to get from a mail domain to a server name.)

Imagine you had a shared web server that hosted 50,000 different
domains with 50,000 different certificates.  The domains are all
owned by different people, so each one has to arrange to sign its
own certificate and provide it to the server operator in a suitably
secure way.  That's essentially the situation with a large SUBMIT
or POP/IMAP server.

>that the SRV target name is trivial to MITM?

No, I'm saying that there is no way other than RFC 6186+DNSSEC to tell
mechanically what servers handle what mail domains.

>to the problems with 6186.

It doesn't.  But since there is no way other than RFC 6186+DNSSEC to
tell mechanically what servers handle what mail domains, that's all
we've got.

>asking the user to confirm data gleaned from SRV records.

I looked at RFC 6186, and don't see where it says that.  Could you
clarify?  It does say that the user will probably have to provide
login and password information, but that's a separate step after
deciding what server to use.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Dec 2015 01:23:38 +0000

> lay out the steps to use to get from a mail domain to a server name.)

We're on the same page then.  As I don't want to be the only one
saying this, I am making an effort to let others say it first.

> deciding what server to use.

https://tools.ietf.org/html/rfc6186#section-6

(second paragraph)

   A malicious attacker with access to the DNS server data, or able to
   get spoofed answers cached in a recursive resolver, can potentially
   cause MUAs to connect to any IMAP, POP3, or submission server chosen
   by the attacker.  In the absence of a secure DNS option, MUAs SHOULD
   check that the target FQDN returned in the SRV record matches the
   original service domain that was queried.  If the target FQDN is not
   in the queried domain, MUAs SHOULD verify with the user that the SRV
			  ---------------------------------------------
   target FQDN is suitable for use before executing any connections to
   -------------------------------------------------------------------
   the host.  Alternatively, if TLS [RFC5246] is being used for the
   ---------
   email service, MUAs MUST use the procedure outlined in Section 6 of
   [RFC6125] to verify the service

And the next sentence is clear as mud, alternative to what?

In any case, absent DNSSEC validated SRV records, there is no good
way to deploy transport security for *hosted* submission and imap
services without users manually selecting the underlying provider
hostnames as the service endpoint.

With DNSSEC validated SRV records, one may as well use DANE.  That
said, DNSSEC is as yet not a ubiquitous viable option for mobile
clients, we need many years of upgrades of public WiFi networks
before one might be able to expect DNSSEC signed SRV records to
reach one's mobile device.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2015 02:08:29 -0000

>hostnames as the service endpoint.

Yup.  We're exactly where we are now, he said tautologically.

>reach one's mobile device.

I wouldn't disagree, but I also don't see anything on the horizon
better than SRV+DNSSEC.  It's an architectural fact that mail servers
host lots of domains, and that server configuration has historically
been pretty casual.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Dec 2015 02:55:56 +0000

> host lots of domains, and that server configuration has historically

OK, but we should probably at this point return to discussing the
draft, it being Last Call and all that.  What does all this mean
in terms of the draft?

  * The draft attempts to introduce SRV-ID as a security mechanism
    for mail services.  SRV-ID does not require DNSSEC, but does
    require that CAs be able to figure out which service providers
    are legitimately hosting a given domain.

Is the objection that this is not realistic?  I can see that it
won't always be an option.  There is a class of service providers
for whom this is possible, namely those that are also WebPKI CAs.
So GoDaddy and the like would be able to issue SRV-ID certificates
for domains they host.  Is that enough to justify including the
SRV-ID use-case in the draft?

Or is it the case that you'd prefer text that says that the problem
has no broadly workable solution in the absence of DNSSEC?  In
which case the SRV-ID proposal might be a non-starter?  Then the
options we're left with are explicit target server configuration
by users with WebPKI + DNS-ID (of user-specified server names) or
DNSSEC + SRV + DNS-ID (with either WebPKI or DANE for whatever
hostname appears as the target of the SRV).

My take is that the draft explains what it *would* take to try to
secure 6186 in the absence of DNSSEC, and if gets adoption fine,
and if it doesn't at least the obstacles are more clearly explained.

Yes, I am somewhat skeptical of the practicality of the model, but
since it is basically the only plausible alternative to either
manual configuration (including MUA wired-in per-provider settings)
or SRV + DNSSEC, I see no harm in it, whether it works out or not.

The draft is very concise, perhaps there should be more discussion
of the difficulties that lead to its recommendations, including
the some text to the effect that while DNSSEC (with perhaps DANE)
might address the issues more neatly in the future, this document
aims to specify practices one could employ today (or at least soon).
Which brings us back to the question of whether WebPKI SRV-ID
certificates can be employed now or in the near future widely enough
to warrant the ink.

--
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2015 03:10:53 -0000

>SRV-ID use-case in the draft?

Given the limited number of organizations that are both CAs and mail
hosts, it seems a poor idea to tell people to implement something
which will at best be flaky.

>has no broadly workable solution in the absence of DNSSEC?

Well, it's true.

R's,
John

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 3 Dec 2015 12:53:25 +0100

My objections to the draft would be alleviated if the abstract was
changed to:

   This document describes an experimental TLS server identity
verification procedure
   for SMTP Submission, IMAP, POP and ManageSieve clients that is
appropriate for
   mail servers that host a small number of domains under a single
administration.

   When used, it replaces

   Procedures that scale to servers that host a large number of domains are
   for further study.

And in the security considerations section:

  Because of the lack of client identification of the target domain,
  the email server certificate described in this document has to contain
  the complete list of names that the client will be looking for. If
  RFC 6186 is in use, this means that the mail server certificate will hold
  a list of all domains served by this service. This reveals information
about
  other customers of the service, which may not be a desirable result.

Note that I'm OK with pushing this as *experimental*. Given the lack of
general applicability, I'm not OK with pushing this for standards-track.

Harald

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Dec 2015 14:33:01 +0000

On Thu, Dec 03, 2015 at 12:53:25PM +0100, Harald Alvestrand wrote:

>    This document describes an experimental TLS server identity verification
>    procedure for SMTP Submission, IMAP, POP and ManageSieve clients that
>    is appropriate for mail servers that host a small number of domains
>    under a single administration.

This scope reduction is I think much too drastic.  Firstly, because
the RFC 6186 use-case is not the only one under consideration.
Indeed if we're concerned about applicability, the draft's text
for the most important use-case of explicitly specified service
end-points (the vast majority of current practice) does not face
any new operational barriers.

While the client would now check for "SRV-ID" with the user email
domainpart in the server certificate, there is no obligation on
the server certificate to contain these, as the client will *also*
check for the DNS-ID of the explicitly specified server hostname.

>    Procedures that scale to servers that host a large number of domains are

And so in this case, all is well, provided the users of said domains
all manually specify the provider's SMTP and IMAP servers.  It is
only the attempt to support "zero conf" via 6186 + SRV-ID for the
source domain that runs into likely difficulties actually obtaining
such certificates, and lack of SNI signalling.

The lack of SNI is easily addressed, by requiring clients that
implement RFC 6186 to use SNI (indeed they'll some day have no
choice but to do that anyway with TLS 1.3).

>   Because of the lack of client identification of the target domain,

See above, this is a completely avoidable obstacle.

>   a list of all domains served by this service.

Hence the conclusion is not valid.

>   This reveals information about

And this too becomes moot.

-- 
	Viktor.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 3 Dec 2015 21:59:32 +0100

> such certificates, and lack of SNI signalling.

OK, make the use of "domain name from user's email address" and RFC 6186
support an experimental feature, perhaps described in an appendix. What
I want the document to call out is that there are known, important use
cases for which RFC 6186 together with this draft *DOES NOT WORK*.

Quoting RFC 2026 is always fun:

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

The "technical omission" here is "using 6186 together with mail servers
supporting a high number of domains is going to be painful, and this
document doesn't say how to solve it".

Fix that, or document it.

> choice but to do that anyway with TLS 1.3).

I read the TLS draft. This is still a misrepresentation; TLS 1.3 won't
force anyone to use it - the higher level protocol *can*, however, do that.
I would absolutely support a revision to RFC 6186 that mandates use of SNI.

> And this too becomes moot.

Yes, if 6186 support is taken out of the draft, the problem goes away.
But at the moment, 6186 is in the draft.

Pick your poison.

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Dec 2015 16:23:33 -0500

--On Tuesday, December 01, 2015 15:50 +0000 John Levine
<[email-masked]> wrote:

>...
> The other is that there is no reasonable way for a CA to
> verify that the list of mail domains in a certificate is
> correct, which means that SNI wouldn't help.  For example, one
> of my customers quarteracre.net has a few mailboxes at
> hostedemail.com.  The usual CA validation wouldn't help, since
> there is nothing in the WHOIS for quarteracre.net or any of
> the other stuff that CA's normally check that tell you where
> their mail is.
> 
> _imaps._tcp.quarteracre.net. 3600 IN	SRV	1 1 993
> mail.a.hostedemail.com. _imaps._tcp.quarteracre.net. 3600 IN
> 	RRSIG	SRV 8 4 3600 20160201000000 20151201054531 36633
> quarteracre.net.
> My suggestion would be to remove the email domain SRV-IDs from
> the certificates since they don't tell you anything useful,
> and to advise clients to use SRV and DNSSEC to get the name of
> the server if they want to be sure they have the right one.  I
> suppose the CA could make the DNS checks, but that seems like
> a bad idea since certs are typically signed once a year, and a
> large mail system will add and drop client domains every day.
>...

John,

Insofar as I understand this (I've read the thread up to this
time, but the above seems most appropriate to which to reply),
there is one other issue:

If the DNS has 
   target.example.com.   MX 0  smtp1.example.com.
                         MX 10 smtp2.example.net.

Then, first, if the message reaches smtp2.example.net and it
accepts that message (2yz responses to everything), it is under
no obligation to move it along using an SMTP connection to
smtp1.example.com.   It does have an obligation to get the
message delivered (modulo the usual weasel-words), but not to
use SMTP to do so.  More important, if the end user is going to
pick the message up via, say, IMAP, there is no requirement that
the IMAP server (or the mailstore) even be on the public
Internet, much less that it have a domain name, as long as the
IMAP Client MUA can be configured to find the relevant IMAP
server.

So it seems to me that even Harald's list of cases in which this
approach won't work and isn't applicable should be longer and
even more qualified.  Put differently, while the numbers may be
large, it appears in practice that this approach is (even
potentially) applicable to a very small number of types of cases
and configurations and that the document should be very clear
about that, characterizing those cases in as much detail as
possible.

    john

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2015 17:15:18 -0500

> about that, characterizing those cases in as much detail as

I think the problem that we're trying to address here is setting up a MUA 
and wanting to ensure that it's talking to the correct SUBMIT, POP, and 
IMAP servers.  You're right that there's all sorts of private networks 
with mysterious naming, but every smartphone has an MUA that usually does 
SUBMIT and IMAP, so it would be nice if the phone's MUA could reliably 
configure itself with minimal help from the user.

Verifying SMTP servers seems like a much easier problem -- the MX records 
are signed with DNSSEC, and the SMTP server presents a certificate with 
the right name, either signed by a mutually satisfactory CA or verified by 
DNSSEC signed TLSA.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Dec 2015 09:50:34 +1100

In message <[email-masked]>, "John R Levine" writes
> the right name, either signed by a mutually satisfactory CA or verified by 

And publishing and verifying the submit servers with SRV is just
as easy with DNSSEC.  It's trying to make it work without DNSSEC
that is hard.

Apple, Google and Microsoft could be supplying a DNSSEC aware stub
resolver in their products today if they wanted to.  They could be
supplying the root's trust anchor like they supply CA bundles to
that stub resolver.  Then all the products running on those platforms
would have access to DNSSEC without having to roll their own
validator.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 3 Dec 2015 16:03:18 -0700

> On Dec 3, 2015, at 3:15 PM, John R Levine <[email-masked]> wrote:
> 
> I think the problem that we're trying to address here is setting up a MUA and wanting to ensure that it's talking to the correct SUBMIT, POP, and IMAP servers.  You're right that there's all sorts of private networks with mysterious naming, but every smartphone has an MUA that usually does SUBMIT and IMAP, so it would be nice if the phone's MUA could reliably configure itself with minimal help from the user.

See: https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03

for an attempt that was made a couple of years ago.  We had a BoF that didn't go particularly well, but if there was interest, I'm pretty sure we could do another one and overcome the objections.

Note that Cyrus's document allows service-specific certificate pinning by bootstrapping from https://*/.well-known, an approach that was resurrected in draft-ietf-xmpp-posh.

-- 
Joe Hildebrand

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2015 20:21:06 -0500

> for an attempt that was made a couple of years ago.  We had a BoF that didn't go particularly well, but if there was interest, I'm pretty sure we could do another one and overcome the objections.

For this particular situation, I think that's overkill.  We already have 
RFC 6186 which defines an easy to use way to publish the location of 
SUBMIT, POP, and IMAP servers, at least if you already have DNSSEC set up. 
I can confirm that it's easy, it took me about five minutes to add the 
relevant records to my DNS zones.  The SRV records have the domain names 
of the servers, you check them against the DNS-ID in the servers' 
certificates, and you're done.  You still have to provide your password, 
but that goes with the territory since the client systems aren't otherwise 
known to the servers.

The arguments seem to be based on the observation that DNSSEC uptake is 
slow so maybe we should do something else.  Maybe, but it's not my 
impression that's a winning argument in the IETF.

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

---

From: "John Levine" <[email-masked]>
Date: 4 Dec 2015 03:53:04 -0000

>document doesn't say how to solve it".

Wait a minute.  If you don't use the SRV-IDs, which you don't need if
use DNSSEC on the SRV records, 6186 scales just fine.  No SNI, nothing
but SRV records that have the domain name that should match the DNS-ID
the server presents.  What am I missing?

On the other hand, if you need the SRV-ID records, a server that
supports two domains is going to be just as schrod if the domains
don't happen to bear a relationship to the DNS-ID that CAs can verify.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 04 Dec 2015 12:53:47 +0000

Hi Harald,

>> On Thu, Dec 03, 2015 at 12:53:25PM +0100, Harald Alvestrand wrote:
  [...]

> What I want the document to call out is that there are known, important use
I think this is fair. I would prefer to document existing 
limitations/problems.

I will work on some text on this.

Best Regards,
Alexey

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Dec 2015 20:52:54 +0100

> document doesn't say how to solve it".

Painful = non-zeroconf, but why?.  An easy way to host 50,000 email domains
without DNSSEC is to redirect them all to the same SRV targets.  A few
certificates suffice.  The client-side "oneconf" setup should then ask:

   Is your mail hosted by <mail.example>? [confirm] [deny]

Possibly, it would also recall that property upon request.  I wouldn't call
"painful" getting such awareness, I'd be grateful.

IMHO, the above way is better than defining 50,000 email servers without proper
certificates, or without DNSSEC.  Can the I-D say so?

Ale