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

Individual smtpd_tls_ask_ccert?

Expand Messages
  • Patrick Ben Koetter
    IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs, because there are enough MTAs out there unable to handle client certificate
    Message 1 of 25 , Jul 29 5:54 AM
      IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
      because there are enough MTAs out there unable to handle client certificate
      requests from a server they connect to.

      It that is true, would it be possible to make smtpd_tls_ask_ccert client
      dependent e.g. request a ccert when the client sends e.g. a specific HELO
      hostname?

      mail.example.com ask_ccert
      .example.net ask_ccert

      p@rick

      --
      [*] sys4 AG

      https://sys4.de, +49 (89) 30 90 46 64
      Franziskanerstraße 15, 81669 München

      Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
      Vorstand: Patrick Ben Koetter, Marc Schiffbauer
      Aufsichtsratsvorsitzender: Florian Kirstein
    • Viktor Dukhovni
      ... Obviously this would be a new feature. With the existing Postfix you can run an SMTP service that requests client certificates on a different IP address
      Message 2 of 25 , Jul 29 6:05 AM
        On Tue, Jul 29, 2014 at 02:54:29PM +0200, Patrick Ben Koetter wrote:

        > IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
        > because there are enough MTAs out there unable to handle client certificate
        > requests from a server they connect to.
        >
        > It that is true, would it be possible to make smtpd_tls_ask_ccert client
        > dependent e.g. request a ccert when the client sends e.g. a specific HELO
        > hostname?
        >
        > mail.example.com ask_ccert
        > .example.net ask_ccert

        Obviously this would be a new feature. With the existing Postfix
        you can run an SMTP service that requests client certificates on
        a different IP address or port, provided the clients in question
        are willing to configure a manual transport entry for your domain.

        As for the new feature, it is possible in principle. How important
        is this? What value do you expect to get from said client
        certificates?

        --
        Viktor.
      • Patrick Ben Koetter
        ... I would want to identify clients by their certificate fingerprint. Either in a policy service or in a Postfix map. I am thinking smtpd_tls_policy_maps. ...
        Message 3 of 25 , Jul 29 6:08 AM
          * Viktor Dukhovni <postfix-users@...>:
          > On Tue, Jul 29, 2014 at 02:54:29PM +0200, Patrick Ben Koetter wrote:
          >
          > > IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
          > > because there are enough MTAs out there unable to handle client certificate
          > > requests from a server they connect to.
          > >
          > > It that is true, would it be possible to make smtpd_tls_ask_ccert client
          > > dependent e.g. request a ccert when the client sends e.g. a specific HELO
          > > hostname?
          > >
          > > mail.example.com ask_ccert
          > > .example.net ask_ccert
          >
          > Obviously this would be a new feature. With the existing Postfix
          > you can run an SMTP service that requests client certificates on
          > a different IP address or port, provided the clients in question
          > are willing to configure a manual transport entry for your domain.
          >
          > As for the new feature, it is possible in principle. How important
          > is this? What value do you expect to get from said client
          > certificates?

          I would want to identify clients by their certificate fingerprint. Either in a
          policy service or in a Postfix map. I am thinking smtpd_tls_policy_maps.



          >
          > --
          > Viktor.

          --
          [*] sys4 AG

          https://sys4.de, +49 (89) 30 90 46 64
          Franziskanerstraße 15, 81669 München

          Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
          Vorstand: Patrick Ben Koetter, Marc Schiffbauer
          Aufsichtsratsvorsitzender: Florian Kirstein
        • Wietse Venema
          ... Is this still true? Assuming that you are referring to MTA-MTA communication, not end-user MUAs (such as old Netscape clients that should have fallen to
          Message 4 of 25 , Jul 29 6:13 AM
            Patrick Ben Koetter:
            > IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
            > because there are enough MTAs out there unable to handle client certificate
            > requests from a server they connect to.

            Is this still true? Assuming that you are referring to MTA-MTA
            communication, not end-user MUAs (such as old Netscape clients that
            should have fallen to dust by now).

            > It that is true, would it be possible to make smtpd_tls_ask_ccert client
            > dependent e.g. request a ccert when the client sends e.g. a specific HELO
            > hostname?
            >
            > mail.example.com ask_ccert
            > .example.net ask_ccert

            Alternatively, allow a richer input to smtpd_tls_ask_ccert besides
            yes and no. For example, a (match)list.

            Wietse
          • Patrick Ben Koetter
            ... Actually I don t know if it is still true. If not we could ignore the individualization and - ideally - move to to add smtpd_tls_ccert_policy_maps. ...
            Message 5 of 25 , Jul 29 6:17 AM
              * Wietse Venema <wietse@...>:
              > Patrick Ben Koetter:
              > > IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
              > > because there are enough MTAs out there unable to handle client certificate
              > > requests from a server they connect to.
              >
              > Is this still true? Assuming that you are referring to MTA-MTA
              > communication, not end-user MUAs (such as old Netscape clients that
              > should have fallen to dust by now).

              Actually I don't know if it is still true. If not we could ignore the
              individualization and - ideally - move to to add smtpd_tls_ccert_policy_maps.


              > > It that is true, would it be possible to make smtpd_tls_ask_ccert client
              > > dependent e.g. request a ccert when the client sends e.g. a specific HELO
              > > hostname?
              > >
              > > mail.example.com ask_ccert
              > > .example.net ask_ccert
              >
              > Alternatively, allow a richer input to smtpd_tls_ask_ccert besides
              > yes and no. For example, a (match)list.

              Yes. Finer control e.g. access(5) actions would be my ultimate wish.

              p@rick

              --
              [*] sys4 AG

              https://sys4.de, +49 (89) 30 90 46 64
              Franziskanerstraße 15, 81669 München

              Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
              Vorstand: Patrick Ben Koetter, Marc Schiffbauer
              Aufsichtsratsvorsitzender: Florian Kirstein
            • Wietse Venema
              ... access(5) restrictions are evaluated by default at RCPT TO time. You need a decision that is made before or at STARTTLS time. Wietse
              Message 6 of 25 , Jul 29 6:25 AM
                Patrick Ben Koetter:
                > > > mail.example.com ask_ccert
                > > > .example.net ask_ccert
                > >
                > > Alternatively, allow a richer input to smtpd_tls_ask_ccert besides
                > > yes and no. For example, a (match)list.
                >
                > Yes. Finer control e.g. access(5) actions would be my ultimate wish.

                access(5) restrictions are evaluated by default at RCPT TO time.
                You need a decision that is made before or at STARTTLS time.

                Wietse
              • Viktor Dukhovni
                ... There were IIRC (also?) some issues with qmail, which is not updated terribly frequently. TLS_README says: Note, that unless client certificates are used
                Message 7 of 25 , Jul 29 6:42 AM
                  On Tue, Jul 29, 2014 at 09:13:19AM -0400, Wietse Venema wrote:

                  > > IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
                  > > because there are enough MTAs out there unable to handle client certificate
                  > > requests from a server they connect to.
                  >
                  > Is this still true? Assuming that you are referring to MTA-MTA
                  > communication, not end-user MUAs (such as old Netscape clients that
                  > should have fallen to dust by now).

                  There were IIRC (also?) some issues with qmail, which is not updated
                  terribly frequently. TLS_README says:

                  Note, that unless client certificates are used to allow greater access to
                  TLS authenticated clients, it is best to not ask for client certificates at
                  all, as in addition to increased overhead some clients (notably in some
                  cases qmail) are unable to complete the TLS handshake when client
                  certificates are requested.

                  This was long ago, someone might need to configure a few versions
                  of qmail with TLS and test... No idea which versions of qmail are
                  still in use.

                  > > It that is true, would it be possible to make smtpd_tls_ask_ccert client
                  > > dependent e.g. request a ccert when the client sends e.g. a specific HELO
                  > > hostname?
                  > >
                  > > mail.example.com ask_ccert
                  > > .example.net ask_ccert
                  >
                  > Alternatively, allow a richer input to smtpd_tls_ask_ccert besides
                  > yes and no. For example, a (match)list.

                  That was also my thinking, but I was expecting a new parameter,

                  smtpd_tls_ask_ccert_helo_names = <domain match list>

                  Turning "smtpd_tls_ask_ccert" from a boolean to a matchlist, requires
                  a bit of special gymnastics to deal with "yes" and "no", would that
                  be better?

                  --
                  Viktor.
                • Viktor Dukhovni
                  ... A related question is whether we should always (sometimes?, never?) set the client CA list to match the trusted CA list. The list of DNs is included in
                  Message 8 of 25 , Jul 29 6:53 AM
                    On Tue, Jul 29, 2014 at 01:42:18PM +0000, Viktor Dukhovni wrote:

                    > There were IIRC (also?) some issues with qmail, which is not updated
                    > terribly frequently. TLS_README says:
                    >
                    > Note, that unless client certificates are used to allow greater access to
                    > TLS authenticated clients, it is best to not ask for client certificates at
                    > all, as in addition to increased overhead some clients (notably in some
                    > cases qmail) are unable to complete the TLS handshake when client
                    > certificates are requested.
                    >
                    > This was long ago, someone might need to configure a few versions
                    > of qmail with TLS and test... No idea which versions of qmail are
                    > still in use.

                    A related question is whether we should always (sometimes?, never?)
                    set the client CA list to match the trusted CA list. The list of
                    DNs is included in the server's SSL HELLO as a hint of which
                    certificate to choose among many. I am not aware of any MTA that
                    uses this 'hint", typically the sole client certificate is used
                    unconditionally. Thus the client CA list can perhaps be left empty.

                    What is not clear is whether any MUAs need the "hint", and whether
                    MTAs (say old versions of qmail) would interoperate better with an
                    empty CA list than not.

                    Current Postfix behaviour is that the list of CAs sent to the client
                    is equal to the list of trusted CAs in smtpd_tls_CAfile (but not
                    CApath).

                    --
                    Viktor.
                  • Wietse Venema
                    ... smtpd_tls_ask_ccert_helo_names does not generalize. We d also need smtpd_tls_ask_ccert_client_names and smtpd_tls_ask_ccert_client_addrs and so on. Instead
                    Message 9 of 25 , Jul 29 7:03 AM
                      Viktor Dukhovni:
                      > > > It that is true, would it be possible to make smtpd_tls_ask_ccert client
                      > > > dependent e.g. request a ccert when the client sends e.g. a specific HELO
                      > > > hostname?
                      > > >
                      > > > mail.example.com ask_ccert
                      > > > .example.net ask_ccert
                      > >
                      > > Alternatively, allow a richer input to smtpd_tls_ask_ccert besides
                      > > yes and no. For example, a (match)list.
                      >
                      > That was also my thinking, but I was expecting a new parameter,
                      >
                      > smtpd_tls_ask_ccert_helo_names = <domain match list>
                      >
                      > Turning "smtpd_tls_ask_ccert" from a boolean to a matchlist, requires
                      > a bit of special gymnastics to deal with "yes" and "no", would that
                      > be better?

                      smtpd_tls_ask_ccert_helo_names does not generalize. We'd also need
                      smtpd_tls_ask_ccert_client_names and smtpd_tls_ask_ccert_client_addrs
                      and so on. Instead of introducing code that solves only one user-visible
                      problem, introduce infrastructure that can be reused in other contexts.

                      Wietse
                    • Viktor Dukhovni
                      ... My thinking is that only the HELO name is a plausibly correct client identity for certificate checks. This is that the client calls itself. while the
                      Message 10 of 25 , Jul 29 7:39 AM
                        On Tue, Jul 29, 2014 at 10:03:04AM -0400, Wietse Venema wrote:

                        > > That was also my thinking, but I was expecting a new parameter,
                        > >
                        > > smtpd_tls_ask_ccert_helo_names = <domain match list>
                        > >
                        > > Turning "smtpd_tls_ask_ccert" from a boolean to a matchlist, requires
                        > > a bit of special gymnastics to deal with "yes" and "no", would that
                        > > be better?
                        >
                        > smtpd_tls_ask_ccert_helo_names does not generalize. We'd also need
                        > smtpd_tls_ask_ccert_client_names and smtpd_tls_ask_ccert_client_addrs
                        > and so on. Instead of introducing code that solves only one user-visible
                        > problem, introduce infrastructure that can be reused in other contexts.

                        My thinking is that only the HELO name is a plausibly correct client
                        identity for certificate checks. This is that the client calls itself.
                        while the client name is not reliably available (DNS timeout, ...)
                        and the IP address is difficult to reliably associate with a given
                        sending organization. The envelope sender address is end-to-end,
                        and so is not applicable to hop-by-hop TLS security policy.

                        Therefore, the client gets to announce its name (via EHLO) and the
                        server can optionally request client certs when the alleged EHLO
                        name is on a list of special domains, or perhaps in the future when
                        there is a client DANE TLSA record for the name in question.

                        So the choice of "helo_names" is not random, it is I think the
                        only plausible "reference identity" for the client.

                        --
                        Viktor.
                      • Wietse Venema
                        ... It does not matter. We have a client with N properties and we need a matching mechanism. The matching mechanism should be more general than the specific
                        Message 11 of 25 , Jul 29 7:52 AM
                          Viktor Dukhovni:
                          > On Tue, Jul 29, 2014 at 10:03:04AM -0400, Wietse Venema wrote:
                          >
                          > > > That was also my thinking, but I was expecting a new parameter,
                          > > >
                          > > > smtpd_tls_ask_ccert_helo_names = <domain match list>
                          > > >
                          > > > Turning "smtpd_tls_ask_ccert" from a boolean to a matchlist, requires
                          > > > a bit of special gymnastics to deal with "yes" and "no", would that
                          > > > be better?
                          > >
                          > > smtpd_tls_ask_ccert_helo_names does not generalize. We'd also need
                          > > smtpd_tls_ask_ccert_client_names and smtpd_tls_ask_ccert_client_addrs
                          > > and so on. Instead of introducing code that solves only one user-visible
                          > > problem, introduce infrastructure that can be reused in other contexts.
                          >
                          > My thinking is that only the HELO name is a plausibly correct client
                          > identity for certificate checks. This is that the client calls itself.

                          It does not matter. We have a client with N properties and we need
                          a matching mechanism. The matching mechanism should be more general
                          than the specific user-visible problem at hand.

                          Anf if at all possible, we should also avoid a user interface that
                          requires two parameters to turn on/off one feature: one binary
                          parameter and one matching parameter.

                          Wietse
                        • Viktor Dukhovni
                          ... STARTTLS is just after the first EHLO, so what we have is: * Client IP address * Possibly a client DNS name we can t rely on. * A client EHLO name. Thus a
                          Message 12 of 25 , Jul 29 8:04 AM
                            On Tue, Jul 29, 2014 at 10:52:42AM -0400, Wietse Venema wrote:

                            > > My thinking is that only the HELO name is a plausibly correct client
                            > > identity for certificate checks. This is that the client calls itself.
                            >
                            > It does not matter. We have a client with N properties and we need
                            > a matching mechanism. The matching mechanism should be more general
                            > than the specific user-visible problem at hand.
                            >
                            > Anf if at all possible, we should also avoid a user interface that
                            > requires two parameters to turn on/off one feature: one binary
                            > parameter and one matching parameter.

                            STARTTLS is just after the first EHLO, so what we have is:

                            * Client IP address
                            * Possibly a client DNS name we can't rely on.
                            * A client EHLO name.

                            Thus a decision to ask for client certs can use at most these three
                            inputs. The user interface is then one of:

                            * smtpd_tls_ask_ccert_helo_names =
                            <domain match list> (overrides smtpd_tls_ask_ccert = no)

                            * smtpd_tls_ask_ccert =
                            no | yes |
                            match_client_{address,name,helo_name} type:name,
                            ...

                            We can indeed give users enough rope to attempt to use the client
                            address or name in this context.

                            If/when the DANE WG blesses TLSA records for TLS clients, we could
                            also enable client certs based on the presence of associated TLSA
                            RRs. These would have to be based on the client HELO name. Neither
                            of the other inputs are suitable for constructing the TLSA base
                            domain.

                            --
                            Viktor.
                          • Wietse Venema
                            ... And one more main.cf parameter for client TLSA records. That would make three. ... What would this user interface look like with client TLSA records?
                            Message 13 of 25 , Jul 29 8:24 AM
                              Viktor Dukhovni:
                              > * smtpd_tls_ask_ccert_helo_names =
                              > <domain match list> (overrides smtpd_tls_ask_ccert = no)

                              And one more main.cf parameter for client TLSA records. That would
                              make three.

                              > * smtpd_tls_ask_ccert =
                              > no | yes |
                              > match_client_{address,name,helo_name} type:name,
                              > ...

                              What would this user interface look like with client TLSA
                              records?

                              Wietse
                            • Viktor Dukhovni
                              ... Yes, in this model, another boolean to enable client TLSA records. ... Well, the DANE case is more interesting, because it likely fits better into
                              Message 14 of 25 , Jul 29 8:54 AM
                                On Tue, Jul 29, 2014 at 11:24:52AM -0400, Wietse Venema wrote:

                                > Viktor Dukhovni:
                                > > * smtpd_tls_ask_ccert_helo_names =
                                > > <domain match list> (overrides smtpd_tls_ask_ccert = no)
                                >
                                > And one more main.cf parameter for client TLSA records. That would
                                > make three.

                                Yes, in this model, another boolean to enable client TLSA records.

                                >
                                > > * smtpd_tls_ask_ccert =
                                > > no | yes |
                                > > match_client_{address,name,helo_name} type:name,
                                > > ...
                                >
                                > What would this user interface look like with client TLSA
                                > records?

                                Well, the DANE case is more interesting, because it likely fits
                                better into "req_ccert" than "ask_ccert", with the client cert
                                required when associated TLSA records are found, and validated
                                based on those records.

                                So we'd perhaps have:

                                smtpd_tls_req_ccert =
                                no | yes | dane

                                which leaves the question of whether this too needs a local policy
                                override:

                                smtpd_tls_req_ccert =
                                no | yes |
                                [ dane, ]
                                [ match_client_{address,name,helo_name} type:name, ]
                                ...

                                Where "no" or "yes" stand alone, but "dane" could be combined with
                                any of the match primitives.

                                Perhaps a better option is to change the "match" feature to a lookup
                                feature which returns a value of "no | ask | require | dane", thus we'd have:

                                smtpd_tls_ccert_policy =
                                lookup_client_address static:no,
                                lookup_client_helo_name static:ask,
                                lookup_client_name static:require,
                                lookup_client_helo_name static:dane,

                                with "static" being just an example table type that illustrates
                                the valid RHS values. With this "smtpd_tls_ccert_policy" subsumes
                                and obsoletes both of "smtpd_tls_ask_ccert" and "smtpd_tls_req_ccert".

                                --
                                Viktor.
                              • A. Schulze
                                ... Hello, I ask for client certs on every of my public mx servers without any compatibility issues for more the two years. Andreas
                                Message 15 of 25 , Jul 29 9:01 AM
                                  Patrick Ben Koetter:

                                  > IIRC smtpd_tls_ask_ccert should not be enabled on publicly
                                  > referenced MTAs ...
                                  > It that is true ...

                                  Hello,

                                  I ask for client certs on every of my public mx servers without any
                                  compatibility issues
                                  for more the two years.

                                  Andreas
                                • Viktor Dukhovni
                                  ... The syntactic overhead can be reduced, by making lookup_client_helo_name implicit: smtpd_tls_ccert_policy = static:dane and we could also make static:
                                  Message 16 of 25 , Jul 29 10:06 AM
                                    On Tue, Jul 29, 2014 at 03:54:37PM +0000, Viktor Dukhovni wrote:

                                    > Perhaps a better option is to change the "match" feature to a lookup
                                    > feature which returns a value of "no | ask | require | dane", thus we'd have:
                                    >
                                    > smtpd_tls_ccert_policy =
                                    > lookup_client_address static:no,
                                    > lookup_client_helo_name static:ask,
                                    > lookup_client_name static:require,
                                    > lookup_client_helo_name static:dane,
                                    >
                                    > with "static" being just an example table type that illustrates
                                    > the valid RHS values. With this "smtpd_tls_ccert_policy" subsumes
                                    > and obsoletes both of "smtpd_tls_ask_ccert" and "smtpd_tls_req_ccert".

                                    The syntactic overhead can be reduced, by making "lookup_client_helo_name"
                                    implicit:

                                    smtpd_tls_ccert_policy = static:dane

                                    and we could also make "static:" implicit when the string is one
                                    of: "no | ask | require | dane". Thus enabling a no-overhead form:

                                    smtpd_tls_ccert_policy = ask

                                    In addition we could also support "dane-only" (requiring TLSA RRs
                                    from a particular set of clients), and even allow the table lookups
                                    to return a certificate or public key fingerprint rather than "require".

                                    Which brings us back to the key question, what is the real motivation
                                    for this? Preventing HELO forgery? Making TLS access control easier
                                    to use (with "dane-only", one might be able to use check_helo_access
                                    safely, because certain HELO names would be authenticated)? Some sort
                                    of audit-trail that the client connection was not MiTMed?

                                    What are we really gaining here? Note that active attackers on the
                                    network path can change any of the three inputs (client IP, client
                                    name or client HELO name), so unless the client is using an MiTM
                                    resistant sending policy, we can't prevent MiTM attacks, rather
                                    we can only detect their absense in some cases and perhaps grant
                                    the client greater access.

                                    --
                                    Viktor.
                                  • BlueStar88
                                    ... First we should extend DNS using another MX-like entry, to be able to define authoritative MTA client nodes for a specific domain, so we have something to
                                    Message 17 of 25 , Jul 29 10:24 AM
                                      Am 29.07.2014 um 19:06 schrieb Viktor Dukhovni:
                                      > The syntactic overhead can be reduced, by making "lookup_client_helo_name"
                                      > implicit:
                                      >
                                      > smtpd_tls_ccert_policy = static:dane
                                      >
                                      > and we could also make "static:" implicit when the string is one
                                      > of: "no | ask | require | dane". Thus enabling a no-overhead form:
                                      >
                                      > smtpd_tls_ccert_policy = ask
                                      >
                                      > In addition we could also support "dane-only" (requiring TLSA RRs
                                      > from a particular set of clients), and even allow the table lookups
                                      > to return a certificate or public key fingerprint rather than "require".
                                      >
                                      > Which brings us back to the key question, what is the real motivation
                                      > for this? Preventing HELO forgery? Making TLS access control easier
                                      > to use (with "dane-only", one might be able to use check_helo_access
                                      > safely, because certain HELO names would be authenticated)? Some sort
                                      > of audit-trail that the client connection was not MiTMed?
                                      >
                                      > What are we really gaining here? Note that active attackers on the
                                      > network path can change any of the three inputs (client IP, client
                                      > name or client HELO name), so unless the client is using an MiTM
                                      > resistant sending policy, we can't prevent MiTM attacks, rather
                                      > we can only detect their absense in some cases and perhaps grant
                                      > the client greater access.

                                      First we should extend DNS using another MX-like entry, to be able to
                                      define authoritative MTA client nodes for a specific domain, so we have
                                      something to stick on. Then we can build the same ("backfiring")
                                      security checks, like we have on server connections today.

                                      Wishful thinking...

                                      ;-P


                                      BlueStar88
                                    • Viktor Dukhovni
                                      ... This was abandoned in favour of SPF, DKIM and DMARC. http://tools.ietf.org/html/draft-crocker-csv-csa-00 It was an anti-spam measure, and has no direct
                                      Message 18 of 25 , Jul 29 10:40 AM
                                        On Tue, Jul 29, 2014 at 07:24:41PM +0200, BlueStar88 wrote:

                                        > First we should extend DNS using another MX-like entry, to be able to
                                        > define authoritative MTA client nodes for a specific domain, so we have
                                        > something to stick on.

                                        This was abandoned in favour of SPF, DKIM and DMARC.

                                        http://tools.ietf.org/html/draft-crocker-csv-csa-00

                                        It was an anti-spam measure, and has no direct bearing on TLS client
                                        authentication.

                                        --
                                        Viktor.
                                      • Patrick Ben Koetter
                                        ... The use case goes like this: Company A and B agree to use TLS in order to protect communication. While it is simple for A to create a policy that enforces
                                        Message 19 of 25 , Jul 29 2:59 PM
                                          * Viktor Dukhovni <postfix-users@...>:
                                          > On Tue, Jul 29, 2014 at 03:54:37PM +0000, Viktor Dukhovni wrote:
                                          >
                                          > > Perhaps a better option is to change the "match" feature to a lookup
                                          > > feature which returns a value of "no | ask | require | dane", thus we'd have:
                                          > >
                                          > > smtpd_tls_ccert_policy =
                                          > > lookup_client_address static:no,
                                          > > lookup_client_helo_name static:ask,
                                          > > lookup_client_name static:require,
                                          > > lookup_client_helo_name static:dane,
                                          > >
                                          > > with "static" being just an example table type that illustrates
                                          > > the valid RHS values. With this "smtpd_tls_ccert_policy" subsumes
                                          > > and obsoletes both of "smtpd_tls_ask_ccert" and "smtpd_tls_req_ccert".
                                          >
                                          > The syntactic overhead can be reduced, by making "lookup_client_helo_name"
                                          > implicit:
                                          >
                                          > smtpd_tls_ccert_policy = static:dane
                                          >
                                          > and we could also make "static:" implicit when the string is one
                                          > of: "no | ask | require | dane". Thus enabling a no-overhead form:
                                          >
                                          > smtpd_tls_ccert_policy = ask
                                          >
                                          > In addition we could also support "dane-only" (requiring TLSA RRs
                                          > from a particular set of clients), and even allow the table lookups
                                          > to return a certificate or public key fingerprint rather than "require".
                                          >
                                          > Which brings us back to the key question, what is the real motivation
                                          > for this? Preventing HELO forgery? Making TLS access control easier
                                          > to use (with "dane-only", one might be able to use check_helo_access
                                          > safely, because certain HELO names would be authenticated)? Some sort
                                          > of audit-trail that the client connection was not MiTMed?

                                          The use case goes like this:

                                          Company A and B agree to use TLS in order to protect communication. While it
                                          is simple for A to create a policy that enforces TLS when they send to B,
                                          there's no easy way for B to enforce TLS on their (inbound) side.

                                          B may create a SMTP TLS-only listener on a dedicated port/ip and tell A to use
                                          that. Alternatively, if the feature we are discussin at the moment, was in
                                          place, they may as well create a policy that

                                          a) requires TLS if A's IP/hostname is used by the client
                                          b) requests the client to send its ccert
                                          c) verifies the clients ccert fingerprint matches one put down in a map

                                          This could all take place on a publicly referenced MX. Assuming both parties
                                          agreed to enforce TLS it would be RFC compliant.

                                          > What are we really gaining here? Note that active attackers on the

                                          The gain is mutual authentication. At the moment the SMTP server has no means
                                          to enforce TLS selectively on its default ip/port.

                                          > network path can change any of the three inputs (client IP, client
                                          > name or client HELO name), so unless the client is using an MiTM
                                          > resistant sending policy, we can't prevent MiTM attacks, rather
                                          > we can only detect their absense in some cases and perhaps grant
                                          > the client greater access.

                                          Correct me if I am wrong: Client-side DANE and/or ccert fingerprint matching
                                          would be apt to prevent MiTM attacks.

                                          p@rick


                                          --
                                          [*] sys4 AG

                                          https://sys4.de, +49 (89) 30 90 46 64
                                          Franziskanerstraße 15, 81669 München

                                          Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
                                          Vorstand: Patrick Ben Koetter, Marc Schiffbauer
                                          Aufsichtsratsvorsitzender: Florian Kirstein
                                        • Viktor Dukhovni
                                          ... No, it would at best detect their absence when there is no MiTM attack. Otherwise, when the client is not holding up its side of the bargain, and not
                                          Message 20 of 25 , Jul 29 3:30 PM
                                            On Tue, Jul 29, 2014 at 11:59:41PM +0200, Patrick Ben Koetter wrote:

                                            > > network path can change any of the three inputs (client IP, client
                                            > > name or client HELO name), so unless the client is using an MiTM
                                            > > resistant sending policy, we can't prevent MiTM attacks, rather
                                            > > we can only detect their absense in some cases and perhaps grant
                                            > > the client greater access.
                                            >
                                            > Correct me if I am wrong: Client-side DANE and/or ccert fingerprint matching
                                            > would be apt to prevent MiTM attacks.

                                            No, it would at best detect their absence when there is no MiTM
                                            attack. Otherwise, when the client is not holding up its side of
                                            the bargain, and not authenticating the server in an MiTM-resistant
                                            manner, there is nothing the server can do to avoid MiTM, because
                                            the MiTM attacker can mask the client's identity.

                                            So unless the client's real identity gets non-default access, all
                                            you get is an audit trail of the success cases, which you believe
                                            were not MiTMed, and the remaining cases may or may not have been.

                                            If the client's identity is used for access control, then potentially
                                            you get more robust access checks via the client's reference identity
                                            (HELO name), when that identity is verified via DANE or PKIX.

                                            You can't get MiTM protection because the client's reference identity
                                            is not known in advance at the server, and can be changed by the
                                            MiTM provided the alternate reference identity gets acceptable
                                            service.

                                            In your logs you might wonder why some mail from a particular domain
                                            is coming from a different IP address or from an unusual HELO name,
                                            but there is nothing on the wire to prove MiTM, all you see is a
                                            connection from a client not subject to the certificate requirements.

                                            I am not saying that evidence of lack of MiTM for some connections
                                            is not useful, but you need to understand the limits of the
                                            technology.

                                            --
                                            Viktor.
                                          • BlueStar88
                                            ... That RFC is from 2005 and was considered for anti-spam, as you ve said. But does that mean, it is buried forever? If we have a new - and quite serious -
                                            Message 21 of 25 , Jul 29 4:15 PM
                                              Am 29.07.2014 um 19:40 schrieb Viktor Dukhovni:
                                              > On Tue, Jul 29, 2014 at 07:24:41PM +0200, BlueStar88 wrote:
                                              >
                                              >> First we should extend DNS using another MX-like entry, to be able to
                                              >> define authoritative MTA client nodes for a specific domain, so we have
                                              >> something to stick on.
                                              > This was abandoned in favour of SPF, DKIM and DMARC.
                                              >
                                              > http://tools.ietf.org/html/draft-crocker-csv-csa-00
                                              > It was an anti-spam measure, and has no direct bearing on TLS client
                                              > authentication.

                                              That RFC is from 2005 and was considered for anti-spam, as you've said.
                                              But does that mean, it is buried forever?
                                              If we have a new - and quite serious - purpose here (having mutual TLS
                                              security in mind), it should be revived to support that.

                                              If there's another way, I'm fine with that. But we have to improve here
                                              by any means, to keep up with the ongoing arms race.
                                              Having neat things like DNSSEC and DANE to backup up TLS security
                                              doesn't make much sense, if only one party/peer of each connection can
                                              uphold a certain security level.

                                              --
                                              BlueStar88 (bluestar88@...)
                                            • Scott Kitterman
                                              ... CSV doesn t really offer more than an SPF check on the HELO identity. It s dead. Scott K
                                              Message 22 of 25 , Jul 29 4:35 PM
                                                On July 29, 2014 7:15:04 PM EDT, BlueStar88 <bluestar88@...> wrote:
                                                >
                                                >Am 29.07.2014 um 19:40 schrieb Viktor Dukhovni:
                                                >> On Tue, Jul 29, 2014 at 07:24:41PM +0200, BlueStar88 wrote:
                                                >>
                                                >>> First we should extend DNS using another MX-like entry, to be able
                                                >to
                                                >>> define authoritative MTA client nodes for a specific domain, so we
                                                >have
                                                >>> something to stick on.
                                                >> This was abandoned in favour of SPF, DKIM and DMARC.
                                                >>
                                                >> http://tools.ietf.org/html/draft-crocker-csv-csa-00
                                                >> It was an anti-spam measure, and has no direct bearing on TLS client
                                                >> authentication.
                                                >
                                                >That RFC is from 2005 and was considered for anti-spam, as you've said.
                                                >But does that mean, it is buried forever?
                                                >If we have a new - and quite serious - purpose here (having mutual TLS
                                                >security in mind), it should be revived to support that.
                                                >
                                                >If there's another way, I'm fine with that. But we have to improve here
                                                >by any means, to keep up with the ongoing arms race.
                                                >Having neat things like DNSSEC and DANE to backup up TLS security
                                                >doesn't make much sense, if only one party/peer of each connection can
                                                >uphold a certain security level.

                                                CSV doesn't really offer more than an SPF check on the HELO identity. It's dead.

                                                Scott K
                                              • Viktor Dukhovni
                                                ... I m afraid magical thinking does not make progress in this space. What s reasonable to do is constrained by what is possible to do, (additional practical
                                                Message 23 of 25 , Jul 29 4:50 PM
                                                  On Wed, Jul 30, 2014 at 01:15:04AM +0200, BlueStar88 wrote:

                                                  > Am 29.07.2014 um 19:40 schrieb Viktor Dukhovni:
                                                  > > On Tue, Jul 29, 2014 at 07:24:41PM +0200, BlueStar88 wrote:
                                                  > >
                                                  > >> First we should extend DNS using another MX-like entry, to be able to
                                                  > >> define authoritative MTA client nodes for a specific domain, so we have
                                                  > >> something to stick on.
                                                  > > This was abandoned in favour of SPF, DKIM and DMARC.
                                                  > >
                                                  > > http://tools.ietf.org/html/draft-crocker-csv-csa-00
                                                  > > It was an anti-spam measure, and has no direct bearing on TLS client
                                                  > > authentication.
                                                  >
                                                  > That RFC is from 2005 and was considered for anti-spam, as you've said.
                                                  > But does that mean, it is buried forever?
                                                  > If we have a new - and quite serious - purpose here (having mutual TLS
                                                  > security in mind), it should be revived to support that.
                                                  >
                                                  > If there's another way, I'm fine with that. But we have to improve here
                                                  > by any means, to keep up with the ongoing arms race.
                                                  > Having neat things like DNSSEC and DANE to backup up TLS security
                                                  > doesn't make much sense, if only one party/peer of each connection can
                                                  > uphold a certain security level.

                                                  I'm afraid magical thinking does not make progress in this space.
                                                  What's reasonable to do is constrained by what is possible to do,
                                                  (additional practical constraints also apply). When you keep
                                                  suggesting the impossible, I can only continue to dismiss the
                                                  suggestions.

                                                  DANE is quite useful for authenticating the receiving server, even
                                                  if it plays no role in authenticating the client. No authentication
                                                  system can magically break the asymmetry between the client and
                                                  server roles. As I have explained multiple times it is not possible
                                                  to prevent MiTM on the server side when all clients are granted
                                                  the same authorization (to send mail to the server's domains).

                                                  Only when some clients are more authorized than others does
                                                  authentication ensure that MiTMed sessions don't hijack the authorized
                                                  privileges of the real client.

                                                  It is not possible to *prevent* MiTM on the server side. The most
                                                  you can sometimes do is check that the alleged client identity is not
                                                  MiTMed, but that alleged identity may have been modified by the MiTM.

                                                  In other words, you can't stop downgrade attacks on the client
                                                  identity. And I mean "can't" in a strong mathematical sense, not
                                                  in some practical sense that might change tomorrow.

                                                  Therefore, please cease the repeated suggestions that we do the
                                                  impossible. It can't happen, and therefore it won't happen.

                                                  DANE authentication of clients won't stop MiTM. However it can
                                                  generate an audit trail of known-good sessions, and can help to
                                                  simplify the management of custom access rights, replacing difficult
                                                  to coordinate fingerprints with associated verified reference
                                                  identities. This could hypothentically also help with reputation
                                                  systems, ...

                                                  In no case can this help to thwart active attacks by nation-state
                                                  adversaries that want to intercept encrypted traffic. That defense
                                                  remains the sole responsibility of the client. No amount of magical
                                                  thinking changes this, even if my reasoning seems wrong or unclear.

                                                  --
                                                  Viktor.
                                                • Wietse Venema
                                                  I think it would help if someone can explain what an SMTP client certificate actually proves, without all the wishful thinking that every nugget of security
                                                  Message 24 of 25 , Jul 29 4:53 PM
                                                    I think it would help if someone can explain what an SMTP client
                                                    certificate actually proves, without all the wishful thinking that
                                                    every nugget of "security" is a worthwhile improvement.

                                                    What does the certificate really prove about the SMTP client?

                                                    What does the certificate prove about the connection from that SMTP
                                                    client, and how useful is that really, bearing in mind that this
                                                    SMTP connection is very likely only the last one in a sequence of
                                                    network connections?

                                                    What does it prove about the message envelope and message content
                                                    that was sent over that SMTP connection, bearing in mind that the
                                                    message very likely originated from some other system?

                                                    Wietse
                                                  • Viktor Dukhovni
                                                    ... Others may have their views of what a client certificate actually demonstrates, below is mine: * It establishes an identity for the party at the other end
                                                    Message 25 of 25 , Jul 29 5:54 PM
                                                      On Tue, Jul 29, 2014 at 07:53:41PM -0400, Wietse Venema wrote:

                                                      > I think it would help if someone can explain what an SMTP client
                                                      > certificate actually proves, without all the wishful thinking that
                                                      > every nugget of "security" is a worthwhile improvement.
                                                      >
                                                      > What does the certificate really prove about the SMTP client?
                                                      >
                                                      > What does the certificate prove about the connection from that SMTP
                                                      > client, and how useful is that really, bearing in mind that this
                                                      > SMTP connection is very likely only the last one in a sequence of
                                                      > network connections?
                                                      >
                                                      > What does it prove about the message envelope and message content
                                                      > that was sent over that SMTP connection, bearing in mind that the
                                                      > message very likely originated from some other system?

                                                      Others may have their views of what a client certificate actually
                                                      demonstrates, below is mine:

                                                      * It establishes an identity for the party at the other end of the TLS
                                                      connection be it the "true" client or the MiTM.

                                                      * This identity may or may not be the party attempting to send a
                                                      given message. To avoid MiTM attacks, the sending systems has
                                                      to authenticate the server.

                                                      * When a given organization (say an email service provider of
                                                      some sort) has non-default access permissions to inject mail
                                                      into a given server's queue, then a client certificate may be
                                                      used as an alternative to SASL authentication to authenticate
                                                      with an identity that is authorized for the desired access.

                                                      * If we add a feature that makes it possible to authenticate a
                                                      client reference identity (typically the HELO name) via DANE
                                                      or PKIX, then it becomes easier to grant non-default access
                                                      rights based on a more stable identifier than a certificate
                                                      fingerprint (which is difficult to coordinate across
                                                      organizational boundaries).

                                                      * Logging of DANE or PKIX verified HELO names may show positive
                                                      evidence that some messages originated where claimed and were
                                                      not intercepted in transit. However, in fact what learns is
                                                      the identity of either the "true" client or the "true" MiTM.
                                                      If one can reasonably rule out the possibility that the
                                                      authenticated party is in fact an MiTM attacker on some other
                                                      source, then one may cautiously conclude that the message in
                                                      question was delivered over a secure channel.

                                                      * That said, should an MiTM attack take place, and if the sending
                                                      system is not doing its job of authenticating the receiving server,
                                                      there is nothing the server can do to detect MiTM, rather all that
                                                      happens is that the MiTMed transmission either has no client
                                                      cert at all (along with a forged HELO name and/or source IP address),
                                                      or has a certificate for some untraceable throw-away domain. The
                                                      transmission will no longer have the authorization of the "real"
                                                      client, provided that client has non-default authorization based
                                                      on its special identity.

                                                      An astute administrator may be able to put enhanced functionality
                                                      in this space to good use. It seems likely that many will simply
                                                      enjoy a false sense of "security", where none exists. I am inclined
                                                      to add some functionality in this space, with strong disclaimers
                                                      in the documentation.

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