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

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

On Tue, Dec 01, 2015 at 03:34:32PM +0100, Harald Alvestrand wrote:

> 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.

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.

HOWEVER:

> 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:

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?

> - Change its certificate to include a complete list of all the domains
> 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

> 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.

See above.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2015 18:38:02 -0000

>DNSSEC.  So "another" might become "only" in that case.

Then we have a problem, since the SRV-ID is just an assertion from the
server.  What's to keep an evil MITM from putting dukhovni.org as a
SRV-ID in its submit and imaps certificate?  If the cert is signed,
the signer will look at the DNS-ID.  There's no way other than RFC
6186 to tell what the real pop or imap servers for a domain are.

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

In the lack of plausible alternatives, I think so.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Dec 2015 18:59:16 +0000

On Tue, Dec 01, 2015 at 06:38:02PM -0000, John Levine wrote:

> server.
> What's to keep an evil MITM from putting dukhovni.org as a
> SRV-ID in its submit and imaps certificate?

The trusted CA presumably, if it is not negligent.

> In the lack of plausible alternatives, I think so.

Well, the plausible alternatives are explicit static configuration
of the server names by the user, per instruction from the provider.
This "out of band 6186" if you like.  That's largely what happens
today, except that for some popular providers, many user agents
come preloaded with default settings.

The other plausible alternatives are DNSSEC, or "ask the user".

-- 
	Viktor.

---

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

>The trusted CA presumably, if it is not negligent.

How is the trusted CA supposed to figure out which domains it should
allow as SRV-ID?  

Here's a concrete real life example: I have a pop and imap server
called imap.iecc.com.  (It even has a signed certificate.)  You're the
CA, what SRV-IDs will you allow?  You can ask me any questions you
want, but keep in mind that my answers are not always accurate.

>of the server names by the user, per instruction from the provider.

I understand that's how a user configures her MTA, but you'll have to
lay out in detail how the slip of paper in the user's hand tells a CA
what SRV-IDs they should have allowed in the server's certificate.

R's,
John

---

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

> Then we have a problem, since the SRV-ID is just an assertion from the
But it has to be signed by a CA. If the CA is not happy for you to 
assert SRV-ID, it should not include SRV-ID in an issued certificate.

---

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

Hi Harald,

On 01/12/2015 14:34, Harald Alvestrand wrote:
> - 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:
>
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.
> 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.
Best Regards,
Alexey

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2015 08:42:50 -0500

> But it has to be signed by a CA. If the CA is not happy for you to assert 
> SRV-ID, it should not include SRV-ID in an issued certificate.

Now I'm really confused.  Are you saying the SRV-ID is optional?  If so, 
what's the point of it?  In nearly all cases, there's no way for a CA to 
tell what SRV-IDs it should allow, so nobody will use them.

(This is in addition to the problems that a large mail host handles tens 
of thousands of domains, and the list changes every day.)

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2015 14:47:42 +0000

Hi John,

On 02/12/2015 13:42, John R Levine wrote:
> Now I'm really confused.  Are you saying the SRV-ID is optional?
I am saying that CAs can't sign what they can't validate. This is 
nothing new, the same applies to DNS-ID or CN-ID. So if a CA wants to 
sign SRV-ID, it needs a way to validate it.

> If so, what's the point of it?  In nearly all cases, there's no way 
> for a CA to tell what SRV-IDs it should allow, so nobody will use them.
Some enterprise CAs or CAs which are also MSPs might be able to validate 
SRV-IDs. Also when SRV record points to a subdomain of the right hand 
side, CA might treat this as allowed without validation.

> (This is in addition to the problems that a large mail host handles 
> tens of thousands of domains, and the list changes every day.)
>
> Regards,

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2015 15:17:16 -0000

>separate certificate with a single domain.

Given that there are mail services with tens of thousands of domains
on the same set of servers, and probably at least one mail service
with 100,000 domains, this really doesn't scale.

>From previous messages, I understand that both publishing and checking
SRV-ID are entirely optional.  It would be nice to adjust to draft to
make that clear.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2015 15:27:04 +0000

> with 100,000 domains, this really doesn't scale.
Yes, I can add a note about this. Also recommending use of SNI (case 1) 
might be a good idea.
> SRV-ID are entirely optional.  It would be nice to adjust to draft to
Ack, I will add some text along what we've discussed.

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2015 10:40:32 -0500

> Yes, I can add a note about this. Also recommending use of SNI (case 1) might 
> be a good idea.

If there's no SRV-ID, you don't need SNI since all 100,000 domains point 
at the same server name.

> Ack, I will add some text along what we've discussed.

Tnx.

Regards,

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2015 15:48:33 +0000

On 02/12/2015 15:40, John R Levine wrote:
>> Yes, I can add a note about this. Also recommending use of SNI (case 
>> 1) might be a good idea.
>
> If there's no SRV-ID, you don't need SNI since all 100,000 domains 
> point at the same server name.
Yes, but then they can't be verified automatically by MUAs, so each of 
them would need to be approved manually by users.

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2015 10:54:06 -0500

>> If there's no SRV-ID, you don't need SNI since all 100,000 domains point at 
>> the same server name.
> Yes, but then they can't be verified automatically by MUAs, so each of them 
> would need to be approved manually by users.

Aren't we back to RFC 6186?  If the MUA developers are going to open up 
the code to add new checks for the server's certificate, why not also add 
checks for the appropriate SRV records?  I realize that not everyone does 
DNSSEC, but the SRV check will be a lot more effective than yet another 
baffling warning that ends with "check OK if you ever want to see your 
mail again".

Regards,

---

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

On 02/12/2015 15:54, John R Levine wrote:
>> Yes, but then they can't be verified automatically by MUAs, so each 
>> of them would need to be approved manually by users.
>
> Aren't we back to RFC 6186?  If the MUA developers are going to open 
> up the code to add new checks for the server's certificate, why not 
> also add checks for the appropriate SRV records?  I realize that not 
> everyone does DNSSEC, but the SRV check will be a lot more effective 
> than yet another baffling warning that ends with "check OK if you ever 
> want to see your mail again".
If you can suggest a couple of sentences to add, that would be appreciated.