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 ietf@xxxxxxxx. S. > > 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. > > > > > > >