Subject: [Uta] WGLC draft-ietf-uta-email-tls-certs

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Apr 2015 21:34:43 +0200

Folks,

This starts a 2 week WGLC on draft-ietf-uta-email-tls-certs. Please
provide your comments on the UTA list before EOB (any TZ) Friday April
24 2015.

	Cheers Leif

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Apr 2015 09:46:37 -1000

> provide your comments on the UTA list before EOB (any TZ) Friday April

What is the reason for making SRV-ID support required for email client
software implementations? I've written certificate verification code
that is used in one email client (Mozilla Thunderbird) that doesn't
support SRV-ID and there's currently no plan to add SRV-ID.

More generally, I think it would be good to avoid adding the
additional requirement that clients support SRV-ID support so that
email clients can use any RFC6125-compliant certificate verification
library.

That said, maybe I'm not understanding the importance of SRV-ID.
Clarification of why supporting SRV-ID is important would be useful.

Cheers,
Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Apr 2015 19:14:37 +0000

> Clarification of why supporting SRV-ID is important would be useful.

My understanding is that clients should support SRV-ID when they
locate the submission or IMAP service via SRV records.  Most MUAs
don't do SRV lookups for either, and therefore don't need to support
SRV-ID.

If a client supports DANE, and obtains DNSEC-validated SRV results,
and finds associated TLSA records for the target service endpoint,
then again its primary reference identifier is the target DNS name.

However, with DANE, this or a follow-on document needs to specify
whether SRV-ID should be supported as a secondary identifier to
support mixed deployments in which the SRV-ID certificate is the
only only one available.

While DANE might not pan out, I think that new specifications (such
as this one) need to cover interaction with DANE, so that implementors
know how to build interoperable software with or without DANE support.

So I would urge the group to at least discuss, but ideally add a
description of how DANE fits into MUA certificate verification,
when the MUA supports DANE.  I am more than willing to help
review new text in that direction.

-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Sat, 11 Apr 2015 13:08:59 -1000

Viktor Dukhovni <[email-masked]> wrote:
> Brian Smith wrote:

Even if the client uses SRV records, it will still operate just fine
using DNS-IDs and without supporting SRV-ID, right?

I re-read what RFC 6125 says about using SRV-IDs instead of DNS-IDs to
restrict which services a certificate is valid for. I also read RFC
6186 regarding the use of SRV records to support email client
auto-configuration. The goals of each seem reasonable. But, it seems
too early to mandate SRV-ID support.

First, note that the CABForum Baseline Requirements [1] say, regarding
subjectAltName: "This extension MUST contain at least one entry. Each
entry MUST be either a dNSName containing the Fully-Qualified Domain
Name or an iPAddress containing the IP address of a server." Thus, a
certificate that conforms to the CABForum Baseline Requirements MUST
NOT contain any SRV-ID subjectAltNames.

It is reasonable--some would even say good--for a MUA to use
certificate verification logic that only validates certificates that
are valid according to the CABForum Baseline Requirements. In that
case, the certificate verification logic doesn't need to support
SRV-ID at all, since instead it should reject--or, if it wants to be
liberal, ignore--all SRV-ID subjectAltName entries.

Further, because of what the CABForum Baseline Requirements say, it
seems like it would be very difficult to get a certificate that
contains SRV-ID subjectAltNames from a CA that typical MUAs trust.

Are there any existing MUAs, certificate verification libraries,
and/or mail servers that implement support for SRV and SRV-ID that can
be used for interop testing? Has any interop testing been done yet? I
think such interop testing should be done before SRV-ID support is
mandated or recommended.

> support mixed deployments in which the SRV-ID certificate is the

I would expect that if a certificate is involved then the certificate
will be used, and that DANE will be used only to help authenticate the
certificate. Otherwise, there wouldn't be a certificate involved and
the document wouldn't be applicable, right?

Cheers,
Brian

[1] https://cabforum.org/wp-content/uploads/BRv1.2.5.pdf

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Apr 2015 03:16:53 +0000

> using DNS-IDs and without supporting SRV-ID, right?

Well, without DANE, all the various hosts providing the service,
would now certificates for the name of the service domain, rather
than just the service for which they are targets, some of these
might be hosting providers for just that service.  So there use-cases
in which it is highly desirable that all clients either don't do SRV
lookups, or if they do, that they support SRV-ID.

> NOT contain any SRV-ID subjectAltNames.

