On Tue, Jan 28, 2020, at 11:00, Gould, James wrote:
> JG - You have brought this up before, but the adoption of a BCP draft
> by the WG is certainly applicable.
I remain unconvinced, and would advocate that this draft, if going forward,
is *at best* EXPERIMENTAL, and certainly not BCP.
Again, there are multiple models of transfers out there. No one can say,
and specifically not at the protocol level, that one is flat out better
than another. The fact that the current situation has to be amended regarding
passwords (the whole purpose of the draft) clearly shows the current
"most common" case is far from being perfect.
Hence, whatever is written here can not be a BCP.
And everything related to password storage, complexity, entropy, etc. should
not be in a specification coming out of the REGEXT working group. Coming out of
IETF,
maybe. But just not from this group.
I am just advocating to take all of that into account, instead of taking
one case and declaring this is the only way to do it (while it is obviously
not true on the field), because this is exactly why EPP is so fragmented today.
> The authInfo node was defined from the ground up to be extensible,
> and we should leverage that to put into place better mechanisms than
> current plain text passwords.
>
> JG - An alternative approach is not mutually exclusive and I look
> forward to any proposals that you may have.
I think I gave multiple ideas (which can of all boil down to: let us step back
and think about passwords in general instead of fixing current situation with
workarounds; this is the same problem I have with login-security extension),
but I won't work on those alone if no one
is interested. Yet, they exist, as I am sure others not even written yet.
But, even if they do not exist, this does not give an immediate green light
to what is proposed here. However in order not to rehash things I will stop here
for now, and maybe participate in further discussions when/if the draft is
adopted
by WG which seems plausible.
In its current form however I would clearly voice my concerns against BCP
status.
> JG - Any input from interested parties is welcome. The main question
> is whether other models can be fit into a common practice or whether
> they stand on their own.
At this stage, this is not what interests me, and if concerned parties
do not want to participate here they may have their reasons (starting with not
feeling
to be taken into account, I guess, I do not know I do not speak for anyone).
My concern is just to show that there are multiple ways to operate, that must
have a reason and that should make us think at the protocol level how to handle
all that instead of "patching" the current password situation.
> JG - One goal of enhancing the security of the authorization
> information for transfers is to reduce or remove the dependency on the
> use of RDDS.
This may need to be expressed in the draft then.
> JG - draft-gould-regext-secure-authinfo-transfer focuses on the
> behavior of the info command and response as it relates to verifying
> the authorization information value and disclosing whether the
> authorization information is set in the info response to the sponsoring
> or non-sponsoring registrar. Defining a BCP would help to make things
> more consistent. draft-gould-regext-secure-authinfo-transfer does not
> cover what elements are returned in a full or partial info response.
This may be a little contradictory with the goal of reducing dependency of
RDDS. If the business side of things mandates to send emails to contacts,
and if nothing nowhere is said about replies to domain:info from
non sponsoring registrar, then you are back at basically the current situation.
> My thought is that if the valid authorization information is provided
> by a non-sponsoring registrar that the full info response should be
> returned.
Maybe. I am just saying (observing) that it is not the case today.
Here is a non-scientific sample of responses to domain:info from non sponsoring
registrar with correct authInfo:
- all data but no authInfo, nor any date
- all data but no authInfo
- error code 2201
- all data but no contact IDs
- all data but authInfo value replaced with a placeholder
- error code 2306
- all data, but no expiration date
- and of course, "sometimes" :-) all data including the authInfo
(the problem for a registrar trying to validate a password is the following: on
what
criteria(s) to separate "successful domain:info because good authInfo" from
"successful
domain:info because all of them are successful by default, sponsoring registrar
or not,
valid authInfo or not" <- yes this case exists, and not just once, and again
with
some filtering on what is returned)
You can say they are all violating the specification.
My problem is: even if that is true, it does not change anything on the field,
in real life.
Nothing will change in current responses, and no document, even BCP, will make
registries change behavior, if there are no good reasons/generic
framework/clear push
from registrars that are very silent in this WG/etc.
Maybe at some point, as controversial it might be, it would make sense to start
working
on "epp-2.0" or at least "domain-2.0".
HTH,
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
