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

SMTP starttls / DANE TLS

Expand Messages
  • Per Thorsheim
    https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ In WG Last Call Any estimate on when this might become final Viktor? After Google named &
    Message 1 of 6 , Jun 16, 2014
    • 0 Attachment
      https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
      "In WG Last Call"

      Any estimate on when this might become final Viktor?

      After Google named & shamed Comcast for not having starttls, many
      well-known services are now establishing RFC 3207 starttls support.
      Additionally people are becoming aware of establishing DNSSEC support as
      well, which I understand is a prerequisite for the above.

      Regards,
      Per
    • Viktor Dukhovni
      ... With any luck, around July IETF. The WG chairs are trying to coordinate progress on both the SMTP and the SRV drafts. I used the pause in the original
      Message 2 of 6 , Jun 16, 2014
      • 0 Attachment
        On Mon, Jun 16, 2014 at 10:12:03AM +0200, Per Thorsheim wrote:

        > https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
        > "In WG Last Call"
        >
        > Any estimate on when this might become final Viktor?

        With any luck, around July IETF. The WG chairs are trying to
        coordinate progress on both the SMTP and the SRV drafts. I used
        the pause in the original last call to make various improvements.

        --
        Viktor.
      • Per Thorsheim
        ... Sounds good, look forward to see it finalised. Blogged this today: https://starttls.info/blog/from-zero-to-hero-in-no-time/ ACLU, EFF and many others are
        Message 3 of 6 , Jun 17, 2014
        • 0 Attachment
          Den 16.06.2014 17:18, skrev Viktor Dukhovni:
          > On Mon, Jun 16, 2014 at 10:12:03AM +0200, Per Thorsheim wrote:
          >
          >> https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
          >> "In WG Last Call"
          >>
          >> Any estimate on when this might become final Viktor?
          > With any luck, around July IETF. The WG chairs are trying to
          > coordinate progress on both the SMTP and the SRV drafts. I used
          > the pause in the original last call to make various improvements.
          >
          Sounds good, look forward to see it finalised. Blogged this today:
          https://starttls.info/blog/from-zero-to-hero-in-no-time/

          ACLU, EFF and many others are now actively promoting starttls
          deployment, as you may have seen from the past few weeks with lots of
          services announcing support and implementing it quickly. Next step, if
          I'm not completly wrong, is to get TLDs to use DNSSEC if they haven't
          got it already, then deploy it for your own domains, and then hopefully
          your DANE TLS proposal.

          I really hope that will catch on and be deployed faster than we've
          waited for RFC3207.

          Br,
          Per
        • Viktor Dukhovni
          ... Thanks for fighting the good fight. In the mean-time, any chance you could stop fix the misleading TLS support scores starttls.info issues to soundly
          Message 4 of 6 , Jun 17, 2014
          • 0 Attachment
            On Tue, Jun 17, 2014 at 08:39:38PM +0200, Per Thorsheim wrote:

            > Sounds good, look forward to see it finalised. Blogged this today:
            > https://starttls.info/blog/from-zero-to-hero-in-no-time/
            >
            > ACLU, EFF and many others are now actively promoting starttls
            > deployment, as you may have seen from the past few weeks with lots of
            > services announcing support and implementing it quickly. Next step, if
            > I'm not completly wrong, is to get TLDs to use DNSSEC if they haven't
            > got it already, then deploy it for your own domains, and then hopefully
            > your DANE TLS proposal.
            >
            > I really hope that will catch on and be deployed faster than we've
            > waited for RFC3207.

            Thanks for fighting the good fight. In the mean-time, any chance
            you could stop fix the misleading TLS support scores starttls.info
            issues to soundly configured MTAs?

            * For SMTP, self-signed certificates are as good as CA issued
            certificates. The hostname in the certificate is irrelevant.

            * For SMTP servers support for anon-DH cipher-suites is a feature,
            not a bug.

            * For opportunistic TLS, even the weakest ciphers are fine,
            provided strong ones are preferred when offered.

            Almost every score-lowering observation leading to 43.5% D for
            dukhovni.org is wrong.

            --
            Viktor.
          • Per Thorsheim
            ... I talked to Einar today, my friend who made the service on my request. We agreed to simplify the scoring, at first down to passed as long as we see
            Message 5 of 6 , Jun 17, 2014
            • 0 Attachment
              Den 17.06.2014 20:59, skrev Viktor Dukhovni:
              > Thanks for fighting the good fight. In the mean-time, any chance
              > you could stop fix the misleading TLS support scores starttls.info
              > issues to soundly configured MTAs?
              >
              > * For SMTP, self-signed certificates are as good as CA issued
              > certificates. The hostname in the certificate is irrelevant.
              >
              > * For SMTP servers support for anon-DH cipher-suites is a feature,
              > not a bug.
              >
              > * For opportunistic TLS, even the weakest ciphers are fine,
              > provided strong ones are preferred when offered.
              >
              > Almost every score-lowering observation leading to 43.5% D for
              > dukhovni.org is wrong.
              >
              I talked to Einar today, my friend who made the service on my request.
              We agreed to simplify the scoring, at first down to "passed" as long as
              we see starttls support with minimum SSLv3 and no export 40/56bit.

              We'll recommend supporting TLSv1.1/2 and using a cert from a TTP, and
              probably display the preferred cipher suite from the server, if any.
              Will probably not let this affect scoring in any direction, and inform
              about your proposal, and recommend DNSSEC deployment in the meantime.

              Br,
              Per
            • Viktor Dukhovni
              ... That s still too rigid for opportunistic TLS, Postfix servers currently and for the forseeable future explicitly default to support export and low grade
              Message 6 of 6 , Jun 17, 2014
              • 0 Attachment
                On Tue, Jun 17, 2014 at 09:09:31PM +0200, Per Thorsheim wrote:

                > Den 17.06.2014 20:59, skrev Viktor Dukhovni:
                >
                > > Thanks for fighting the good fight. In the mean-time, any chance
                > > you could stop fix the misleading TLS support scores starttls.info
                > > issues to soundly configured MTAs?
                >
                > I talked to Einar today, my friend who made the service on my request.
                > We agreed to simplify the scoring, at first down to "passed" as long as
                > we see starttls support with minimum SSLv3 and no export 40/56bit.

                That's still too rigid for opportunistic TLS, Postfix servers
                currently and for the forseeable future explicitly default to
                support export and low grade ciphers, because again, these are
                strictly better than cleartext. What reason is there to disable
                them?

                Pass, means implements STARTTLS, brownie points for PFS support.
                The rest is at best misleading to down-right counter-productive.

                > We'll recommend supporting TLSv1.1/2 and using a cert from a TTP, and
                > probably display the preferred cipher suite from the server, if any.

                If you want people to throw cash away, just publish appropriate
                charities for people to donate money to. Throwing the money away
                on certificates nobody checks seems silly.

                > Will probably not let this affect scoring in any direction, and inform
                > about your proposal, and recommend DNSSEC deployment in the meantime.

                Please make substantially more radical changes, that take into account
                that opportunistic TLS in SMTP is very different from TLS in HTTPS.

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