Subject: [Uta] Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 20 Nov 2015 06:29:25 -0800

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: Russ Housley <[email-masked]>
Date: Fri, 20 Nov 2015 16:36:41 -0500

I support this document going forward.  Below I suggest four improvements to the document.

(1)  In Introduction says:

   Note that this document doesn't apply to use of TLS in MTA-to-MTA
   SMTP.

Can this be enhanced to include a pointer to where this can be found?

(2)  The next paragraph in the Introduction says:

   The main goal of the document is to provide consistent TLS server
   identity verification procedure across multiple email related
   protocols.

Since this is a standards-track document, I think it would be better to say:

   This document provides a consistent TLS server identity
   verification procedure across multiple email related protocols.

(3)  Section 2 does a lot by reference, which is fine.  I think it would help the reader to duplicate a bit of context from RFC 6125, in particular repeating the definitions of CN-ID, DNS-ID, and SRV-ID.

(4)  Section 3 needs to state first that the certificate passes certification path validation as described in Section 6 of RFC 5280, and second passes the email-specific rules in this section.

Russ

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 21 Nov 2015 14:41:29 +0000

Hi Russ,
Thank you for your comments.

> Can this be enhanced to include a pointer to where this can be found?

Currently this is discussed in draft-friedl-uta-smtp-mta-certs, but this
is not a WG document, so I would rather not have a pointer.

>    verification procedure across multiple email related protocols.

Changed, thank you.

> (3)  Section 2 does a lot by reference, which is fine.  I think it would help the reader to duplicate a bit of context from RFC 6125, in particular repeating the definitions of CN-ID, DNS-ID, and S…

Yes, I struggled with this as well. This would be lots of cut & pasted
text.

> (4)  Section 3 needs to state first that the certificate passes certification path validation as described in Section 6 of RFC 5280, and second passes the email-specific rules in this section.

Yes, this was implied. Added to my copy.

---

From: "Leif Johansson" <[email-masked]>
Date: Sat, 21 Nov 2015 17:15:00 +0100

Skickat från min iPhone

> 21 nov. 2015 kl. 15:41 skrev Alexey Melnikov <[email-masked]>:
> 
> Hi Russ,

The energy seems to have run out in the group. We should not introduce dependencies that may needlessly hold publication imo.

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Nov 2015 10:10:01 -0500

Alexey:

Thanks for addressing my comments.  I think the CN-ID, DNS-ID, and SRV-ID definitions would be about 1/2 page.  Is that a lot of text?

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Nov 2015 05:11:47 +0000

> is not a WG document, so I would rather not have a pointer.

IIRC that document is not really intended to be standards track,
I think it is intended to be more of a BCP for facilitating explicit
secure-channels between domains that to manually configure mandatory
TLS security.  [I expect to be involved in further progress on that
document].

MTA-to-MTA at scale is opportunistic, and the relevant documents
for opportunistic discovery and use of TLS authentication in SMTP
are presently RFC 7435 and RFC 7672.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Nov 2015 05:51:41 +0000

> I support this document going forward.  Below I suggest four improvements to the document.

I also have some suggested improvements:

Section 2:

   reference identifier:  (as defined in [RFC6125]) One of the domain
      names associated by the email (i.e., an SMTP, IMAP, POP3 or
      ManageSieve) client with the destination email server and
      optionally an application service type for performing name checks
      on the server certificate.  When name checks are applicable, at
      least one of the reference identifiers MUST match an [RFC6125]
      DNS-ID or SRV-ID (or if none are present the [RFC6125] CN-ID) of
      the server certificate.

This speaks of a "destination email server", but none of the
protocols in question deliver email to its "destination".  These
are submission and mailstore access protocols.  So the phrase
"destination email server" is perhaps misleading.  I would
suggest replacing "destination" with "target".

Section 3:

   1.  For DNS-ID and CN-ID identifier types the client MUST use one or
       more of the following as "reference identifiers": (a) the right
       hand side of the email address, (b) the hostname it used to open
       the connection (without CNAME canonicalization).  The client MAY
       also use (c) a value securely derived from (a) or (b), such as
       using "secure" DNSSEC validated lookup.

The problem here is that "the right hand side of the email address"
is not clearly defined, which email address?  It seems that the
email address in question here is that of the user (performing mail
submission or accessing his own mailbox).  Also I would replace
"right hand side" with "domain part" (RFC 5322 email addresses are
<localpart@domainpart>).

   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.

