Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt

[Viktor Dukhovni <[e-mail]>]

On Tue, Nov 05, 2013 at 05:01:54PM -0800, Chris Newman wrote:

> I have read draft-ietf-dane-smtp-with-dane-02.txt and support
> advancing it on standards track if three changes* are made to the
> document as mentioned in my comments below. I believe this is a
> plausible strategy to improve security/privacy for SMTP relay and is
> close to ready for publication.

Thanks for the feedback.  The primary points of contention appear
to be:

    - Objection to DANE TLSA for submission.

    - Objection to requirement to match any of multiple peer names.

    - Suggestion that SMTP servers not offer TLS if the configured trust
      chain lacks a suitable TA.

    - Objection to text recommending anonymous cipher support on
      the server.

My response to each below:

- DANE for SMTP Submission

   * This is good measure a response to RFC6409 which introduces
     SRV records as a means to offer zeroconf MSA deployments.

     With the client having no securely obtained name to check in
     the peer certificate, the peer certificate is unusable, one
     can check it is valid, but one check that it names the right
     server.

     My contention is that MUA + SRV is in the same boat as MTA + MX
     and the only practical way to make either secure is DANE.

     Once we have at least one use-case for MUA + DANE, there is
     also the use case in which the server administrator and MUA
     user prefer to use DANE.  There needs to be standard for this,
     and an SMTP + DANE RFC seemed like a fine place to cover this.

- Objection to multiple peer names.

   * This was adopted from Tony's expired SRV draft.  I agree with
     the motivation to interoperate with existing practice.  It is
     already common in bilateral SMTP security configurations to
     field certificates that match the recipient domain, not the
     MX host.  Public CAs even market (I may have misremembered
     the name) Unified Messaging Certificates.

     So DANE SMTP clients need to be prepared to encounter certificates
     tailored to a pre-DANE world.

     Postfix (widely deployed) supported multiple name values, even
     before DANE.  This is IMHO not a major obstacle.

- SMTP server chain sanity checks

   * This is rather tricky.  An SMTP server does not generally know whether
     it is doing DANE or not, clients know whether they are doing DANE
     when they obtain (or fail to obtain) appropriate TLSA records.

     To determine whether it is missing a TA cert, a server would
     have to look up TLSA records for all relevant domains, locate
     the MX record that identifies it, obtain the TLSA RRset.  If
     that RRset has usage 2 entries, after (in the SNI use-case)
     figuring out which chain applies to that domain, it then needs
     to validate the chain to see whether the required TA is present.

     I don't see ever implementing this for Postfix.  What I did
     implement is a command-line tool that allows one to probe SMTP
     server TLS support and determine whether TLS works, including
     tests of DANE verification when TLSA records are found.

     Server operators should test their servers from a client that
     is configured with zero trusted CAs and make sure that DANE
     works there, when DANE TLSA records are published.  We can
     give some more specific guidance to server operators on testing
     their deployment, perhaps in the ops draft, but I would not object
     to additional overlap in the SMTP draft.

- Anon ciphers

    * A substantial fraction of SMTP MTAs enable and will continue
      to enable anon ciphersuites when not authenticating the server.

    * The comment in the draft is recommending *server* server support
      for these.  If the client has already sent a HELLO message
      with a bunch of anon ciphersuites, the server may as well
      use one, and though it may prefer non-anon ciphers, its
      TLS stack should not fail just because anon ciphers were
      offered.

> 	The TLS protocol has interoperability problems if the client hello
> 	has too many cipher suites in it.

    * This issue may have been substantially addressed yesterday,
      see the the IETF TLS mailing list thread on ALPIN:

      http://www.ietf.org/mail-archive/web/tls/current/msg10423.html

      Avoiding client HELLO with length in [256,512) resolves the
      SSLv2 vs. SSLv3 HELLO ambiguity.

-- 
	Viktor.