TLSA/DANE: Prinzipielles

Patrick Ben Koetter p at sys4.de
Do Jun 28 16:19:39 CEST 2018


Friedemann,

* Friedemann Stoyan <postfixbuch-users at listen.jpberlin.de>:
> Liebe Mitadmins!
> 
> Ich würde gerne einmal ein prinzipielles Thema bezüglich TLSA/DANE
> ansprechen.
> 
> Für das Zertifikat, das der SMTP-Daemon vorzeigt, kann ich ja einen
> TLSA-RR generieren und in das DNS tun. Der Client kann somit prüfen,
> ob das mit dem Zertifikat so stimmig ist. Soweit sogut.
> 
> Was, wenn der smtpd ein RSA und ein ECDSA-Zertifikat hat? Zwei
> TLSA-RRs?
> 
> Der SMTP Client kann ja auch ein (oder zwei) Zertifikate vorzeigen.
> Sollen/können für diese auch TLSA-RRs gemacht werden? Kann der smtpd
> auf der Gegenseite damit umgehen?

Der Client kann damit umgehen. Und das nicht nur zufällig, denn das RFC sieht
explizit vor, dass ein Client alle TLSA-Records einer Ressource prüfen muss.
Ausschlaggebend ist für den Client nur, dass *einer* passt.

Dieser Ansatz findet auch Anwendung beim Rollover eines TLSA-RRs. Du pflegst
beide ein, wartest $TTL bis alle den neuen TLSA lernen konnten und den alten
vergessen sollten und dann aktivierst Du das neue Cert im smtpd. Anschliessend
entfernst Du den alten TLSA im DNS.

Wenn der Client ein Cert vorweist, dann hat das für DANE heute keine
Auswirkungen. Die RFCs sehen keine mutual-auth vor. Ich hatte das mal ins
Gespräch gebracht, aber das Interesse war in der working group zu gering
ausgeprägt.

p at rick



> 
> Das würde also bedeuten, dass für einen MX Record 4 Stück TLSA-RRs
> erzeugt werden (RSA/ECDSA + Client/Server).
> 
> Sind meine Gedankengänge soweit korrekt?
> 
> mfg Friedemann

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 


Mehr Informationen über die Mailingliste Postfixbuch-users