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

[[e-mail]]

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 [e-mail].  

S.




> 
> Unless I don’t see a good justification, please stop it.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Mensaje original-----
> De: ietf <[e-mail]> en nombre de Viktor Dukhovni <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: martes, 24 de noviembre de 2015, 6:51
> Para: <[e-mail]>, <[e-mail]>
> 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.
> >
> >
> 
> 
>