Mon Dieu la quantité de désinformation dans ce message ><
DNSSec impose un roulement régulier de ta clef de signature.
C’est recommandé mais en aucun cas imposé. La seule chose qui est réellement imposé est le renouvellement des signatures elles-mêmes, qui ne sont valides que pour un intervalle de temps donné.
la signature de zone, renouvelée toutes les 2h
la ZSK, renouvelé tous les 90j, qui signe ta zone DNS
la KSK, renouvelé ×ばつ par an
PERSONNE ne t’impose ces délais de renouvellement. Tu les choisis, toi et toi seul.
Le RFC 6781 donne à titre indicatif, pour la durée de validité des signatures, une plage allant de « quelques jours » à « plusieurs mois ».
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Encore une fois, tu t’imposes ça. Il y a d’autres possibilités, par exemple opter pour un compromis avec une ZSK disponible sur le serveur primaire (via un HSM plutôt que directement sur le serveur pour ceux qui ont les moyens) pour re-signer périodiquement la zone, seule la KSK restant hors-ligne.
C’est d’ailleurs la principale raison d’avoir une ZSK et une KSK séparées (non, ça non plus ce n’est pas « imposé » par DNSSEC). Si tu les considères toutes les deux comme également critiques, devant absolument être hors ligne, autant se simplifier la vie et se contenter d’une seule clef.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Seulement si tu choisis 1 d’épingler les certificats plutôt que les clefs publiques (j’ai déjà dit plus haut que ça n’apportait rien dans le cas où tu épingles au niveau terminal, et que c’est déconseillé par le RFC 7671) et 2 de renouveller les clefs à chaque renouvellement de certificat, ce que RIEN NE T’OBLIGE À FAIRE (je ne suis pas le seul à te l’avoir dit, et ne viens pas dire « ouais mais c’est pas le comportement par défaut des clients », quand on monte des usine à gaz comme tu sembles aimer le faire, gérer soi-même les CSR avec un client ACME n’est pas hors de portée).
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
Si, ton choix des 2h est une obligation totalement arbitraire que tu t’imposes à toi-même.
DNS est basé sur UDP.
Pour information, DNS fonctionne aussi bien sur UDP que sur TCP (seuls les administrateurs restés bloqués dans les années 90 continuent à croire que le DNS ne passe que sur UDP), et l’utilisation de TCP est même de plus en plus fréquente (en partie à cause/grâce à DNSSEC justement, qui augmente considérablement la taille des réponses).
et ne peut donc pas envoyer de paquets de plus de 548 octets
D’une, TCP existe (cf. ci-dessus), et de deux, même en UDP, EDNS(0) permet de spécifier des tailles de paquets supérieures.
donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins)
En général, on est plutôt sur du 2048-bit pour les KSK et 1024-bit pour les ZSK — et encore, la tendance est à la généralisation du 2048-bit même pour la ZSK (par exemple, la nouvelle ZSK 2048-bit de la racine vient d’être pré-publiée, et devrait bientôt entrer en service).
On a bien compris que tu n’aimais pas Let’s Encrypt. On t’oblige à l’utiliser alors que ce n’est pas compatible avec les choix arbitraires que tu as fait (et qui sont les seuls bons choix possibles, évidemment — quiconque ne fait pas les mêmes choix que toi est un inconscient qui n’y connais rien en sécurité, non mais c’est qui le crypto-terroriste ici ?), donc c’est le Mal.
C’est bon, on a compris, plus la peine de raconter n’importe quoi pour faire passer le message. ><
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 7.
Mon Dieu la quantité de désinformation dans ce message ><
C’est recommandé mais en aucun cas imposé. La seule chose qui est réellement imposé est le renouvellement des signatures elles-mêmes, qui ne sont valides que pour un intervalle de temps donné.
PERSONNE ne t’impose ces délais de renouvellement. Tu les choisis, toi et toi seul.
Le RFC 6781 donne à titre indicatif, pour la durée de validité des signatures, une plage allant de « quelques jours » à « plusieurs mois ».
Encore une fois, tu t’imposes ça. Il y a d’autres possibilités, par exemple opter pour un compromis avec une ZSK disponible sur le serveur primaire (via un HSM plutôt que directement sur le serveur pour ceux qui ont les moyens) pour re-signer périodiquement la zone, seule la KSK restant hors-ligne.
C’est d’ailleurs la principale raison d’avoir une ZSK et une KSK séparées (non, ça non plus ce n’est pas « imposé » par DNSSEC). Si tu les considères toutes les deux comme également critiques, devant absolument être hors ligne, autant se simplifier la vie et se contenter d’une seule clef.
Seulement si tu choisis 1 d’épingler les certificats plutôt que les clefs publiques (j’ai déjà dit plus haut que ça n’apportait rien dans le cas où tu épingles au niveau terminal, et que c’est déconseillé par le RFC 7671) et 2 de renouveller les clefs à chaque renouvellement de certificat, ce que RIEN NE T’OBLIGE À FAIRE (je ne suis pas le seul à te l’avoir dit, et ne viens pas dire « ouais mais c’est pas le comportement par défaut des clients », quand on monte des usine à gaz comme tu sembles aimer le faire, gérer soi-même les CSR avec un client ACME n’est pas hors de portée).
Si, ton choix des 2h est une obligation totalement arbitraire que tu t’imposes à toi-même.
Pour information, DNS fonctionne aussi bien sur UDP que sur TCP (seuls les administrateurs restés bloqués dans les années 90 continuent à croire que le DNS ne passe que sur UDP), et l’utilisation de TCP est même de plus en plus fréquente (en partie à cause/grâce à DNSSEC justement, qui augmente considérablement la taille des réponses).
D’une, TCP existe (cf. ci-dessus), et de deux, même en UDP, EDNS(0) permet de spécifier des tailles de paquets supérieures.
En général, on est plutôt sur du 2048-bit pour les KSK et 1024-bit pour les ZSK — et encore, la tendance est à la généralisation du 2048-bit même pour la ZSK (par exemple, la nouvelle ZSK 2048-bit de la racine vient d’être pré-publiée, et devrait bientôt entrer en service).
On a bien compris que tu n’aimais pas Let’s Encrypt. On t’oblige à l’utiliser alors que ce n’est pas compatible avec les choix arbitraires que tu as fait (et qui sont les seuls bons choix possibles, évidemment — quiconque ne fait pas les mêmes choix que toi est un inconscient qui n’y connais rien en sécurité, non mais c’est qui le crypto-terroriste ici ?), donc c’est le Mal.
C’est bon, on a compris, plus la peine de raconter n’importe quoi pour faire passer le message. ><
/plonk