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

301320Re: Individual smtpd_tls_ask_ccert?

Expand Messages
  • Viktor Dukhovni
    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

      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.

    • Show all 25 messages in this topic