On Fri, Nov 20, 2015 at 04:36:41PM -0500, Russ Housley wrote:
> 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.