[Postfixbuch-users] DKIM-Impact

[Alexander Stoll]

Am 17.03.2014 13:14, schrieb Django [BOfH]:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Griasde Alexander!
>
> Am 17.03.2014 11:40, schrieb Alexander Stoll:
>
>> Trotzdem passt mir das stumpfe, unreflektierte "Draufhauen" welches
>> in diesem Thread Einzug gehalten hat nicht,
>
> Ja mei, so bin ich hald mal. Wenn einer mich auf die RTF-RFC Schiene
> kommt und dabei Spuren im Log der Web-GUI hinterlässt, die nahelegen,
> dass da einer einfach mal probiert hat, wieviel Zeichen in die WEB-GUI
> passen, dann - ganz ehrlich - fühle ich mich ein wenig arg verschei......

Alles gut, kein Problem an der Stelle, das war auch nicht als exklusive 
Kritik an Deiner Äußerung gemeint, mir geht es eher darum die 
Interessanten Aspekte aus der Argumentation nicht in einem pauschalen 
"das ist nur der schlechte Service von Dienstleister XY" untergehen zu 
lassen und nicht den Service (den ich in dem Kontext auch für 
unzureichend halte...) zu verteidigen.

>> Man darf ruhig das Schutzinteresse und Zweck von DKIM und
>> sinnvolle Schlüssellänge
>
> Also ich hab das ja mal so gemacht, RFC gelesen, Konfigurationsdoku
> von Marc gelesen, Konfiguration angepasst und alles entsprechend
> dokumentiert. Nebenbei einfach malgekuckt, welche Schlüssellänge
> andere professionelle Mitspieler in der ganzen Mailgeschichte so
> benutzen und dann die Schlüssellänge für den eigenen Mailserver auf
> 4096 gesetzt.

Genau das ist der Punkt, ich will die Parameter für die 
Designentscheidung "welche Schlüssellänge nehme ich" erweitern, das ist 
der Teil, worauf ich abziele.

Aus Zeitgründen flechte ich Peer´s Einwurf gleich hier mit ein: Im 
Gegensatz zum verlinkten Szenario eines offenen rekursiven Resolvers 
liegt hier die Problemstellung anders. Ich _muss_ keinen offenen 
Resolver betreiben, habe ich z.B. einen primären NS im eigenen Netz 
stehen und serviere DKIM (passt btw. auf jeden anderen größeren 
TXT-Record), dann muss ich auch Queries zu diesen beantworten. Rate 
Limiting hilft nur begrenzt, ich verlagere ggf. die Last auf den 
mindestens vorhandenen externen NS macht der z.B. als 
Dienstleistungsobjekt meines Registrars oder sonstigen externen 
Anbieters auch Rate Limiting, ist schnell die Situation erreicht, wo 
kein legitimer Query mehr mit ausreichender Wahrscheinlichkeit 
beantwortet wird.
Zu den Größenverhältnissen: Die größte Relevanz in diesem Szenario hat 
das Verhältnis Querie/Response, das Argument "hat nur den Faktor zwei" 
von der anderen Seite betrachtet heißt "braucht nur die halbe Anzahl an 
eingehenden Queries zur Sättigung meines Uplinks..."
Andere zu schützen ist nicht der Ausgangspunkt meiner Betrachtung, als 
unfreiwillig mitwirkender in so einen Angriffsszenario hat eine 
Sättigung des Uplinks genau die gleichen fatalen Auswirkungen auf meinen 
Service, wie wenn ich direkt Opfer und beabsichtigtes Ziel der Attacke wäre.

Fakt ist, je größer der Verstärkungsfaktor, der sich durch meine großen 
TXT-Records erreichen lässt, um so attraktiver bin ich als 
unfreiwilliger Mitspieler in so einem Szenario.
Es gibts hier auch keine pauschale Antwort oder Empfehlung, alles hängt 
von der Topologie/Infrastruktur und einer Reihe weiterer Faktoren ab. 
Mir geht es nur darum, bei einer Designentscheidung zur Einführung von 
DKIM einen weiteren Faktor gewichten und betrachten zu können, um hier 
eine ausgewogene Entscheidung treffen, der das Szenario einer 
Amplification Attack mit einbezieht.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 2576 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20140317/6508c98b/attachment.p7s>