Bonjour,

que risque-t-on si le status d'un nom de domaine est simplement 'Ok'
plutôt que :

Status: clientDeleteProhibited
Status: clientTransferProhibited

Merci.

Olivier Masson <sisemen@laposte.net> a couché sur son écran le
07/05/2007 15:11:50 +0200 :
> Bonjour,
>
> que risque-t-on si le status d'un nom de domaine est simplement 'Ok'
> plutôt que :
>
> Status: clientDeleteProhibited
> Status: clientTransferProhibited

Qu'une personne ayant l'auth code puisse le transférer.
--
oui mais bon les choses changent, évoluent, les DSLAM se connaissent
mieux maintenant, sont plus des étrangers les uns pour les autres,
z'ont plus forcément envie de faire chambre à part :-)
-+- Brina in GFD - "Rapprochement stratégique" -+-

Le Mon, 07 May 2007 17:37:47 +0200, Monsieur 99 a écrit :
>> Status: clientDeleteProhibited
>> Status: clientTransferProhibited
>
> Qu'une personne ayant l'auth code puisse le transférer.

Si cette personne a récupéré cette information elle a probablement
déjà accès au compte chez le bureau d'enregistrement... qui permettra
d'enlever ces deux « protections ».

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek <pm-N200705@nospam.dotandco.com> a couché sur son écran
le 07/05/2007 17:39:42 +0200 :
> Le Mon, 07 May 2007 17:37:47 +0200, Monsieur 99 a écrit :
>>> Status: clientDeleteProhibited
>>> Status: clientTransferProhibited
>> Qu'une personne ayant l'auth code puisse le transférer.
>
> Si cette personne a récupéré cette information elle a probablement
> déjà accès au compte chez le bureau d'enregistrement... qui permettra
> d'enlever ces deux « protections ».
>

Effectivement :-)

--
> à dos de Mule ?
Ben euh, ils y sont allés avec ma femme, mais je pense que c'est la
voiture qui transportait, donc la réponse est "non" ;-)
-+- SC in GFD - "Macho ? Vue de l'esprit, toussa..." -+-

Patrick Mevzek a écrit :

> Si cette personne a récupéré cette information elle a probablement
> déjà accès au compte chez le bureau d'enregistrement... qui permettra
> d'enlever ces deux « protections ».
>

Donc c'est un peu du pipeau commercial ?

Olivier Masson <sisemen@laposte.net> a couché sur son écran le
07/05/2007 20:05:42 +0200 :
> Patrick Mevzek a écrit :
>
>> Si cette personne a récupéré cette information elle a probablement
>> déjà accès au compte chez le bureau d'enregistrement... qui permettra
>> d'enlever ces deux « protections ».
>>
>
> Donc c'est un peu du pipeau commercial ?

Depuis l'introduction de l'auth code, oui. Avant, un petit peu moins.


--
> Pourquoi faut'il tout ce temps?
Restriction de budget .. Ils amenent le materiel au central a dos de
chameau (et il faut le temps de trouver le chameau)
-+- Spyou in GFD - "Ils dégroupent toujours en Egypte" -+-

Le Mon, 07 May 2007 20:05:42 +0200, Olivier Masson a écrit :
>> Si cette personne a récupéré cette information elle a probablement
>> déjà accès au compte chez le bureau d'enregistrement... qui permettra
>> d'enlever ces deux « protections ».
>
> Donc c'est un peu du pipeau commercial ?

Ce qui été du pipeau c'était de faire croire que le code
d'authentification allait résoudre tous les problèmes de transfert,
alors qu'on est dans le cas typique d'un problème nécessitant un
compromis puisqu'on a dans la balance d'un côté de limiter les
transferts frauduleux, de l'autre de faciliter la mobilité entre bureaux.

L'affaire RegisterFly illustre d'ailleurs bien la difficulté de faire des
transferts maintenant à cause de ce code (que le bureau doit donner). A
noter qu'on constate là une certaine impédance entre ce qui était
prévu au niveau des concepteurs du protocole EPP (qui pensaientt que le
code serait choisi lors de l'enregistrement du nom de domaine - rarement
le cas - et aisément accessible voire modifiable par le « propriétaire
» du domaine) et ce qu'on a vu en pratique (les catastrophes initiales
allaient même jusqu'à certains bureaux d'enregistrement qui utilisaient
un seul et même code pour tous les domaines qu'ils géraient !).

