Loading ...
Sorry, an error occurred while loading the content.

Re: Verification of DANE TLSA MX equivalent RRs

Expand Messages
  • Viktor Dukhovni
    ... It is inaccurate. The posttls-finger utility has been included in Postfix snapshots since postfix-2.11-20130602. The best snapshot for DANE support at
    Message 1 of 10 , Sep 18, 2013
    • 0 Attachment
      On Wed, Sep 18, 2013 at 05:49:53PM +0200, Stefan Foerster wrote:

      > I noticed that posttls-finger is not part of any upstream source I
      > could find, leading me to github - is that intentional?

      It is inaccurate. The posttls-finger utility has been included in
      Postfix snapshots since postfix-2.11-20130602. The best snapshot
      for DANE support at this time is:

      postfix-2.11-20130825.

      What is intentional is that while posttls-finger is compiled by
      default, it is not by default installed into $command_directory by
      postfix-install (because it is not listed in conf/postfix-files).

      I have not yet convinced Wietse that this diagnostic tool should
      be part of the required Postfix command set. One might note that
      smtp-sink and smtp-source are likewise not installed by default.

      My take is that posttls-finger is more useful on a day-to-day basis
      at sites that configure secure-channel TLS policy with peers, and/or
      want to diagnose TLS interoperability issues. Whether this is a
      strong enough argument to include posttls-finger in the Postfix
      pacakges delivered by O/S releases is a judgement call.

      --
      Viktor.
    • Stefan Foerster
      ... Would that be draft-ietf-dane-smtp-01? Because this one, too, explicitely doesn t cover mail submission. Stefan
      Message 2 of 10 , Sep 19, 2013
      • 0 Attachment
        * Viktor Dukhovni <postfix-users@...>:
        > On Wed, Sep 18, 2013 at 03:27:14PM +0200, Stefan Foerster wrote:
        > > And while we are at it, one more question, slightly unrelated:
        > > draft-dukhovni-dane-ops-01 does not mention MSAs. Is it commonly
        > > expected that user agents will not support TLSA RRs?
        >
        > You should be looking at the SMTP draft, not the OPS draft. [...]

        Would that be draft-ietf-dane-smtp-01? Because this one, too,
        explicitely doesn't cover mail submission.


        Stefan
      • Viktor Dukhovni
        ... No: https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 with work-in-progress snapshots at: http://vdukhovni.github.io/ietf/ The DANE WG
        Message 3 of 10 , Sep 19, 2013
        • 0 Attachment
          On Thu, Sep 19, 2013 at 10:44:27AM +0200, Stefan Foerster wrote:

          > * Viktor Dukhovni <postfix-users@...>:
          > > On Wed, Sep 18, 2013 at 03:27:14PM +0200, Stefan Foerster wrote:
          > > > And while we are at it, one more question, slightly unrelated:
          > > > draft-dukhovni-dane-ops-01 does not mention MSAs. Is it commonly
          > > > expected that user agents will not support TLSA RRs?
          > >
          > > You should be looking at the SMTP draft, not the OPS draft. [...]
          >
          > Would that be draft-ietf-dane-smtp-01? Because this one, too,
          > explicitely doesn't cover mail submission.

          No:

          https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01

          with work-in-progress snapshots at:

          http://vdukhovni.github.io/ietf/

          The DANE WG voted in Berlin to adopt the SMTP and OPS drafts, so future
          versions at ietf.org will have a different name (TBD).

          --
          Viktor.
        • Stefan Foerster
          ... I see. So, for joe.user@example.com the whole setup would probably be something along: - publish SRV record for _submission._tcp SRV 0 1 587
          Message 4 of 10 , Sep 20, 2013
          • 0 Attachment
            * Viktor Dukhovni <postfix-users@...>:
            > On Thu, Sep 19, 2013 at 10:44:27AM +0200, Stefan Foerster wrote:
            > > * Viktor Dukhovni <postfix-users@...>:
            > > > You should be looking at the SMTP draft, not the OPS draft. [...]
            > > Would that be draft-ietf-dane-smtp-01? Because this one, too,
            > > explicitely doesn't cover mail submission.
            > No:
            >
            > https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01

            I see. So, for joe.user@... the whole setup would probably be
            something along:

            - publish SRV record for _submission._tcp SRV 0 1 587 mail.example.com
            - publish TLSA record for mail.example.com - one might think about
            certificate usage 0 or 1 here, right?
            - make sure the submission server at mail.example.com has certificates
            for mail.example.com as well as example.com, with example.com being
            the certificate that's displayed when the client does't support SNI,
            at least according to draft-fanf-dane-mua-00

            I can see why you are being sceptical about MUA support for this. And,
            from an ops PoV, the requirement of having two certificates, one for
            the server hostname and one for the mail domain, with the need of
            obtaining both from a CA that has widepread support amongst MUAs, with
            the further need to provide two endpoints, one for old and one for new
            clients, is a real PITA.

            JFTR: The second mentioning of RFC6409 in section 3 of
            draft-dukhovni-smtp-opportunistic-tls-01 might possibly be a typo,
            referring to RFC6186.


            Stefan
          • Viktor Dukhovni
            ... Yes. Though it will be some time before most MUAs are zeroconf in this way. Perhaps the mobile device OSs will lead here, but it is also possible that
            Message 5 of 10 , Sep 20, 2013
            • 0 Attachment
              On Fri, Sep 20, 2013 at 11:47:35AM +0200, Stefan Foerster wrote:

              > I see. So, for joe.user@... the whole setup would probably be
              > something along:
              >
              > - publish SRV record for _submission._tcp SRV 0 1 587 mail.example.com

              Yes. Though it will be some time before most MUAs are zeroconf in
              this way. Perhaps the mobile device OSs will lead here, but it is
              also possible that each platform will simply assume you're using
              their "cloud" email service, and not choose to support RFC 6186.

              > - publish TLSA record for mail.example.com - one might think about
              > certificate usage 0 or 1 here, right?

              No. Whenever there is indirection between the user specified
              destination and the name of the ultimate TCP endpoint host, and
              especially when TLS support is discovered rather (also requiring
              DNSSEC to avoid downgrade attacks) the public CA PKI is inapplicable
              without DNSSEC, so the same guidelines apply, usage 2/3 only.

              > - make sure the submission server at mail.example.com has certificates
              > for mail.example.com as well as example.com, with example.com being
              > the certificate that's displayed when the client does't support SNI,
              > at least according to draft-fanf-dane-mua-00

              No need. One certificate is enough. With certificate usage 2 TLSA
              RRs, just point the SRV record at the same name that users who
              don't rely on zeroconf via RFC 6186 are told to set as their SMTP
              server. With certificate usage 3 TLSA RRs, the name in the
              certificate is irrelevant.

              > from an ops PoV, the requirement of having two certificates, one for
              > the server hostname and one for the mail domain, with the need of
              > obtaining both from a CA that has widepread support amongst MUAs, with
              > the further need to provide two endpoints, one for old and one for new
              > clients, is a real PITA.

              There is no such need, the draft RFC allows server operators to use
              *either* name (whichever they prefer), and requires clients to support
              both. There is NO requirement for server operators to publish both.

              > JFTR: The second mentioning of RFC6409 in section 3 of
              > draft-dukhovni-smtp-opportunistic-tls-01 might possibly be a typo,
              > referring to RFC6186.

              Thanks, yes, I'll fix that.

              --
              Viktor.
            • Stefan Foerster
              ... To be honest, that s not what I read from section 4 of ... Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01? Stefan P.S: I feel that we
              Message 6 of 10 , Sep 20, 2013
              • 0 Attachment
                * Viktor Dukhovni <postfix-users@...>:
                > On Fri, Sep 20, 2013 at 11:47:35AM +0200, Stefan Foerster wrote:
                > > - make sure the submission server at mail.example.com has certificates
                > > for mail.example.com as well as example.com, with example.com being
                > > the certificate that's displayed when the client does't support SNI,
                > > at least according to draft-fanf-dane-mua-00
                >
                > No need. One certificate is enough. With certificate usage 2 TLSA
                > RRs, just point the SRV record at the same name that users who
                > don't rely on zeroconf via RFC 6186 are told to set as their SMTP
                > server. With certificate usage 3 TLSA RRs, the name in the
                > certificate is irrelevant.
                >
                > > from an ops PoV, the requirement of having two certificates, one for
                > > the server hostname and one for the mail domain, with the need of
                > > obtaining both from a CA that has widepread support amongst MUAs, with
                > > the further need to provide two endpoints, one for old and one for new
                > > clients, is a real PITA.
                >
                > There is no such need, the draft RFC allows server operators to use
                > *either* name (whichever they prefer), and requires clients to support
                > both. There is NO requirement for server operators to publish both.

                To be honest, that's not what I read from section 4 of
                draft-fanf-dane-mua-00:

                | A mail server that is the target of an [RFC6186] SRV record MUST have
                | a TLS certificate that authenticates the SRV owner domain (i.e. the
                | user's mail domain). This is necessary for clients that cannot
                | perform DNSSEC validation. This certificate MUST be the default that
                | is presented if the client does not use the TLS Server Name Indication
                | extension (TLS SNI) [RFC6066].

                | In order to support this specification, the mail server MUST also have
                | a certificate that authenticates the SRV target domain (the mail
                | server hostname). This can be done using a multi-name certificate or
                | by using the client's TLS SNI to select the appropriate certificate.
                | The mail server's TLSA record MUST correspond to this certificate.

                Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01?


                Stefan

                P.S: I feel that we might be stretching what's considered on-topic on
                this mailing list - perhaps we should take this off-list, or to a more
                appropriate (read: DANE related) list?
              • Viktor Dukhovni
                ... I ll take a look at that. It is still a draft, if necessary, we ll work to revise it. ... The latter naturally. My take is that clients using SRV RRs
                Message 7 of 10 , Sep 20, 2013
                • 0 Attachment
                  On Fri, Sep 20, 2013 at 04:39:42PM +0200, Stefan Foerster wrote:

                  > > There is no such need, the draft RFC allows server operators to use
                  > > *either* name (whichever they prefer), and requires clients to support
                  > > both. There is NO requirement for server operators to publish both.
                  >
                  > To be honest, that's not what I read from section 4 of
                  > draft-fanf-dane-mua-00:

                  I'll take a look at that. It is still a draft, if necessary, we'll
                  work to revise it.

                  > | A mail server that is the target of an [RFC6186] SRV record MUST have
                  > | a TLS certificate that authenticates the SRV owner domain (i.e. the
                  > | user's mail domain). This is necessary for clients that cannot
                  > | perform DNSSEC validation. This certificate MUST be the default that
                  > | is presented if the client does not use the TLS Server Name Indication
                  > | extension (TLS SNI) [RFC6066].
                  >
                  > | In order to support this specification, the mail server MUST also have
                  > | a certificate that authenticates the SRV target domain (the mail
                  > | server hostname). This can be done using a multi-name certificate or
                  > | by using the client's TLS SNI to select the appropriate certificate.
                  > | The mail server's TLSA record MUST correspond to this certificate.
                  >
                  > Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01?

                  The latter naturally. My take is that clients using SRV RRs that
                  can't do DNSSEC get no security so there's no point in specifying
                  required certificates for these. Especially with many domains
                  hosted by third parties it is impractical to require pervasive
                  trans-organizational SNI. So the above requirement is a mistake
                  that needs to be corrected.

                  > P.S: I feel that we might be stretching what's considered on-topic on
                  > this mailing list - perhaps we should take this off-list, or to a more
                  > appropriate (read: DANE related) list?

                  If you want to pursue the MUA issues further, or have additional
                  questions/comments about DANE for MTAs, feel free to join the
                  DANE WG mailing list:

                  dane@...

                  Your timing is good, Tony has just returned to the list after a
                  long break, and this is a good opportunity to start resolving
                  any conflicts between his prior work and my more recent drafts.

                  --
                  Viktor.
                Your message has been successfully submitted and would be delivered to recipients shortly.