Some news on SMTP DANE TLS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Some news on SMTP DANE TLS

Viktor Dukhovni
Today, Microsoft announced plans to implement SMTP DANE TLS in Office365
"Exchange Online":

    https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494

this is not live yet, the implementation will be in two stages:

    The first phase will include only outbound support (mail sent outbound
    from Exchange Online) and we aim to enable this by the end of the
    calendar year 2020.

    The second phase will add inbound support for Exchange Online and we
    plan to enable that by the end of 2021. For both of those phases,
    corresponding TLS-RPT support will be provided.  

The relevance of this to the Postfix community is:

    - If you are already publishing DANE TLSA records for your MX hosts,
      now is a good time to make sure that these are not neglected or
      managed poorly.  Please read:

       https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
       https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
       https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
       https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
       https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

      in particular, make sure that your TLSA RRset is *monitored* and
      any dicrepancies betweent the DNS and your live certificate chain
      are brought to your attention for remediation in a timely manner.

      With monitoring under control, make sure that your certificate
      rollover practices are robust enough to avoid even transient
      problems as a result of changing the cert/key *before* the
      corresponding *new* TLSA RRs are published (along with records
      matching the *current* chain).

      Also, just in case, locating a working technical contact for your
      domain should not require crystal ball gazing, or some form of
      voodoo.  Please consider publishing an RFC8640 TLS-RPT address,
      and an working contact address in your SOA record.  If all else
      fails, have a working postmaster mailbox that is actually read.

    - If you don't already publish TLSA records, that's fine, and I
      don't encourage doing it "as a fashion statement".  Don't do it
      unless you take the time to do it well (see above).  That said,
      please consider adopting DNSSEC and DANE.

      Considerable work has gone into BIND 9.16 to make key management
      easier, with BIND now able to not only automatically resign your
      zone, but also do automated rollover of signing keys.  This may
      be a good time to dip your toes in the water, and learn how to
      deploy DNSSEC.

      As always, monitor what you deploy, unmonitored infrastructure
      should be an oxymoron.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Some news on SMTP DANE TLS

Wietse Venema
Viktor Dukhovni:
> Today, Microsoft announced plans to implement SMTP DANE TLS in Office365
> "Exchange Online":
>
>     https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494
>
> this is not live yet, the implementation will be in two stages:

Nevertheless, big news! Congratulations and thanks for pushing.

        Wietse

>     The first phase will include only outbound support (mail sent outbound
>     from Exchange Online) and we aim to enable this by the end of the
>     calendar year 2020.
>
>     The second phase will add inbound support for Exchange Online and we
>     plan to enable that by the end of 2021. For both of those phases,
>     corresponding TLS-RPT support will be provided.  
>
> The relevance of this to the Postfix community is:
>
>     - If you are already publishing DANE TLSA records for your MX hosts,
>       now is a good time to make sure that these are not neglected or
>       managed poorly.  Please read:
>
>        https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
>        https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
>        https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
>        https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
>        https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
>
>       in particular, make sure that your TLSA RRset is *monitored* and
>       any dicrepancies betweent the DNS and your live certificate chain
>       are brought to your attention for remediation in a timely manner.
>
>       With monitoring under control, make sure that your certificate
>       rollover practices are robust enough to avoid even transient
>       problems as a result of changing the cert/key *before* the
>       corresponding *new* TLSA RRs are published (along with records
>       matching the *current* chain).
>
>       Also, just in case, locating a working technical contact for your
>       domain should not require crystal ball gazing, or some form of
>       voodoo.  Please consider publishing an RFC8640 TLS-RPT address,
>       and an working contact address in your SOA record.  If all else
>       fails, have a working postmaster mailbox that is actually read.
>
>     - If you don't already publish TLSA records, that's fine, and I
>       don't encourage doing it "as a fashion statement".  Don't do it
>       unless you take the time to do it well (see above).  That said,
>       please consider adopting DNSSEC and DANE.
>
>       Considerable work has gone into BIND 9.16 to make key management
>       easier, with BIND now able to not only automatically resign your
>       zone, but also do automated rollover of signing keys.  This may
>       be a good time to dip your toes in the water, and learn how to
>       deploy DNSSEC.
>
>       As always, monitor what you deploy, unmonitored infrastructure
>       should be an oxymoron.
>
> --
>     Viktor.
>