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

301316Re: Individual smtpd_tls_ask_ccert?

Expand Messages
  • Patrick Ben Koetter
    Jul 29, 2014
    • 0 Attachment
      * 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
    • Show all 25 messages in this topic