Times change.  CAs can issue new certificates if there is demand.
The first step is client support, then server operators can start
asking for these once enough clients are on board.

We're also going to ask CAs to support Curve 25519 certs, later
new hash functions...

> are valid according to the CABForum Baseline Requirements.

The CAB forum is all about browsers, not too much represenation
from the email world there.

> In that

That cripples non-DANE email hosting, and makes security for hosted
RFC 6186 services rather tricky (leap of faith).

> contains SRV-ID subjectAltNames from a CA that typical MUAs trust.

Clients can support the extension before any such certificates are
available.  The draft is not mandating that clients *only* support
SRV-ID.  Once MUAs routinely support SRV-ID, servers can start
deploing it.  This is how progress is made.  It takes time.

I don't much care what the CAB forum has espoused, they have a
narrow and short-term view of the world.

> be used for interop testing?

They need to be built.  Help would be appreciated.  I'll look into
adding support in OpenSSL.  You might help with NSS, ...

> the document wouldn't be applicable, right?

DANE is indeed mostly about explicit trust anchors, however DNSSEC
protects otherwise insecure service redirection (SRV, MX, CNAME,
...) and makes it possible to authenticate the target, so reference
identities with DANE are different than without (indeed entirely
ignored with DANE-EE(3) for which the peer identity is validated
exclusively through DNS).

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.1.1
    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.1.2
    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.2.1
    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.2.2

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Apr 2015 15:57:22 +0100

Hi Brian,

On 12/04/2015 00:08, Brian Smith wrote:
>> locate the submission or IMAP service via SRV records.
Correct.
>> Most MUAs
In general case this is not true. This will only work correctly  if DNS 
SRV is pointing to a server in the same DNS domain.

Take for example a case where email addresses @example.com are 
outsourced to another provider, e.g. gmail.com
When a client connects to IMAP service for example.com, it needs to know 
that imap.gmail.com is a legitimate server for this service. So either 
imap.gmail.com's TLS certificate needs to include sRVName 
_imap.example.com or it needs to include dNSName for example.com. The 
latter is of course problematic if only IMAP service is delegated to 
imap.gmail.com.

(And yes, DANE can be used to address this as well, but it depends on 
another service that need to be deployed)
> restrict which services a certificate is valid for.
Yes, this is the main part of it.
> I also read RFC
I would not interpret it like this, because CABForum can't talk for uses 
of TLS outside of the browser world.
XMPP uses presence of XMPP URIs (see Section 13.7.1.4 of RFC 6120) in 
subjectAltName for TLS verification. According to your interpretation 
CABForum certificates disallow XMPP use as well.

> Are there any existing MUAs,
Yes.
> certificate verification libraries,
and yes. I am tempted to collect more information and show examples of 
how this can be done in Java and using other open source libraries.
> be used for interop testing? Has any interop testing been done yet?
Not that I am aware of, but I am happy to talk about this off-list.
> I think such interop testing should be done before SRV-ID support is
> mandated or recommended.
Some comments:

1) I've looked at several big Mail Service Providers and pretty much all 
of them use DNS SRV to advertise location of their submission/imap 
servers. They don't user sRVName in subjectAltNames, which makes it 
impossible for email clients to verify whether such servers are 
legitimate. So I think something needs to be done to address this problem.

2) I am expecting that some CAs would be unable to validate/accept 
sRVNames in certificate signing requests. This can be intentional and 
can be covered by "local policy". But at least they must not crash and 
burn when they encounter sRVName in subjectAltNames.

3) This document is not reflecting universally widespread practice, 
because frankly too many email clients don't verify TLS certificates, 
and server certificates don't comply with very basic requirements 
expressed in much earlier RFCs. I don't believe there is a requirement 
for a Standard Track RFC to only reflect what is already deployed, in 
many cases Standard Track RFCs are drawing attention to what should be 
the recommended practice.

Best Regards,
Alexey

---

From: Brian Smith <[email-masked]>
Date: Mon, 13 Apr 2015 14:33:00 -1000

Alexey Melnikov <[email-masked]> wrote:
> In general case this is not true. This will only work correctly  if DNS SRV
> is pointing to a server in the same DNS domain.
>
> Take for example a case where email addresses @example.com are outsourced to
> another provider, e.g. gmail.com
> imap.gmail.com's TLS certificate needs to include sRVName _imap.example.com
> or it needs to include dNSName for example.com. The latter is of course
> problematic if only IMAP service is delegated to imap.gmail.com.

