[Ach] filippo on SSL SMTP encryption

[Manuel Kraus]

Am 01.04.2015 um 12:17 schrieb Hanno Böck:
> Depends on what we're talking, but there are people out there
> promoting DANE for https and things like pgp keys via dnssec.
> <...>
>
> I agree that servers are a different thing. Maybe DNSSEC will have its
> place to protect s2s crypto. But I still see a lot of issues there.
> Like "Oh you live in a country where your TLD operator doesn't support
> DNSSEC yet? There's nothing you can do..."
> That's what I meant with the too many pieces.
>
> I'd feel a pinning solution for smtp/starttls would bring us more than
> dnssec. tack is in limbo right now (and I'm not sure if it'd solve
> everything needed for smtp).
>
> <...>
>
> HPKP and Certificate Transparency.
> And I feel there's really a big difference between DANE on one side and
> HPKP/CT on the other. HPKP needs two pieces to work (a server config
> and a client software change). CT needs more pieces, but it was
> explicitly designed in a way that even partly deployment already gains
> you something. (you can check the CT logs if there are bad certs
> popping up for your domain - there was a service to do that for you,
> but it seems it's gone...)

The issue with not-supporting TLD-Providers can be solved by simply
using other popular anchors, maybe multiple of them in different
jurisdictions. I use the TLD's and the ISC.org's anchors [1]. The only
way to harden this single point of trust thing (same problem like with
CA), is to use multiple anchors and do cross-check them (which you
cannot do with CA, but with DNSSEC). There could be an open list of
popular trust anchors where people put their keys. Software developers
could hardcode those anchors in their clients and decide on a vote
basis, to give some room to detect bad apples without instantly loosing
the whole concept. Such a result then could end in something like HPKP /
stapling to take away the load after initial checks were done.
As long you trust a DNSSEC trust anchor (again, better a whole group of
them), you can do the pinning by DANE with high reliability. The best
outcome of this would be to drop the need of a single commercial or
governmental CA. Like this the needed transparency is in parts delivered
by DANE, since valid fingerprints are publicly available in a mature
manner and perhaps cross-checkable. Such a cross-checking ability would
be -the- huge improvement over the single point of trust concept like
the classic CA model.

As I understand, mentioned alternative (HPKP) is not available at
present and has the disadvantage on relying on a TOFU-procedure, where
an attacker simply could intercept the first request. If he's in
position to MITM a server target, fake a certificate, he'll be able to
manipulate TOFU too, having the users stick on that bad certificate for
even a much longer time as a result.

But, well, if the currently underlying DNSSEC crypto really sucks (as to
read in the mentioned rant articles) we're doomed with it at present.
Maybe that can be fixed simply using better algorithms?

All IMHO, thanks for understanding.


Regards

Manuel

[1] http://dnsviz.net/d/lsd.is/dnssec/