As noted in Section 7 of RFC7672, when (don't know of any MUAs that
do this now) MUAs start using DNS SRV records to indirectly map
service domains to target servers, the WebPKI security model breaks
down in some of the same ways as it does for SMTP with MX records
(https://tools.ietf.org/html/rfc7672#section-1.3.2).  In particular,
using the target server hostname from from the SRV record is not
secure unless that SRV record is protected with DNSSEC.  Once
it is protected with DNSSEC and the client has the capacity to
perform the verification, it may as well do DANE (since it
then unavodably trusts the DNS).

The upshot is that once 6186 comes into play the text from part
"1" is no longer applicable as-is.  This is because (b) is no longer
securely obtained (absent DNSSEC it is the result of an insecure
SRV lookup).  So part (b) of "1" only applies when DNSSEC is
available.  However SRV-ID is fine, because it is the domainpart
of the user's email address and not subject to active attacks on
DNS.  This is why in the second numbered list we have (without
the rationale):

   2.  Support for the SRV-ID identifier type (subjectAltName of SRVName
       type [RFC4985]) is REQUIRED for email client software
       implementations that support [RFC6186].  List of SRV-ID types for
       email services is specified in [RFC6186].  For the ManageSieve
       protocol the service name "sieve" is used.

and then correspondingly in section 5:

   2.  If the email services provided are discoverable using DNS SRV as
       specified in [RFC6186], the Mail Service Provider MUST include
       the SRV-ID identifier type (subjectAltName of SRVName type
       [RFC4985]) for each type of email service in Certificate Signing
       Requests.

and in the examples in Section 6, which describe only SRV-IDs and
not (insecure) DNS-IDs in combination with services discovered via
RFC 6186 SRV records.

Section 6:

More instances of "right hand side" rather than "domainpart".

Section 8:

   TLS Server Identity Check for Email relies on use of trustworthy DNS
   hostnames when constructing "reference identifiers" that are checked
   against an email server certificate.  Such trustworthy names are
   either entered manually (for example if they are advertised on a Mail
   Service Provider's website), explicitly confirmed by the user (e.g.
   if they are a target of a DNS SRV lookup) or derived using a secure
   third party service (e.g.  DNSSEC-protected SRV records which are
   verified by the client or trusted local resolver).  Future work in
   this area might benefit from integration with DANE [RFC6698], but it
   is not covered by this document.

This repeats RFC 6186's waving of the "explicitly confirmed by the
user" magic wand to make a fundamental gap in the security model
appear to go away.  The rest of the document seems to require
SRV-IDs to avoid this trap, but here suddenly we're back to accepting
DNS-IDs arrived at via insecure SRV records, and we just "ask the
user".

So the question is whether in fact that's the approach, in which
case the earlier insistence on SRV-IDs is weakened and perhaps too
strong, or whether this is not the case, and the security considerations
should specifically explain the issue and state that asking the
user is not a good idea, and the the solution is the new SRV-IDs
as specified in this document.

[ Other options might be DANE 7671/7671, or POSH 7711. ]

--
	Viktor.

---

From: [email-masked]
Date: Tue, 24 Nov 2015 10:42:16 +0000

On Tue Nov 24 08:40:50 2015 GMT, JORDI PALET MARTINEZ wrote:
> Speaking as sergeant-at-arms.
> 
> There is any real need to cross-post to the general area explorer ?

The document is in ietf last call so it is entirely appropriate to send to [email-masked].  

S.

> 
> Unless I don’t see a good justification, please stop it.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Mensaje original-----
> De: ietf <[email-masked]> en nombre de Viktor Dukhovni <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: martes, 24 de noviembre de 2015, 6:51
> Para: <[email-masked]>, <[email-masked]>
> Asunto: Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Nov 2015 13:30:16 +0000

Hi Russ,

> Thanks for addressing my comments.  I think the CN-ID, DNS-ID, and SRV-ID definitions would be about 1/2 page.  Is that a lot of text?
If you are only suggesting to adding this:

       *  CN-ID = a Relative Distinguished Name (RDN) in the certificate
          subject field that contains one and only one attribute-type-
          and-value pair of type Common Name (CN), where the value
          matches the overall form of a domain name (informally, dot-
          separated letter-digit-hyphen labels); see [PKIX  <https://tools.ietf.org/html/rfc6125#ref-PKIX>] and also
          [LDAP-SCHEMA  <https://tools.ietf.org/html/rfc6125#ref-LDAP-SCHEMA>]

       *  DNS-ID = a subjectAltName entry of type dNSName; see [PKIX  <https://tools.ietf.org/html/rfc6125#ref-PKIX>]

       *  SRV-ID = a subjectAltName entry of type otherName whose name
          form is SRVName; see [SRVNAME  <https://tools.ietf.org/html/rfc6125#ref-SRVNAME>]

       *  URI-ID = a subjectAltName entry of type
          uniformResourceIdentifier whose value includes both (i) a
          "scheme" and (ii) a "host" component (or its equivalent) that
          matches the "reg-name" rule (where the quoted terms represent
          the associated [ABNF  <https://tools.ietf.org/html/rfc6125#ref-ABNF>] productions from [URI  <https://tools.ietf.org/html/rfc6125#ref-URI>]); see [PKIX  <https://tools.ietf.org/html/rfc6125#ref-PKIX>] and
          [URI  <https://tools.ietf.org/html/rfc6125#ref-URI>]

then it would be alright. If we start explaining reference identifiers, 
etc., then it is much harder job and I an worried of not copying enough, 
which can make this misleading when compared to RFC 6125.
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 24 Nov 2015 22:26:28 +0100

Hi,

>     Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.

The introduction of the draft explains that one of the goal is to define 
consistent rules between a few protocols implemented at the same time in 
email clients:

    Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is
    described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804]
    respectively.  Each of the documents describes slightly different
    rules for server certificate identity verification (or doesn't define
    any rules at all).  In reality, email client and server developers
    implement many of these protocols at the same time, so it would be
    good to define modern and consistent rules for verifying email server
    identities using TLS.

Couldn't the draft also update Section 5 of RFC 4642 about the use of 
TLS in NNTP?
The NNTP protocol is also a protocol that is found in email clients, so 
it would make sense to have consistent rules between email and netnews.
For instance, Thunderbird, SeaMonkey, Gnus, Opera Mail, Windows Live 
Mail, Forté Agent or tin (to mention only them) are both email and 
netnews clients.

Amongst other things, Section 5 of RFC 4642 says:

    During the TLS negotiation, the client MUST check its understanding
    of the server hostname against the server's identity as presented in
    the server Certificate message, in order to prevent man-in-the-middle
    attacks.  Matching is performed according to these rules:

    -  The client MUST use the server hostname it used to open the
       connection (or the hostname specified in TLS "server_name"
       extension [TLS-EXT]) as the value to compare against the server
       name as expressed in the server certificate.  The client MUST NOT
       use any form of the server hostname derived from an insecure
       remote source (e.g., insecure DNS lookup).  CNAME canonicalization
       is not done.

    -  If a subjectAltName extension of type dNSName is present in the
       certificate, it SHOULD be used as the source of the server's
       identity.

    -  Matching is case-insensitive.

    -  A "*" wildcard character MAY be used as the left-most name
       component in the certificate.  For example, *.example.com would
       match a.example.com, foo.example.com, etc., but would not match
       example.com.

    -  If the certificate contains multiple names (e.g., more than one
       dNSName field), then a match with any one of the fields is
       considered acceptable.

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

    Additionally, clients MUST verify the binding between the identity of
    the servers to which they connect and the public keys presented by
    those servers.  Clients SHOULD implement the algorithm in Section 6
    of [PKI-CERT] for general certificate validation, but MAY supplement
    that algorithm with other validation methods that achieve equivalent
    levels of verification (such as comparing the server certificate
    against a local store of already-verified certificates and identity
    bindings).

Or another idea:  wouldn't the draft be worthwhile for a BCP like BCP 
195 "Recommendations for Secure Use of Transport Layer Security (TLS) 
and Datagram Transport Layer Security (DTLS)"?

It could indeed be "Recommendations for TLS Server Identity Check 
Procedure".  The advantage would be that the BCP can apply to email 
protocols, as well as other protocols using TLS.
It would save time for others, and permit to have homogeneity and 
consistent rules across protocols, as well as increasing security.

-- 
Julien ÉLIE

« Destiny decides who you meet in life but it's only your heart that
   can decide who gets to stay in your life. »

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Nov 2015 20:55:45 +0000

Hi Julien,

> On 24 Nov 2015, at 21:26, Julien ÉLIE <[email-masked]> wrote:
> 
> Couldn't the draft also update Section 5 of RFC 4642 about the use of TLS in NNTP?
> The NNTP protocol is also a protocol that is found in email clients, so it would make sense to have consistent rules between email and netnews.
 (Snip)
> 
> Or another idea:  wouldn't the draft be worthwhile for a BCP like BCP 195 "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"?
> 
> It could indeed be "Recommendations for TLS Server Identity Check Procedure".  The advantage would be that the BCP can apply to email protocols, as well as other protocols using TLS.
> It would save time for others, and permit to have homogeneity and consistent rules across protocols, as well as increasing security.

Early on the WG decided to not do that and deal with different types of protocols separately. For example, requirements on XMPP and email are a bit different, so separate documents are the best. But of course nothing prevents people from publishing another document saying "do the same thing as this other specification, just use different SRV labels" (for example).

Best Regards,
Alexey

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Nov 2015 13:04:11 +0100

> Early on the WG decided to not do that and deal with different types of protocols separately. For example, requirements on XMPP and email are a bit different, so separate documents are the best. Bu…

Indeed.