When the MUA connects to imap.gmail.com, how would the server know
which certificate to give the MUA? Would the MUA put
"_imap.example.com" in the SNI extension of the TLS ClientHello when
connecting to the GMail server? If so, where is it explained how
SRV-IDs are mapped to SNI? In particular, it seems like when RFC 6066
says "the only server names supported are DNS hostnames" it means SNI
must only be used with DNS-IDs. That seems problematic.

It also seems unreasonable to expect mail servers for GMail and other
large mail hosting servers to have certificates that contain SRV-IDs
that identify every single customer.

> I would not interpret it like this, because CABForum can't talk for uses of
> TLS outside of the browser world.

Many members of the CABForum consider the scope of the CABForum to
include all TLS certificates that can be *could* be used by a web
browser. More importantly, browser root CA inclusion programs
generally don't consider the needs of MUAs to be any different than
browsers as far as TLS certificates are concerned, so there's no
provisions for SRV-IDs. It is pretty typical for root stores to base
their set of root CA certificates on what browsers, Mozilla in
particular, include in their root CA programs, so I think that those
concerns are likely to limit the application of the advice in this
draft RFC unless/until the root inclusion policies are updated to deal
with SRV-IDs.

Yes.

> and yes. I am tempted to collect more information and show examples of how
> this can be done in Java and using other open source libraries.

I think it would be great to see a working example, especially as far
as SNI is concerned.

> 1) I've looked at several big Mail Service Providers and pretty much all of
> them use DNS SRV to advertise location of their submission/imap servers.
> They don't user sRVName in subjectAltNames, which makes it impossible for
> email clients to verify whether such servers are legitimate. So I think
> something needs to be done to address this problem.

I agree.

> 2) I am expecting that some CAs would be unable to validate/accept sRVNames
> in certificate signing requests. This can be intentional and can be covered
> by "local policy". But at least they must not crash and burn when they
> encounter sRVName in subjectAltNames.

otherName and uniformResourceIdentifier are intentionally ignored by
the Firefox/Thunderbird certificate verification, except that any
otherName or uniformResourceIdentifier name constraint at all in the
issuer certificate chain will automatically cause validation to fail.

> 3) This document is not reflecting universally widespread practice, because
> frankly too many email clients don't verify TLS certificates, and server
> certificates don't comply with very basic requirements expressed in much
> earlier RFCs. I don't believe there is a requirement for a Standard Track
> RFC to only reflect what is already deployed, in many cases Standard Track
> RFCs are drawing attention to what should be the recommended practice.

Like I said, I think generally the goal is a good one. However, the
mechanism seems problematic as far as deployment is concerned:

1. Root CA inclusion programs for Thunderbird and other MUAs need to
be updated to consider SRV-IDs, particularly what otherName name
constraints a "technically constrained externally-operated sub-CA"
must have.

2. Certificate verification logic needs to be extended to provide a
proper API and a proper implementation of that API for dealing with
SRV-IDs, because SRV-IDs need to be treated differently from DNS-IDs
(and CN-IDs), and current APIs are mostly/totally designed for
DNS-IDs.

3. It seems unreasonable to require that the mail hosting provider
have certificates with srvName subjectAltName entries for all
customers' DNS names. Even for moderately-sized hosts, this would seem
to require the management of a too-large number of certificates.

4. It isn't clear how a CA would go about securely verifying that a
mail hosting provider like GMail is authorized by a domain name owner
(e.g. example.com) to request and use a certificate with a srvName for
the domain name (e.g. GMail asking for an _imap.example.com
certificate). In practice, traditionally standardizing such practices
is done in the CABForum. If CABForum is inappropriate here, then how
will such issuing practices be standardized?

5. If the owner of example.com switches his hosting from
mail.gmail.com to mail.outlook.com, how does the owner of example.com
go about disabling the certificate containing srvName
_imap.example.com that mail.gmail.com is using?

It seems to me like it is worth considering an alternative mechanism
where it is possible for example.com to say that imap.gmail.com is
hosting its email for a certain duration of time, such that
imap.gmail.com doesn't need to get any certificate that specifically
mentions example.com, siimlar to the Alt-Svc mechanism for HTTP/2.

Cheers,
Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Apr 2015 19:42:15 +0000

On Mon, Apr 13, 2015 at 02:33:00PM -1000, Brian Smith wrote:

> connecting to the GMail server?

No, it would send the base domain "example.com".  The IMAP server would
need to know that an "_imap.exmaple.com" certificate is the right one
to return if that's what it has (absent an "example.com" certificate
on hand).

