Menü
Avatar von Achim Kraus
  • Achim Kraus

4 Beiträge seit 24.05.2004

Vielleicht lieber mal DTLS 1.2 ausprobieren

Das ist schon etwas irre:

Da gibt es kaum ein Handvoll DTLS 1.2 Implementierungen, die auch die "sicheren" Spar-Feature wie RPK (RawPublicKey RFC7250) umsetzen und zuverlässig funktionieren, da versucht man, neue Wege zu gehen.

Ja, bei DTLS 1.2 kann es schon sein, dass ein NAT die zugeordnete Adresse wechselt, dafür kann man dann ein Connection ID einsetzen. Das ist noch nicht ganz fertig und aktuell gibt es auch noch sehr wenige Implementierungen. Damit halten aber auch die verschlüsselte Assoziation (Verbindung des verbindungslosen UDP :-) ) deutlich länger, sogar wenn die Geräte im Schlafmodus sind.

Mir erscheint es zweifelhaft, auf OSCORE oder cTLS zu setzen, ohne wirklich zu zeigen das DTLS 1.2 eine schlechte Wahl ist. Und ob die beiden besser funktionieren, muss ja wohl auch noch nachgewiesen werden. Ich befürchte mal, mit guten Implementierungen sieht es da in naher Zukunft nicht so gut aus.

Noch mehr Daten einsparen könnte man auch mit DTLS 1.2 Erweiterungen, besonders wenn man von "vorab-deployments" ausgeht (Gerät und Server tauschen vorab die Zertifikate bzw. "public keys"). Wenn man eh ECDHE benötigt (wegen "perfect forward secrecy") braucht man effizientes ECC, da kann man dann ECDSA miterledigen. Und mit vorab ausgetauschten Zertifikaten könnte man die mit zusätzlichen Erweiterungen, ähnlich wie RFC6066 "client_certificate_url" anstatt der Zertifikate (leicht 1-2k kBytes) IDs von ein paar Bytes (32) verwenden.

Daher bin ich gespannt, was von all diesen Ideen wirklich implementiert wird.

Bewerten
- +
Anzeige