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

301295Re: Individual smtpd_tls_ask_ccert?

Expand Messages
  • Viktor Dukhovni
    Jul 29, 2014
      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

    • Show all 25 messages in this topic