On Fri, Jun 21, 2019, at 08:22, Antoin Verschuren wrote:
> We believe the draft draft-ietf-regext-login-security still has an open
> issue from Patrick Meczek where James response should be confirmed, but
I have reviewed past exchanges and I do not think that there is anything open
left:
I remain in disagreement on various points[1] hence I will not formally
approve it, but I won't either block its advancement.
So, "all fine" for me.
Minor in 4.1: "MUST be included in the response based on the following
conditions"
you should probably emphasize that there is an "AND" between the two points,
not an OR.
Probably obvious but since there are other discussions abount unannounced
extensions
it is probably better to be more specific.
[1] Among other things
(they already have been discussed or not worth discussing, so I just mention
them here for archives, not to open the debate):
- I dislike the use of a specific hardcoded string such as LOGIN-SECURITY
(IETF even has a specific RFC about choosing "random" names, which was followed
by various cases, like for the xn-- in IDNs. See RFC 3797/2777 or its use for
IDNs at http://www.ccwhois.org/mailarchive/cctld-discuss/vol05/0096.html)
- the extension mixes different things (new password scheme, letting the client
identify itself better like user-agent in HTTP, letting the server give
back more structured information about both passwords and TLS... this should
be in 3 extensions, not one)
- discussing about TLS versions being insecure or not would probably need
a reference to RFC8446 and draft-ietf-tls-oldversions-deprecate
- as for reporting problems at the TLS stack was there a discussion on why/when
this
should happen at the EPP level instead of directly at the TLS level?
Specifically because there can be setups where the TLS terminations is in front
of the EPP application servers so a server wanting to forbid some connections,
for problems at the TLS level may be technically unable to do it at the EPP
level.
- a lot of things are not defined. For example for ciphers, what is the value
field?
Is that TLS ciphers from IANA repository? something else?
Not defining things like this is easier to bootstrap the extension usage, but
at the
end of the day will make it less interoperable and complicate registrars life.
For insecure TLS versions, what will be the format?
TLS 1.0
TLS_1.0
TLS_1_0
TLSv1.0 like the example given
0x0301
etc.
- the level could have from the get go accepted typical logging levels, so like
info/debug/trace/notice in addition to current warning/error
- there is no discussion if the server SHOULD/MAY/MUST refuse the login (return
code > 2000)
if there is any event at level="error".
- "The client SHOULD NOT decrease the security of a new password by
decreasing the length of the current password." that does not explain how the
server should react then? Allow it always? Deny it? Let it decide per local
policies?
- a mention/discussion of RFC7613 would seem appropriate
- more generally working today on authentication should be based on SASL and
we should open things better and with more extensibility. This extension is just
piggybacking on the current scheme which creates its own range of
interoperatbility
problems.
--
Patrick Mevzek
[email protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
