Speaking as sergeant-at-arms. There is any real need to cross-post to the general area explorer ? Unless I don’t see a good justification, please stop it. Regards, Jordi -----Mensaje original----- De: ietf <ietf-bounces@xxxxxxxx> en nombre de Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> Responder a: <ietf-dane@xxxxxxxxxxxx> Fecha: martes, 24 de noviembre de 2015, 6:51 Para: <ietf@xxxxxxxx>, <uta@xxxxxxxx> 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 >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. > >