> browser.

They might presume to think so, but they don't really represent
the non-browser constituencies.

> constraints a "technically constrained externally-operated sub-CA"

Name constraints mostly don't work.  For example, name constraints
on the DNS subjectAltName are often not applied to the CN-ID, plus
the whole "critical" mess, ...

> (and CN-IDs), and current APIs are mostly/totally designed for

Yes, toolkits would need to add support for SRV-IDs.

> to require the management of a too-large number of certificates.

That's what SNI is for.  And better yet DANE, which obviates the
need for per-client certificates.

> certificate).

The the CA's job, the certificate would be obtained by the customer
and provisioned by the customer via a customer admin portal.

> In practice, traditionally standardizing such practices

CAs should never issue certificates for a domain to a third party.
So there's nothing to standardize.

> _imap.example.com that mail.gmail.com is using?

Revoke it (we'll pretend revocation works), and/or deprovision it
through the admin interface (before discontinuing the business
relationship) and expect that as a matter of contractual obligation
Gmail will not misuse the certificate for its remaining lifetime.

> mentions example.com, siimlar to the Alt-Svc mechanism for HTTP/2.

That's what DANE accomplishes.  DNSSEC-validated SRV records have
a signature TTL:

	_imap._tcp.example.com. IN SRV 0 0 143 imap.gmail.com.
	_imap._tcp.example.com. IN RRSIG SRV ... <expiration> <inception> ...

a DANE-enabled client finds imap.gmail.com's TLSA RRs and Gmail has no
need for any kind of example.com certificate.

	_143._tcp.imap.gmail.com. IN TLSA 3 1 1 <spki-sha256-digest>

-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Tue, 14 Apr 2015 15:14:16 -1000

> to return if that's what it has (absent an "example.com" certificate

Thanks. That's not what I expected. Do you know which part of which
RFC documents that?

> the whole "critical" mess, ...

For the purposes of Mozilla's root inclusion program, at least, the
name constraints work just fine, including covering CN-IDs, and
regardless of the critical flag. I agree that some implementations
have trouble with name constraints. However, name constraints are an
important part of some root CA inclusion policies, so we can't ignore
them with respect to srvName.

> Yes, toolkits would need to add support for SRV-IDs.

I think it is very likely that many toolkits won't add SRV-ID support
any time soon, if the way that implementers have ignored RFC 6120 is
any indication.

> need for per-client certificates.

How to select which certificate to send based on SNI is a small issue
relative to the general operational problem of managing thousands of
different certificates in order to support SRV-IDs.

> and provisioned by the customer via a customer admin portal.

Requesting a certificate usually requires proof of possession of the
private key. So, GMail would have to generate the CSR (or equivalent)
to give to the CA, not the customer.

> So there's nothing to standardize.

Sounds good, but I think it's fair to say that it is unclear how it
would actually work.

>         _143._tcp.imap.gmail.com. IN TLSA 3 1 1 <spki-sha256-digest>

It one is going to use DNS to do auto-configuration of email clients,
then I think this seems better than the SRV-ID-based approach. At
least it's clearer as to how it is supposed to work.

Thanks for answering my questions. I still think that the X.509
certificate with SRV-ID approach seems too impractical to expect
widespread enough adoption to make it worthwhile to implement the
infrastructure for it. Consequently, I think saying that clients MUST
or even SHOULD implement the SRV-ID-based approach is too much.

Thanks again,
Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Apr 2015 18:10:34 +0100

> Thanks. That's not what I expected. Do you know which part of which
RFC 6125.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Apr 2015 18:14:21 +0100

> or even SHOULD implement the SRV-ID-based approach is too much.
I respectfully disagree in absence of any technical or legal explanation 
of why SRV-ID would not work.

(I will reply to you with examples of how this can be already done with 
existing toolkits - at least several of them require no new API. I am a 
bit short on time at the moment).

---

From: Rick Andrews <[email-masked]>
Date: Wed, 15 Apr 2015 10:23:32 -0700

> The the CA's job, the certificate would be obtained by the customer and provisioned by the customer via a customer admin portal.

I think what's being asked is how would the CA do the verification before issuing the cert?

>> In practice, traditionally standardizing such practices is done in the 
>> CABForum. If CABForum is inappropriate here, then how will such 
>> issuing practices be standardized?

> So there's nothing to standardize.

We do it all the time. You outsource your web site to a hosting company, and the hosting company applies for and gets the cert on your behalf.

-Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Apr 2015 02:04:42 +0000

On Wed, Apr 15, 2015 at 10:23:32AM -0700, Rick Andrews wrote:

> > The the CA's job, the certificate would be obtained by the customer and
> > provisioned by the customer via a customer admin portal.
> 

All the CA is ever expected to verify is that the customer in
question is the rightful "owner" of the name in the certificate.

How services associated with that name are hosted is irrelevant,
that's between the customer and service provider.

> We do it all the time. You outsource your web site to a hosting
> company, and the hosting company applies for and gets the cert on
> your behalf.

However common, or even essential to support various business
practices, this is rather a bad idea.  It means that the whole
system is fundamentally broken.  But I rant, this is going off-
topic.

The issuance of SRV-ID is no different than the issuance of CN-ID
or DNS-ID.  The only new thing is that it has not been used very
much to date.  Regardless of where in the certificate the name is
recorded, or the exact "type" or "format" of the name, the real
issue is supporting multi-tenant hosting of domains by other domains,
which maps poorly into the Web PKI.

This draft is just trying to limit the scope of certificates that
clients delegate to providers.  DANE eliminates the need entirely.

I don't know whether SRV-ID is likely to see much adoption.  It is
a logically and technically sound idea, but it remains to be seen
whether it is a practically sound idea.  Ditto for DANE.  So we
perhaps we just try all the approaches and see what works.

Note that SRV-ID does not displace DNS-ID or CN-ID, indeed the same
SNI domain is sent regardless.  All that SRV-ID does, is *allow*
the server to respond with an SRV-ID if when that's all the hosted
provider has on hand.  If the customer, provider and CA "conspire"
to provision a certificate for the entire domain (rather than a
particular service), that'll still work.

The first step is to ask RPs (Relying Parties) to accept SRV-ID
where applicable.  Then hosting providers, their customers and
CAs might figure out when to provision them, subject to demand
for such services.

Will SRV-ID actually get much traction?  No idea.

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Apr 2015 15:27:29 +0100

> think such interop testing should be done before SRV-ID support is
Here is OpenSSL code. I had to strip code unrelated to this discussion, 
so this might not compile as is, but should be easily fixable for 
somebody who can use OpenSSL:

static int g_srv_nid;

Do this once somewhere:

g_srv_nid = OBJ_create("1.3.6.1.5.5.7.8.7",
     "id-on-srvName", "SRV alt name");

Input for the code below: X509 * cert
{
     X509_EXTENSION *subject_alt_name = NULL;
     STACK_OF(GENERAL_NAME) *alt_names = NULL;
     GENERAL_NAME *alt_name;
     int pos, i;
     bool rc = false;
     char buf[1024];
     unsigned char *s;
     X509_NAME * subject_name;
     X509_NAME_ENTRY *e;
     ASN1_STRING * d;
     char idna_buf[1024];

     for (pos = X509_get_ext_by_NID(cert, NID_subject_alt_name, -1);
     pos != -1;
     pos = X509_get_ext_by_NID(cert, NID_subject_alt_name, pos)) {
     /* Walking each extension... */
     if ((subject_alt_name = X509_get_ext(cert, pos)) == NULL) break;
     if ((alt_names = X509V3_EXT_d2i(subject_alt_name)) == NULL) break;

     for (i = 0; i < sk_GENERAL_NAME_num(alt_names); ++i) {
         if ((alt_name = sk_GENERAL_NAME_value(alt_names, i)) == NULL) 
break;

         /* Now look for Subject Alt Name types we understand,
         * and might use. */
         switch (alt_name->type) {
         case GEN_OTHERNAME:
         if (OBJ_obj2nid(alt_name->d.otherName->type_id) == g_srv_nid) {
             ASN1_STRING_to_UTF8(&s, 
alt_name->d.otherName->value->value.utf8string);

             if (s) {
             /// s contains _<service>.<domain>
             /// Match against the requested domain. Set rc to true if 
successful.

             OPENSSL_free(s);
             }
         }
         break;

         case GEN_DNS:
         {
             char * p = buf;
             ASN1_STRING_COPY(buf, sizeof(buf), alt_name->d.dNSName);

             /// p points to hostname

             /// Match against the requested domain. Set rc to true if 
successful.
         }
         break;
         }

         if (rc) break;
     }

     GENERAL_NAMES_free(alt_names);
     if (rc) goto cleanup;
     }

cleanup:
     ...
}