De nos jours, un bureau d'enregistrement ne peut pas démarrer le
transfert (au sens de la commande à envoyer au registre) sans la
possession de ce code, ce qui n'est donc pas toujours facile à obtenir.
Plusieurs registres caressent l'idée de pouvoir envoyer ce code
directement, en court-circuitant le bureau d'enregistrement : c'est
possible puisque tous les nouveaux gTLDs stockent les informations
personnelles (donc en particulier les adresses email des contacts et
propriétaire) au niveau du registre.

A noter que certains bureaux d'enregistrement sont très enclins à mettre
automatiquement un état clientTransferProhibited sur tout nom de domaine
.... et pas forcément aussi enclins à faciliter au propriétaire du
domaine de pouvoir enlever cet état.

Quant au clientDeleteProhibited on va dire que cela permet surtout
d'éviter les _grosses_ bourdes du bureau d'enregistrement au niveau
d'une suppression accidentelle, puisque cet état nécessitera alors
obligatoirement deux opérations (une mise à jour pour enlever cet état,
puis la destruction en elle-même), qui ne peuvent pas être cumulées en
une seule opération en EPP.

Bref, il n'y a aucune solution magique. Le cas idéal c'est le bureau
d'enregistrement qui permet facilement à son client d'ajouter ou
d'enlever les états qu'il souhaite (avec un minimum d'explications).
_Dans ce cas de figure_, avoir clientDeleteProhibited et
clientTransferProhibited est une bonne chose (avec le postulat
initial, pas de conséquences négatives) ... mais certainement pas une
protection infaillible, donc on peut aussi vivre sans.

Si votre bureau d'enregistrement ne vous permet pas de contrôler ces
états aisément, cela peut aussi être un élément de choix quant à
poursuivre la prestation avec lui.

A noter que là comme ailleurs, quand on veut vérifier il vaut mieux
regarder directement le whois du registre (whois qui maintenant exhibe les
états EPP, avec quelques modulations, tous les registres n'ayant pas mis
en oeuvre la même version du standard EPP) et pas le whois du bureau
d'enregistrement qui peut montrer des états fantômes ou internes
(cuisine interne du bureau non nécessairement répercutée chez le
registre).

Voilà pour ma tartine post-élections :-)

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

> Voilà pour ma tartine post-élections :-)
>

C'est très bien ainsi (enfin, pas en ce qui concerne les élections).

Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que,
de base, le mail d'alerte pour le renouvellement de domaine est envoyé
aux mails que l'on a pour l'admin et facturation.

Donc en regardant le whois, on a le mail. Ensuite, un peu de social
engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep :
un petit coup de snif et hop, on a le mot de passe. Car personne (à part
mes clients ) n'utilise du pop/smtp sécurisé ou, au moins, le
chiffrement du mot de passe.

Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger
comme protection, non ?

Olivier Masson a écrit :
>
>> Voilà pour ma tartine post-élections :-)
>>
>
> C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
>
> Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que,
> de base, le mail d'alerte pour le renouvellement de domaine est envoyé
> aux mails que l'on a pour l'admin et facturation.
>
> Donc en regardant le whois, on a le mail. Ensuite, un peu de social
> engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep :
> un petit coup de snif et hop, on a le mot de passe. Car personne (à part
> mes clients ) n'utilise du pop/smtp sécurisé ou, au moins, le
> chiffrement du mot de passe.
>
> Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger
> comme protection, non ?

