TLSA/DANE: Prinzipielles

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TLSA/DANE: Prinzipielles

Friedemann Stoyan
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?

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
Reply | Threaded
Open this post in threaded view
|

Re: TLSA/DANE: Prinzipielles

Patrick Ben Koetter-2
Friedemann,

* Friedemann Stoyan <[hidden email]>:

> 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@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
 
Reply | Threaded
Open this post in threaded view
|

Re: TLSA/DANE: Prinzipielles

Friedemann Stoyan
On 28.06.18 16:19, Patrick Ben Koetter wrote:
> […]
> 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@rick

Danke für die Erläuterung. Nun ist alles klar.

mfg Friedemann