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

OT - Dane, TLSA

Expand Messages
  • John Allen
    Does anybody know of a good,but simple write up on DANE and TLSA. It has to be simple enough for me to understand (assume idiot). John A
    Message 1 of 23 , Dec 13, 2013
    • 0 Attachment
      Does anybody know of a good,but simple write up on DANE and TLSA.
      It has to be simple enough for me to understand (assume idiot).

      John A
    • Viktor Dukhovni
      ... An explanation of what DANE TLSA is for[*]? Or how to set up a Postfix to work with it? If the latter, setting up a client to verify DANE TLSA?
      Message 2 of 23 , Dec 13, 2013
      • 0 Attachment
        On Fri, Dec 13, 2013 at 03:11:38PM -0500, John Allen wrote:

        > Does anybody know of a good,but simple write up on DANE and TLSA.
        > It has to be simple enough for me to understand (assume idiot).

        An explanation of what DANE TLSA is for[*]?

        Or how to set up a Postfix to work with it?

        If the latter, setting up a client to verify DANE TLSA?

        http://www.postfix.org/TLS_README.html#client_tls_dane

        Or setting up server to be verifiable with DANE TLSA?

        There is some text on this in TLS_README in the server certificate
        section, but we could perhaps add a DANE_README at some point
        or expand the server text if it is not sufficiently detailed.
        The main difficulty with server-side DANE is that your zone
        must be DNSSEC signed. Deployment of DNSSEC is still fairly thin.
        With a bit of luck DANE might motivate folks to consider DNSSEC.

        --
        Viktor.

        [*]

        DANE TLSA replaces the multitude of trusted SSL certificate
        authorities, that can issue certificates for any dane, with the
        hierarchy of DNSSEC authorities.

        Each domain can sign the keys of its child domains and the data
        records of its own zones including TLSA records which can bind
        service end-points (_25._tcp.mail.example.com) to associated
        certificates, either the leaf certificate:

        _25._tcp.mail.example.com IN TLSA 3 1 1 <sha256 digest of public key>

        or a chosen (public or private) issuing CA:

        _25._tcp.mail.example.com IN TLSA 2 1 1 <sha256 digest of public key>

        In the latter case the server's chain file MUST include the issuing CA.
      • John Allen
        ... My interest in TLSA was sparked by my looking for info when setting up my DNS with DNSSEC (still a work in progress). It seemed to provide a better level
        Message 3 of 23 , Dec 13, 2013
        • 0 Attachment
          On 13/12/2013 3:50 PM, Viktor Dukhovni wrote:
          > On Fri, Dec 13, 2013 at 03:11:38PM -0500, John Allen wrote:
          >
          >> Does anybody know of a good,but simple write up on DANE and TLSA.
          >> It has to be simple enough for me to understand (assume idiot).
          > An explanation of what DANE TLSA is for[*]?
          >
          > Or how to set up a Postfix to work with it?
          >
          > If the latter, setting up a client to verify DANE TLSA?
          >
          > http://www.postfix.org/TLS_README.html#client_tls_dane
          >
          > Or setting up server to be verifiable with DANE TLSA?
          >
          > There is some text on this in TLS_README in the server certificate
          > section, but we could perhaps add a DANE_README at some point
          > or expand the server text if it is not sufficiently detailed.
          > The main difficulty with server-side DANE is that your zone
          > must be DNSSEC signed. Deployment of DNSSEC is still fairly thin.
          > With a bit of luck DANE might motivate folks to consider DNSSEC.
          >
          My interest in TLSA was sparked by my looking for info when setting up
          my DNS with DNSSEC (still a work in progress). It seemed to provide a
          better level of security than the current standard practice. If I have
          understood what I have read TLSA appears to be a mechanism for
          publishing security certs is a secure manner.
          My interest in TLSA lead me to DANE, I am not sure that I fully
          understand DANE or TLSA, however my understanding is, that DANE is a
          high(er) level TLS encryption standard.


          JohnA
        • Viktor Dukhovni
          ... The trick is to find tools that make operating a DNSSEC zone relatively painless. You get security, but it easier to mess up leaving the zone with stale
          Message 4 of 23 , Dec 13, 2013
          • 0 Attachment
            On Sat, Dec 14, 2013 at 12:04:15AM -0500, John Allen wrote:

            > > The main difficulty with server-side DANE is that your zone
            > > must be DNSSEC signed. Deployment of DNSSEC is still fairly thin.
            > > With a bit of luck DANE might motivate folks to consider DNSSEC.
            >
            > My interest in TLSA was sparked by my looking for info when setting
            > up my DNS with DNSSEC (still a work in progress). It seemed to
            > provide a better level of security than the current standard
            > practice.

            The trick is to find tools that make operating a DNSSEC zone
            relatively painless. You get security, but it easier to mess up
            leaving the zone with stale signatures and thus essentially
            invisible to all DNSSEC-aware clients. By all means deploy
            DNSSEC, but carefully.

            > If I have understood what I have read TLSA appears to be a
            > mechanism for publishing security certs is a secure manner.
            > My interest in TLSA lead me to DANE, I am not sure that I fully
            > understand DANE or TLSA, however my understanding is, that DANE is a
            > high(er) level TLS encryption standard.

            You're naturally confused:

            - DNSSEC: a man-in-the-middle hardened means of publishing DNS data.

            - DANE: an IETF working group to develop standards for using DNSSEC
            to publish authentication information (public keys and the like)
            that binds DNS names to corresponding credentials.

            http://datatracker.ietf.org/wg/dane/charter/

            - TLSA: one of the DNS record types developed by the DANE working group
            that publishes TLS server keys in DNS. TLSA records are defined in
            RFC 6698.

            http://tools.ietf.org/html/rfc6698
            http://datatracker.ietf.org/doc/rfc6698/

            So, neither DANE nor TLSA encrypt your data, TLS does that. DANE
            TLSA DNS records can be used to authenticate your server (or for
            you to authenticate other servers). Since the existing public CA
            PKI is largely incompatible with MX record indirection (thus not
            scalably usable for SMTP), I'm attempting to drive DANE adopting
            for SMTP which will scale, provided DNSSEC gets off the ground.

            http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

            Postfix 2.11 will support DANE TLSA. Work is due to begin on similar
            support in Exim based on library code for DANE TLS over OpenSSL that
            grew out of the DANE support in Postfix. I'm hoping to participate
            in making DANE TLSA support generally available in OpenSSL.

            DANE TLSA records allow sites to independently create leaf and CA
            certificates after first registering their DNSSEC key-signing-keys
            with their DNS registrar. So in effect you do have a CA, but it
            is your DNS registrar and they effectively make you a sub-CA for
            your own domain.

            --
            Viktor.
          • John
            ... /*YEP*/, been there, and am doing that. e.g., today for no apparent reason, ( I suspect a roll gone wrong) the KRF on one of my domains is f....). I am
            Message 5 of 23 , Dec 14, 2013
            • 0 Attachment

              On 14/12/2013 12:26 AM, Viktor Dukhovni wrote:
              On Sat, Dec 14, 2013 at 12:04:15AM -0500, John Allen wrote:
              
              
                  The main difficulty with server-side DANE is that your zone
                  must be DNSSEC signed.  Deployment of DNSSEC is still fairly thin.
                  With a bit of luck DANE might motivate folks to consider DNSSEC.
              
              My interest in TLSA was sparked by my looking for info when setting
              up my DNS with DNSSEC (still a work in progress).  It seemed to
              provide a better level of security than the current standard
              practice.
              
              The trick is to find tools that make operating a DNSSEC zone
              relatively painless.  You get security, but it easier to mess up
              leaving the zone with stale signatures and thus essentially
              invisible to all DNSSEC-aware clients.  By all means deploy
              DNSSEC, but carefully.
              YEP, been there, and am doing that. e.g., today for no apparent reason, ( I suspect a roll gone wrong)  the KRF on one of my domains is f....). I am still looking for good tools.
              
              
              If I have understood what I have read TLSA appears to be a
              mechanism for publishing security certs is a secure manner.
              My interest in TLSA lead me to DANE, I am not sure that I fully
              understand DANE or TLSA, however my understanding is, that DANE is a
              high(er) level TLS encryption standard.
              
              You're naturally confused:
              
                  - DNSSEC: a man-in-the-middle hardened means of publishing DNS data.
              
                  - DANE: an IETF working group to develop standards for using DNSSEC
                    to publish authentication information (public keys and the like)
                    that binds DNS names to corresponding credentials.
              
              	http://datatracker.ietf.org/wg/dane/charter/
              
                  - TLSA: one of the DNS record types developed by the DANE working group
                    that publishes TLS server keys in DNS.  TLSA records are defined in
                    RFC 6698.
              
              	  http://tools.ietf.org/html/rfc6698
              	  http://datatracker.ietf.org/doc/rfc6698/
              
              So, neither DANE nor TLSA encrypt your data, TLS does that.  DANE
              TLSA DNS records can be used to authenticate your server (or for
              you to authenticate other servers).  Since the existing public CA
              PKI is largely incompatible with MX record indirection (thus not
              scalably usable for SMTP), I'm attempting to drive DANE adopting
              for SMTP which will scale, provided DNSSEC gets off the ground.
              
              	http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
              
              Postfix 2.11 will support DANE TLSA.  Work is due to begin on similar
              support in Exim based on library code for DANE TLS over OpenSSL that
              grew out of the DANE support in Postfix.  I'm hoping to participate
              in making DANE TLSA support generally available in OpenSSL.
              
              DANE TLSA records allow sites to independently create leaf and CA
              certificates after first registering their DNSSEC key-signing-keys
              with their DNS registrar.  So in effect you do have a CA, but it
              is your DNS registrar and they effectively make you a sub-CA for
              your own domain.
              
              
              Thanks I got some of the above. However I got DANE wrong.

              Does this do anything to solve "Man in the middle" who presents an apparently valid cert (usually generated on the fly)? Because I thought the only way to detect this was to compare the finger print of the key presented with the know finger print.

              Just a thought, maybe there is a more appropriate forum/mail list to discuss this on, as this is not strictly Postfix related?
              JohnA
            • Wietse Venema
              ... With at least one mode of DANE operation, the SMTP server s TLS public-(key or certificate) fingerprint is in the TLSA DNS record. Will that be sufficient
              Message 6 of 23 , Dec 14, 2013
              • 0 Attachment
                John:
                > > - DNSSEC: a man-in-the-middle hardened means of publishing DNS data.
                > >
                > > - DANE: an IETF working group to develop standards for using DNSSEC
                > > to publish authentication information (public keys and the like)
                > > that binds DNS names to corresponding credentials.
                > >
                > > http://datatracker.ietf.org/wg/dane/charter/
                > >
                > > - TLSA: one of the DNS record types developed by the DANE working group
                > > that publishes TLS server keys in DNS. TLSA records are defined in
                > > RFC 6698.
                > >
                > > http://tools.ietf.org/html/rfc6698
                > > http://datatracker.ietf.org/doc/rfc6698/
                > >
                > > So, neither DANE nor TLSA encrypt your data, TLS does that. DANE
                ...
                > Does this do anything to solve "Man in the middle" who presents an
                > apparently valid cert (usually generated on the fly)? Because I thought
                > the only way to detect this was to compare the finger print of the key
                > presented with the know finger print.

                With at least one mode of DANE operation, the SMTP server's TLS
                public-(key or certificate) fingerprint is in the TLSA DNS record.
                Will that be sufficient for your purposes?

                > Just a thought, maybe there is a more appropriate forum/mail list to
                > discuss this on, as this is not strictly Postfix related?

                I suggest reading the IETF mailing list and documents first.
                Hear it from the horse's mouth, as it were.

                Wietse
              • John
                ... YES! ... An excellent idea, particularly as you are talking to the dumbest bit of the horse at the moment. JohnA
                Message 7 of 23 , Dec 14, 2013
                • 0 Attachment
                  On 14/12/2013 8:37 AM, Wietse Venema wrote:
                  > .
                  >> Does this do anything to solve "Man in the middle" who presents an
                  >> apparently valid cert (usually generated on the fly)? Because I thought
                  >> the only way to detect this was to compare the finger print of the key
                  >> presented with the know finger print.
                  > With at least one mode of DANE operation, the SMTP server's TLS
                  > public-(key or certificate) fingerprint is in the TLSA DNS record.
                  > Will that be sufficient for your purposes?
                  YES!
                  >> Just a thought, maybe there is a more appropriate forum/mail list to
                  >> discuss this on, as this is not strictly Postfix related?
                  > I suggest reading the IETF mailing list and documents first.
                  > Hear it from the horse's mouth, as it were.
                  >
                  > Wietse
                  An excellent idea, particularly as you are talking to the dumbest bit of
                  the horse at the moment.

                  JohnA
                • Viktor Dukhovni
                  ... Any authenticated TLS ciphersuite does that. The challenge is always key management. The public certificate authority PKI ( Verisign, Comodo, and the
                  Message 8 of 23 , Dec 14, 2013
                  • 0 Attachment
                    On Sat, Dec 14, 2013 at 08:31:10AM -0500, John wrote:

                    > >DANE TLSA records allow sites to independently create leaf and CA
                    > >certificates after first registering their DNSSEC key-signing-keys
                    > >with their DNS registrar. So in effect you do have a CA, but it
                    > >is your DNS registrar and they effectively make you a sub-CA for
                    > >your own domain.
                    >
                    > Thanks I got some of the above. However I got DANE wrong.
                    >
                    > Does this do anything to solve "Man in the middle" who presents an
                    > apparently valid cert (usually generated on the fly)?

                    Any authenticated TLS ciphersuite does that. The challenge is
                    always key management. The public certificate authority PKI (
                    Verisign, Comodo, and the other couple of hundred CAs in the browser
                    bundles) is somewhat succesful in authenticating HTTPS, and largely
                    inapplicable to SMTP.

                    DANE provides a more scalable key management model. Each domain
                    signs its own server certificates either by directly publishing
                    their public key digests via DNSSEC, or by using its own issuing
                    CA to sign certificates for multiple services, and publishing just
                    the public key digest of the CA. [ See example below my signature. ]

                    > Because I thought the only way to detect this was to compare the
                    > finger print of the key presented with the know finger print.

                    With DANE, the "known finger print" is found in DNSSEC.

                    > Just a thought, maybe there is a more appropriate forum/mail list to
                    > discuss this on, as this is not strictly Postfix related?

                    It is fine to ask here, Postfix is the first real application to
                    support DANE TLSA.

                    --
                    Viktor.

                    Example: debian.org SMTP.

                    - The MX RRset is secure (my validating DNS server set the "ad" bit in
                    the response flags).

                    $ dig +dnssec +noall +comment +ans -t mx debian.org.
                    ;; Got answer:
                    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9595
                    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 19

                    ;; OPT PSEUDOSECTION:
                    ; EDNS: version: 0, flags: do; udp: 4096
                    ;; ANSWER SECTION:
                    debian.org. 60 IN MX 0 mailly.debian.org.
                    debian.org. 60 IN MX 0 muffat.debian.org.
                    debian.org. 60 IN RRSIG MX 7 2 60 20140110192841 20131213192841 17309 debian.org. {base64-encoded signature}

                    - There are secure TLSA RRs for TCP port 25 each of the MX hosts:

                    $ dig +dnssec +noall +comment +ans -t tlsa _25._tcp.mailly.debian.org.
                    ;; Got answer:
                    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58643
                    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11

                    ;; OPT PSEUDOSECTION:
                    ; EDNS: version: 0, flags: do; udp: 4096
                    ;; ANSWER SECTION:
                    _25._tcp.mailly.debian.org. 3600 IN TLSA 3 1 1 709324DC1B427029F8E4D1D9F4159B85567099462CEFA6D5A099B442 2DE4DDA6
                    _25._tcp.mailly.debian.org. 3600 IN RRSIG TLSA 7 5 3600 20140110192841 20131213192841 17309 debian.org. {base64-encoded signature}

                    $ dig +dnssec +noall +comment +ans -t tlsa _25._tcp.muffat.debian.org.
                    ;; Got answer:
                    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59297
                    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11

                    ;; OPT PSEUDOSECTION:
                    ; EDNS: version: 0, flags: do; udp: 4096
                    ;; ANSWER SECTION:
                    _25._tcp.muffat.debian.org. 3600 IN TLSA 3 1 1 CDC19FDEADF1C5566A5DA79BA20EC5522022834FDCECA445889BA1CC 0A78BD35
                    _25._tcp.muffat.debian.org. 3600 IN RRSIG TLSA 7 5 3600 20140110192841
                    20131213192841 17309 debian.org. {base64-encoded signature}

                    - The public-keys of the server cerificates match the TLSA records:

                    $ get311() {
                    (sleep 1; printf "QUIT\r\n" ) |
                    2>/dev/null \
                    openssl s_client -showcerts -starttls smtp -connect "$1:25" |
                    openssl x509 -pubkey -noout |
                    openssl pkey -pubin -outform DER |
                    openssl dgst -sha256 |
                    awk '{print $NF}' |
                    tr '[a-z]' '[A-Z]'
                    }

                    $ dig +short -t mx debian.org |
                    sort -n | while read pref mx; do echo $mx $(get311 $mx); done
                    mailly.debian.org. 709324DC1B427029F8E4D1D9F4159B85567099462CEFA6D5A099B4422DE4DDA6
                    muffat.debian.org. CDC19FDEADF1C5566A5DA79BA20EC5522022834FDCECA445889BA1CC0A78BD35

                    - Therefore debian.org's SMTP servers can be authenticated via their DNSSEC
                    TLSA records. And so man in the middle attacks on email to
                    debian.org from DANE TLSA enabled SMTP clients (e.g. Postfix 2.11
                    configured to use DNSSEC and DANE) require the attacker to
                    brute-force crypt-analyze TLS cryptography, or have access to either the
                    server's private keys, or the DNSSEC private keys of "debian.org",
                    "org" or the root zone.
                  • John Allen
                    ... Thanks for the example I will run it against my own domains. That and head over to the sites suggested by Wietse Venema. JohnA
                    Message 9 of 23 , Dec 14, 2013
                    • 0 Attachment
                      > On Sat, Dec 14, 2013 at 08:31:10AM -0500, John wrote:
                      >
                      >>> DANE TLSA records allow sites to independently create leaf and CA
                      >>> certificates after first registering their DNSSEC key-signing-keys
                      >>> with their DNS registrar. So in effect you do have a CA, but it
                      >>> is your DNS registrar and they effectively make you a sub-CA for
                      >>> your own domain.
                      >> Thanks I got some of the above. However I got DANE wrong.
                      >>
                      >> Does this do anything to solve "Man in the middle" who presents an
                      >> apparently valid cert (usually generated on the fly)?
                      > Any authenticated TLS ciphersuite does that. The challenge is
                      > always key management. The public certificate authority PKI (
                      > Verisign, Comodo, and the other couple of hundred CAs in the browser
                      > bundles) is somewhat succesful in authenticating HTTPS, and largely
                      > inapplicable to SMTP.
                      >
                      > DANE provides a more scalable key management model. Each domain
                      > signs its own server certificates either by directly publishing
                      > their public key digests via DNSSEC, or by using its own issuing
                      > CA to sign certificates for multiple services, and publishing just
                      > the public key digest of the CA. [ See example below my signature. ]
                      >
                      >> Because I thought the only way to detect this was to compare the
                      >> finger print of the key presented with the know finger print.
                      > With DANE, the "known finger print" is found in DNSSEC.
                      >
                      >> Just a thought, maybe there is a more appropriate forum/mail list to
                      >> discuss this on, as this is not strictly Postfix related?
                      > It is fine to ask here, Postfix is the first real application to
                      > support DANE TLSA.
                      >
                      Thanks for the example I will run it against my own domains. That and
                      head over to the sites suggested by Wietse Venema.

                      JohnA
                    • Viktor Dukhovni
                      ... Well, you re unlikely to have working TLSA RRs for your SMTP service just by happenstance. If you want to create a TLSA RRset for your SMTP server, run
                      Message 10 of 23 , Dec 14, 2013
                      • 0 Attachment
                        On Sat, Dec 14, 2013 at 12:44:49PM -0500, John Allen wrote:

                        > >>Just a thought, maybe there is a more appropriate forum/mail list to
                        > >>discuss this on, as this is not strictly Postfix related?
                        > >
                        > >It is fine to ask here, Postfix is the first real application to
                        > >support DANE TLSA.
                        >
                        > Thanks for the example I will run it against my own domains. That
                        > and head over to the sites suggested by Wietse Venema.

                        Well, you're unlikely to have working TLSA RRs for your SMTP service
                        just by happenstance. If you want to create a TLSA RRset for your
                        SMTP server, run the attached "tlsagen" shell script as follows:

                        $ tlsagen cert.pem $(uname -n) DANE-EE PKEY SHA2-256
                        _25._tcp.mail.example.com IN TLSA 3 1 1 {hex string}

                        where "cert.pem" is the file with your Postfix SMTP server certificate,
                        and $(uname -n) is presumably the fully-qualified domain name of
                        the server as an MX host for your domain (otherwise use the actual name).

                        The shell script expects OpenSSL 1.0.0 or later, and will not work
                        with earlier versions.

                        Then add the generated RR to your DNS zone file. When rotating
                        keys (replacing your private key and cert) publish both the new
                        and old TLSA records in DNS well before deploying the new key
                        (allowing the old key to expire from client caches), then deploy
                        the new key/cert on the server. Once the server is using the new
                        key, you can update the DNS again to remove the old key from the
                        TLSA RRset.

                        The "posttls-finger" utility included with Postfix 2.11 snapshot
                        source code can verify DANE SMTP support for your domain:

                        $ posttls-finger your-domain.example

                        If your domain is "klam.ca", then it is not currently verifiable
                        via DNSSEC because there are no associated DS or DNSKEY RRs in the
                        "ca." parent zone. You'd have to get that taken care of via your
                        registrar before you expend further effort on DANE. Of course you
                        need to be sure that your zone signing automation is all in order
                        first.

                        --
                        Viktor.
                      • /dev/rob0
                        ... Perhaps I am biased, but I use and recommend ISC BIND 9.9. The auto-dnssec maintain; zone option does most of the work. Used together with update-policy
                        Message 11 of 23 , Dec 14, 2013
                        • 0 Attachment
                          On Sat, Dec 14, 2013 at 05:26:01AM +0000, Viktor Dukhovni wrote:
                          > On Sat, Dec 14, 2013 at 12:04:15AM -0500, John Allen wrote:
                          > > > The main difficulty with server-side DANE is that your zone
                          > > > must be DNSSEC signed. Deployment of DNSSEC is still fairly
                          > > > thin. With a bit of luck DANE might motivate folks to consider
                          > > > DNSSEC.
                          > >
                          > > My interest in TLSA was sparked by my looking for info when
                          > > setting up my DNS with DNSSEC (still a work in progress). It
                          > > seemed to provide a better level of security than the current
                          > > standard practice.
                          >
                          > The trick is to find tools that make operating a DNSSEC zone
                          > relatively painless. You get security, but it easier to mess
                          > up leaving the zone with stale signatures and thus essentially
                          > invisible to all DNSSEC-aware clients. By all means deploy
                          > DNSSEC, but carefully.

                          Perhaps I am biased, but I use and recommend ISC BIND 9.9. The
                          "auto-dnssec maintain;" zone option does most of the work. Used
                          together with "update-policy local;" you get a simple means of
                          updating your zone data with nsupdate(8).

                          Another choice with 9.9 is inline signing, whereby zone files are
                          maintained as before, and the signing takes place "inline". These
                          features and others are all documented in the BIND 9 ARM:

                          ftp://ftp.isc.org/isc/bind9/9.9.4-P1/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones

                          Each of BIND 9.7, 9.8, and 9.9 had new features which slightly
                          reduced the pain of DNSSEC. 9.10 won't be an exception.
                          --
                          http://rob0.nodns4.us/
                          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                        • Viktor Dukhovni
                          ... Thanks for the tip, the OP may find that helpful. Making use of DNSSEC as transparent as possible to the administrator is key to making it usable. Since
                          Message 12 of 23 , Dec 14, 2013
                          • 0 Attachment
                            On Sat, Dec 14, 2013 at 02:35:15PM -0600, /dev/rob0 wrote:

                            > > The trick is to find tools that make operating a DNSSEC zone
                            > > relatively painless. You get security, but it easier to mess
                            > > up leaving the zone with stale signatures and thus essentially
                            > > invisible to all DNSSEC-aware clients. By all means deploy
                            > > DNSSEC, but carefully.
                            >
                            > Perhaps I am biased, but I use and recommend ISC BIND 9.9. The
                            > "auto-dnssec maintain;" zone option does most of the work. Used
                            > together with "update-policy local;" you get a simple means of
                            > updating your zone data with nsupdate(8).

                            Thanks for the tip, the OP may find that helpful. Making use of
                            DNSSEC as transparent as possible to the administrator is key to
                            making it usable.

                            Since your zone is in fact DNSSEC signed, perhaps you should consider
                            enabling DANE for SMTP:

                            _25._tcp.mx3.nodns4.us. IN TLSA 3 1 1 FDC86639033F23BAB5B24DF459DE2742CF98FCB1BD747F71807C4DF294773323
                            _25._tcp.mx4.nodns4.us. IN TLSA 3 1 1 FDC86639033F23BAB5B24DF459DE2742CF98FCB1BD747F71807C4DF294773323

                            --
                            Viktor.
                          • John
                            ... Yes, unfortunately my .ca Registrar is not currently capable of handling DS or DNSKEY records so I am using the ISC dlv, It works for most things, but I
                            Message 13 of 23 , Dec 14, 2013
                            • 0 Attachment
                              On 14/12/2013 1:30 PM, Viktor Dukhovni wrote:
                              > On Sat, Dec 14, 2013 at 12:44:49PM -0500, John Allen wrote:
                              >
                              >>>> Just a thought, maybe there is a more appropriate forum/mail list to
                              >>>> discuss this on, as this is not strictly Postfix related?
                              >>> It is fine to ask here, Postfix is the first real application to
                              >>> support DANE TLSA.
                              >> Thanks for the example I will run it against my own domains. That
                              >> and head over to the sites suggested by Wietse Venema.
                              > Well, you're unlikely to have working TLSA RRs for your SMTP service
                              > just by happenstance. If you want to create a TLSA RRset for your
                              > SMTP server, run the attached "tlsagen" shell script as follows:
                              >
                              > $ tlsagen cert.pem $(uname -n) DANE-EE PKEY SHA2-256
                              > _25._tcp.mail.example.com IN TLSA 3 1 1 {hex string}
                              >
                              > where "cert.pem" is the file with your Postfix SMTP server certificate,
                              > and $(uname -n) is presumably the fully-qualified domain name of
                              > the server as an MX host for your domain (otherwise use the actual name).
                              >
                              > The shell script expects OpenSSL 1.0.0 or later, and will not work
                              > with earlier versions.
                              >
                              > Then add the generated RR to your DNS zone file. When rotating
                              > keys (replacing your private key and cert) publish both the new
                              > and old TLSA records in DNS well before deploying the new key
                              > (allowing the old key to expire from client caches), then deploy
                              > the new key/cert on the server. Once the server is using the new
                              > key, you can update the DNS again to remove the old key from the
                              > TLSA RRset.
                              >
                              > The "posttls-finger" utility included with Postfix 2.11 snapshot
                              > source code can verify DANE SMTP support for your domain:
                              >
                              > $ posttls-finger your-domain.example
                              >
                              > If your domain is "klam.ca", then it is not currently verifiable
                              > via DNSSEC because there are no associated DS or DNSKEY RRs in the
                              > "ca." parent zone. You'd have to get that taken care of via your
                              > registrar before you expend further effort on DANE. Of course you
                              > need to be sure that your zone signing automation is all in order
                              > first.
                              >
                              Yes, unfortunately my .ca Registrar is not currently capable of handling
                              DS or DNSKEY records so I am using the ISC dlv, It works for most
                              things, but I assume from your comment that TLSA will require records at
                              the .ca root. I have the same problem with the other two domains where
                              Tucows is the registrar.

                              Ha well, we wouldn't be in this business if it were easy.

                              JohnA
                            • Viktor Dukhovni
                              ... No, in fact there is no special magic for TLSA RRs as opposed to other DNSSEC records. They are protected or not protected by DNSSEC in the same way as
                              Message 14 of 23 , Dec 14, 2013
                              • 0 Attachment
                                On Sat, Dec 14, 2013 at 04:16:08PM -0500, John wrote:

                                > Yes, unfortunately my .ca Registrar is not currently capable of
                                > handling DS or DNSKEY records so I am using the ISC dlv, It works
                                > for most things, but I assume from your comment that TLSA will
                                > require records at the .ca root. I have the same problem with the
                                > other two domains where Tucows is the registrar.

                                No, in fact there is no special magic for TLSA RRs as opposed to
                                other DNSSEC records. They are protected or not protected by DNSSEC
                                in the same way as all other records. Rather, OpenWRT on my home
                                router is not configured to use ISC's DLV. If some verifier is
                                configured to consult the ISC DLV, they may well find your TLSA
                                RRset to be secure and thus usable.

                                For what it is worth, as another data-point, the Google 8.8.8.8
                                recursive DNS servers also don't report "klam.ca" as being signed.

                                --
                                Viktor.
                              • Benny Pedersen
                                ... if its dumbest its a donkey, not a horse :)
                                Message 15 of 23 , Dec 14, 2013
                                • 0 Attachment
                                  John skrev den 2013-12-14 15:24:

                                  > An excellent idea, particularly as you are talking to the dumbest bit
                                  > of the horse at the moment.

                                  if its dumbest its a donkey, not a horse :)
                                • /dev/rob0
                                  ... I was planning to do DANE this summer when the feature was implemented, but at the time my mail host had a too-old openssl. I think we re good now: $
                                  Message 16 of 23 , Dec 17, 2013
                                  • 0 Attachment
                                    On Sat, Dec 14, 2013 at 08:53:14PM +0000, Viktor Dukhovni wrote:
                                    > On Sat, Dec 14, 2013 at 02:35:15PM -0600, /dev/rob0 wrote:
                                    >
                                    > > > The trick is to find tools that make operating a DNSSEC zone
                                    > > > relatively painless. You get security, but it easier to mess
                                    > > > up leaving the zone with stale signatures and thus essentially
                                    > > > invisible to all DNSSEC-aware clients. By all means deploy
                                    > > > DNSSEC, but carefully.
                                    > >
                                    > > Perhaps I am biased, but I use and recommend ISC BIND 9.9. The
                                    > > "auto-dnssec maintain;" zone option does most of the work. Used
                                    > > together with "update-policy local;" you get a simple means of
                                    > > updating your zone data with nsupdate(8).
                                    >
                                    > Thanks for the tip, the OP may find that helpful. Making use of
                                    > DNSSEC as transparent as possible to the administrator is key to
                                    > making it usable.
                                    >
                                    > Since your zone is in fact DNSSEC signed, perhaps you should
                                    > consider enabling DANE for SMTP:

                                    I was planning to do DANE this summer when the feature was
                                    implemented, but at the time my mail host had a too-old openssl. I
                                    think we're good now:

                                    $ openssl version
                                    OpenSSL 1.0.1e 11 Feb 2013

                                    > _25._tcp.mx3.nodns4.us. IN TLSA 3 1 1 FDC86639033F23BAB5B24DF459DE2742CF98FCB1BD747F71807C4DF294773323
                                    > _25._tcp.mx4.nodns4.us. IN TLSA 3 1 1 FDC86639033F23BAB5B24DF459DE2742CF98FCB1BD747F71807C4DF294773323

                                    Hehe, oops. This exposes my postscreen MX policy test ruse (same
                                    certificate on both IP addresses.) (Yeah, I know, it doesn't matter;
                                    spammers are not going to check my TLSA records.)

                                    Thanks for the reminder and help. I will do it this weekend.
                                    --
                                    http://rob0.nodns4.us/
                                    Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                                  • Eray Aslan
                                    ... +++ tlsagen 2014-04-25 13:50:17.000000000 +0000 @@ -20,7 +23,7 @@ $/=undef; ($a= ) =~ s/(.)/sprintf( %02X , ord($1))/egs; printf _%d._tcp.%s. IN
                                    Message 17 of 23 , Apr 25, 2014
                                    • 0 Attachment
                                      On Sat, Dec 14, 2013 at 06:30:15PM +0000, Viktor Dukhovni wrote:
                                      > Well, you're unlikely to have working TLSA RRs for your SMTP service
                                      > just by happenstance. If you want to create a TLSA RRset for your
                                      > SMTP server, run the attached "tlsagen" shell script as follows:
                                      >
                                      > $ tlsagen cert.pem $(uname -n) DANE-EE PKEY SHA2-256
                                      > _25._tcp.mail.example.com IN TLSA 3 1 1 {hex string}

                                      For the record, looks like a typo in the script:

                                      --- tlsagen 2014-04-25 14:22:02.000000000 +0000
                                      +++ tlsagen 2014-04-25 13:50:17.000000000 +0000
                                      @@ -20,7 +23,7 @@
                                      $/=undef;
                                      ($a=<STDIN>) =~ s/(.)/sprintf("%02X", ord($1))/egs;
                                      printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n",
                                      - $port, $host, $usage, $s, $m, $a;
                                      + $port, $host, $u, $s, $m, $a;
                                      ' "$@"
                                      }

                                      --
                                      Eray
                                    • Viktor Dukhovni
                                      ... Thanks, yes, this has since been fixed, and a few other improvements made. Current version attached. Requires bash(1) rather than a generic POSIX
                                      Message 18 of 23 , Apr 25, 2014
                                      • 0 Attachment
                                        On Fri, Apr 25, 2014 at 02:35:55PM +0000, Eray Aslan wrote:

                                        > For the record, looks like a typo in the script:
                                        >
                                        > --- tlsagen 2014-04-25 14:22:02.000000000 +0000
                                        > +++ tlsagen 2014-04-25 13:50:17.000000000 +0000

                                        Thanks, yes, this has since been fixed, and a few other improvements
                                        made. Current version attached. Requires bash(1) rather than a
                                        generic POSIX /bin/sh, for error detection in all stages of a
                                        multi-stage command pipe.

                                        --
                                        Viktor.
                                      • Viktor Dukhovni
                                        ... Oh, and by the way, I see your domain has working TLSA RRs. I now know of 18 domains with working TLSA records for their MX hosts (but two of them are
                                        Message 19 of 23 , Apr 25, 2014
                                        • 0 Attachment
                                          On Fri, Apr 25, 2014 at 02:35:55PM +0000, Eray Aslan wrote:

                                          > > $ tlsagen cert.pem $(uname -n) DANE-EE PKEY SHA2-256
                                          > > _25._tcp.mail.example.com IN TLSA 3 1 1 {hex string}
                                          >
                                          > For the record, looks like a typo in the script:

                                          Oh, and by the way, I see your domain has working TLSA RRs. I now
                                          know of 18 domains with working TLSA records for their MX hosts
                                          (but two of them are mine). That list is a bit short. :-( I'm
                                          helping the ietf.org administrator to implement STARTTLS and TLSA
                                          records, so that'll be 19 soon.

                                          If anyone else on this list has a DNSSEC signed domain and adds MX
                                          host TLSA records, please feel free to drop me a note. I'll connect
                                          to your domain from my home network a few times a year to test DANE
                                          interoperability, you will not be exposed to any noticeable load,
                                          nor any unwanted email messages, the connection will just complete
                                          a TLS handshake, send "QUIT" and disconnect. (A test with
                                          posttls-finger).

                                          --
                                          Viktor.
                                        • Eray Aslan
                                          ... [...] ... Feel free to (ab)use it and to ask for different configs/MTAs etc if necessary. -- Eray
                                          Message 20 of 23 , Apr 25, 2014
                                          • 0 Attachment
                                            On Fri, Apr 25, 2014 at 03:00:42PM +0000, Viktor Dukhovni wrote:
                                            > Oh, and by the way, I see your domain has working TLSA RRs.
                                            [...]
                                            > If anyone else on this list has a DNSSEC signed domain and adds MX
                                            > host TLSA records, please feel free to drop me a note. I'll connect
                                            > to your domain from my home network a few times a year to test DANE

                                            Feel free to (ab)use it and to ask for different configs/MTAs etc if
                                            necessary.

                                            --
                                            Eray
                                          • Tom Hendrikx
                                            ... Hash: SHA256 ... Count me in. Your post was a trigger for me: wanted to try this for some time, but never got to it. It was actually dead easy ;) I read
                                            Message 21 of 23 , Apr 25, 2014
                                            • 0 Attachment
                                              -----BEGIN PGP SIGNED MESSAGE-----
                                              Hash: SHA256

                                              On 25-04-14 17:00, Viktor Dukhovni wrote:
                                              > On Fri, Apr 25, 2014 at 02:35:55PM +0000, Eray Aslan wrote:
                                              >
                                              >>> $ tlsagen cert.pem $(uname -n) DANE-EE PKEY SHA2-256
                                              >>> _25._tcp.mail.example.com IN TLSA 3 1 1 {hex string}
                                              >>
                                              >> For the record, looks like a typo in the script:
                                              >
                                              > Oh, and by the way, I see your domain has working TLSA RRs. I now
                                              > know of 18 domains with working TLSA records for their MX hosts
                                              > (but two of them are mine). That list is a bit short. :-( I'm
                                              > helping the ietf.org administrator to implement STARTTLS and TLSA
                                              > records, so that'll be 19 soon.
                                              >
                                              > If anyone else on this list has a DNSSEC signed domain and adds MX
                                              > host TLSA records, please feel free to drop me a note. I'll
                                              > connect to your domain from my home network a few times a year to
                                              > test DANE interoperability, you will not be exposed to any
                                              > noticeable load, nor any unwanted email messages, the connection
                                              > will just complete a TLS handshake, send "QUIT" and disconnect.
                                              > (A test with posttls-finger).
                                              >

                                              Count me in. Your post was a trigger for me: wanted to try this for
                                              some time, but never got to it. It was actually dead easy ;)

                                              I read http://blog.huque.com/2012/10/dnssec-and-certificates.html and
                                              ended up using hash-slinger which is available in latest ubuntu
                                              release, just like posttls-finger.

                                              Tom
                                              -----BEGIN PGP SIGNATURE-----
                                              Version: GnuPG v1
                                              Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

                                              iQIcBAEBCAAGBQJTWquLAAoJEJPfMZ19VO/1cD0QAIHWUKJd3p0whYnMllAGugxv
                                              NiuiNB+tg3WrvP25mkfufeZFYCTBT7Uo4PMAnlGB7MCOVDBzM4Qj/bm5YCMpf0wN
                                              ueCdZmVsiJb8Io8WiJuGzxTPPF9IgJ6Z5caH9lMEHrpKh46q3EaBtfbNA6SGhUaE
                                              L0Jcjv+UqSdYmkcFWbiPDLIysWuozliutw/gRJvHoHkPCFb+TTvFN6ACym+CZl6r
                                              R8GbPbBjc+Y82xgFSTYzCLa2LbC+0F9/IFRnDwZjbpV0xju+91emYOe0lmXDG9iU
                                              b+OMo4REp9qD7UaIHdxjZHMKYbhBkgIAchHb/RwJBFvSjAmhLpWtPpfS0eZliyBa
                                              Y+a0Gr7dcJw8H8M6I8ge5HWzzDDKP4rJ43mMFX3AxR17oPB5zVc+Ox84bxVDUCBP
                                              cwvSkYPCVlZMWZHnbA51WmqX0igKrH5l8wNUEIMyyb0oakHFMM2ugVMkJS3EHKHL
                                              zKnIw/AHSXRSgCF/1huyl0OA7GpYL0kmAAf+BnhJjVs02D4xt7JDg8sr/mQ6pO0y
                                              3lregDHgELhllhzXpnpDtFZ6zwobqeMbgQtEGe8aYN/4Yw1bvimpxwBqfyZXMGmi
                                              GJngcB0taarwUHNRq9IHoccEGJyx/pAzpTMnmMNELdws8hW1ciestUnpsWPjyT/n
                                              Tn5vftD7ghdnxhRLz/o/
                                              =rPRj
                                              -----END PGP SIGNATURE-----
                                            • Jonas Wielicki
                                              ... sotecware.net and wielicki.name are both handled by my mailhost and should have TLSA records. I just realized that wielicki.name had an invalid MX record,
                                              Message 22 of 23 , Apr 26, 2014
                                              • 0 Attachment
                                                On 25.04.2014 17:00, Viktor Dukhovni wrote:
                                                > If anyone else on this list has a DNSSEC signed domain and adds MX
                                                > host TLSA records, please feel free to drop me a note. I'll connect
                                                > to your domain from my home network a few times a year to test DANE
                                                > interoperability, you will not be exposed to any noticeable load,
                                                > nor any unwanted email messages, the connection will just complete
                                                > a TLS handshake, send "QUIT" and disconnect. (A test with
                                                > posttls-finger).

                                                sotecware.net and wielicki.name are both handled by my mailhost and
                                                should have TLSA records.

                                                I just realized that wielicki.name had an invalid MX record, but I just
                                                fixed that, it should be propagated in the next 30 minutes.

                                                I wonder whether a service like https://xmpp.net would be valuable for
                                                the SMTP network too. For those who don’t know it, it provides general
                                                security parameter checking on XMPP hosts, including certificate, cipher
                                                and DNSSEC checks (example report[1]).

                                                regards,
                                                Jonas

                                                [1]: https://xmpp.net/result.php?domain=sotecware.net&type=client
                                              • /dev/rob0
                                                ... You helped me with that in this very thread back in December. :) Those records are in place now for nodns4.us. -- http://rob0.nodns4.us/ Offlist GMX mail
                                                Message 23 of 23 , Apr 26, 2014
                                                • 0 Attachment
                                                  On Fri, Apr 25, 2014 at 03:00:42PM +0000, Viktor Dukhovni wrote:
                                                  > If anyone else on this list has a DNSSEC signed domain and adds
                                                  > MX host TLSA records, please feel free to drop me a note.

                                                  You helped me with that in this very thread back in December. :)
                                                  Those records are in place now for nodns4.us.
                                                  --
                                                  http://rob0.nodns4.us/
                                                  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                                                Your message has been successfully submitted and would be delivered to recipients shortly.