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.
