Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Serv

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(_at_)ietf(_dot_)org.  

S.




> Unless I don’t see a good justification, please stop it.
>
> Regards,
> Jordi
>
>
>
>
>
>
>
>
>
> -----Mensaje original-----
> De: ietf <ietf-bounces(_at_)ietf(_dot_)org> en nombre de Viktor Dukhovni 
> <ietf-dane(_at_)dukhovni(_dot_)org>
> Responder a: <ietf-dane(_at_)dukhovni(_dot_)org>
> Fecha: martes, 24 de noviembre de 2015, 6:51
> Para: <ietf(_at_)ietf(_dot_)org>, <uta(_at_)ietf(_dot_)org>
> 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.