D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick
me corrigera le cas echeant ) aucune obliation en ce sens (envoi
d'email pour confirmation des contacts avant transfert)

Le Tue, 08 May 2007 15:51:25 +0200, Spyou a écrit :
>> Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger
>> comme protection, non ?
>
> D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick
> me corrigera le cas echeant ) aucune obliation en ce sens (envoi
> d'email pour confirmation des contacts avant transfert)

Depuis 2004 et la nouvelle politique de transfert
(<http://www.icann.org/transfers/policy-12jul04.htm>) il est à
la charge exclusive du nouveau bureau de s'assurer d'avoir l'accord des
contacts (administratif ou propriétaire, cf §2.1) et il n'a pas le droit
de lancer un transfert sans cet accord.

Le bureau perdant peut alerter les contacts qu'un transfert a lieu et
demander confirmation, mais n'y est pas tenu via un document spécifique
(<http://www.icann.org/transfers/foa-conf-12jul04.htm>). A noter que
l'accord est le comportement par défaut, sous 5 jours.

Ce désaccord possible des contacts via le bureau actuel est l'une des
neuf causes possibles de rejet. L'absence de réponse est explicitement
interdite comme cause de rejet possible.

A noter que cette nouvelle politique a été mise en place avant
l'utilisation des codes d'authentification partout, et donc l'ensemble
actuellement est plutôt un goubli boulga pas très cohérent.
Mais au moins ca clarifie les voies de résolution des litiges, ca c'est
bien.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Tue, 08 May 2007 12:51:40 +0200, Olivier Masson a écrit :
> Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que,
> de base, le mail d'alerte pour le renouvellement de domaine est envoyé
> aux mails que l'on a pour l'admin et facturation.

Chez la majorité des bureaux oui, probablement. Ce n'est certes pas la
seule façon de faire.

> Donc en regardant le whois, on a le mail. Ensuite, un peu de social
> engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep
> : un petit coup de snif et hop, on a le mot de passe. Car personne (à
> part mes clients ) n'utilise du pop/smtp sécurisé ou, au moins, le
> chiffrement du mot de passe.

Il y a encore plus simple avec un peu de patience : on cherche les
domaines dont les contacts ont des adresses email sur des domaines non
renouvelés, ce qui arrive régulièrement. On redépose après le nom de
domaine en question et on récupère donc le contrôle de toutes les
adresses email et donc le contrôle de tous les domaine ayant des contacts
avec ces adresses email.
Ou on contacte le bureau en disant que les emails répondent pas, et le
bureau va détruire le domaine ... qu'on peut donc récupérer après
(d'autant plus probablement que le bureau met en vente aux enchéres les
domaines).

> Vu ce que peut parfois représenter un nom de domaine, c'est un peu
> léger comme protection, non ?

La sécurité de la majorité des noms de domaine actuellement est
effectivement au niveau de la sécurité des adresses email des contacts,
compte-tenu des choix opérés par la majorité des bureaux. Mais il y a
d'autres façons de faire :-)

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek a écrit :

> Depuis 2004 et la nouvelle politique de transfert
> (<http://www.icann.org/transfers/policy-12jul04.htm>) il est à
> la charge exclusive du nouveau bureau de s'assurer d'avoir l'accord des
> contacts (administratif ou propriétaire, cf §2.1) et il n'a pas le droit
> de lancer un transfert sans cet accord.
>
> Le bureau perdant peut alerter les contacts qu'un transfert a lieu et
> demander confirmation, mais n'y est pas tenu via un document spécifique
> (<http://www.icann.org/transfers/foa-conf-12jul04.htm>). A noter que
> l'accord est le comportement par défaut, sous 5 jours.
>
> Ce désaccord possible des contacts via le bureau actuel est l'une des
> neuf causes possibles de rejet. L'absence de réponse est explicitement
> interdite comme cause de rejet possible.
>

Hum, j'espère avoir très mal compris : je demande le transfert de
hotels.com et si personne ne s'y oppose, on accepte le transfert ?
Non ! Pas à ce point quand-même ! Je pars en vacances 10 jours, je
reviens, j'ai plus mes domaines

Le Wed, 09 May 2007 11:02:04 +0200, Olivier Masson a écrit :
> Hum, j'espère avoir très mal compris : je demande le transfert de
> hotels.com et si personne ne s'y oppose, on accepte le transfert ?

Le nouveau bureau (celui lancant le transfert) doit obtenir l'accord
explicite du propriétaire ou du contact administratif, sans compter qu'il
a besoin du code d'authentification pour lancer la procédure.

Le bureau d'enregistrement actuel (celui perdant le nom de domaine), peut
aussi demander aux contacts, mais là pas besoin d'accord explicite : si
les contacts ne répondent pas, celà équivaut à un accord pour le
transfert.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>