Re: [regext] review of draft-ietf-regext-login-security-03

"Patrick Mevzek" <> Tue, 09 April 2019 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEBB5120912 for <>; Tue, 9 Apr 2019 10:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=5Djj74jY; dkim=pass (2048-bit key) header.b=OCsJeljA
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XMIR7B19icvW for <>; Tue, 9 Apr 2019 10:49:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF2081208FC for <>; Tue, 9 Apr 2019 10:49:45 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id E1E9C2660D for <>; Tue, 9 Apr 2019 13:49:44 -0400 (EDT)
Received: from imap1 ([]) by compute3.internal (MEProxy); Tue, 09 Apr 2019 13:49:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=4sQKF dqHSHJZjHpDFOE7UP6Gv0iQfD8IP+vJmRAbTwI=; b=5Djj74jYcQpmCI1OoDCZi B0B8qeaInk7yPX+cSFrrHdyr08aVRsa987TPsIjNEilcbn3ywftTyIgDcFcMFuig 83XOvlSxLNo7DRfFLydqbmJvULNieIjpE9zmnLUTeLbGrKz/ffBBWvkQsEnSfu2J GcgRg4msDZEh2YoL5iFtlx/mo1hmi5dlv9TWo+ZlAzHREc5j35qm4l6gFPe8/mCK eWynMEXKVf3ymPqAOy1BuYVFgeyaJ/bp5nW7+O37M5sy2amq++BT3VtbjghedDd6 plMEF4ZBcQLELPT5pv36wq95xJFQZN9D03/uULrb/9nUs4+UNAbVb4Q7sFG17u/a g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4sQKFdqHSHJZjHpDFOE7UP6Gv0iQfD8IP+vJmRAbT wI=; b=OCsJeljAMv8+TIqwzL4rO0SkL4H+JOBTyU+h+h4dWnDCrfFvwpy7Xc3+Y IXmZC4dT7zgGnGutwHir0snQnvKQocynH5/haZg4878I4UPaYbQqBl8V55XY7pY6 8+9xwdnSRmfPZ8y+VF+J0jlrcgiFebtIRJyvsyC+tUZ1U1A2WooGPPDSQCdk6dbN sjtGcWSJJroeAS3RZCJz8PNDXtOWRMryii2+ADtBpOnAhgtNJoT7FrJTPuLHaO5t KKTCGr018xFbka712zgh5yezvhU7pvgMRlaYlNIKyhI2tOYHb+V65vDg7ZBVIKkc 5MtPB6yCug4FQS+n5l+uzNqK/oLaA==
X-ME-Sender: <xms:ONusXKLiMrq5NBx_unGQTis9yspuJADg4QmIL67nm_kRdi3AbkRzmWNngRs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmsegu ohhtrghnuggtohdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughoth grnhgutghordgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:ONusXPhzYPxC4dlYH4c0k1i-qZWV-_uDP0HoxjUE4L_IQC8BYUSbuQ> <xmx:ONusXENBVNgV9LaxNJqZb7DFtCqIpecVFuSGid4qe66UmOsgKYiVfQ> <xmx:ONusXKq9wJtrzMip6PgI-85uz1QNcOx2NcwBuf3tNiucxLIeigDyqQ> <xmx:ONusXNHn8OiJ_VU7CVjoKTBNV1EeHYr2jhoxzIvFeMlqvRA3nKkjMA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7B01BD48AF; Tue, 9 Apr 2019 13:49:44 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 66173168
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Tue, 09 Apr 2019 13:49:44 -0400
From: "Patrick Mevzek" <>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [regext] review of draft-ietf-regext-login-security-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Apr 2019 17:49:52 -0000

On Tue, Mar 26, 2019, at 12:56, Martin Casanova wrote:
> I know that you have foreseen draft-gould-regext-login-security-policy 
> to query about password complexity but I think for convenience of the 
> registrar it would still be nice to somehow include the password 
> requirement in the response even if it is redundant. Otherwise one has 
> to implement draft-gould-regext-login-security-policy at the same time 
> or communicate the requirement out of band.
>  maybe like that
>    S:        <loginSec:event
>    S:          type="newPW"
>    S:          value="expression: 
> (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) 
> (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$"
>    S:          level="error">
>    S:          New password does not meet complexity requirements
>    S:        </loginSec:event>
> Page 10:
>    S:    <result code="2200">
>    S:      <msg>Authentication error</msg>

It may be nice to try giving back all the requirements... except that you can
not always express all of them with a regular expression for once, and because
there are different flavors of regular expressions for another reason,
two points I already raised on the "policy" extension.

Some registries may have requirements like: at least one letter and at least one
digit and at least one "special" character.
While this may still be done by a regex, it will not be nice (as you need to consider at the same time the range of characters allowed and the constraints on length), and yet there may
be even harder cases, like "no sequence of repeating characters" 
or like "at least 2 "special" character, but not twice the same one".

Aside, there is RFC 7613 "Preparation, Enforcement, and Comparison of Internationalized Strings
                  Representing Usernames and Passwords" and it may be a good idea to reference it or derive from it. Note specifically sections 3.5 and 4.2.2 (that touches the other point raised about handling spaces, etc.)

And I do not even touch things like:
- checking if the password does not contain a known word for some definition of word in some dictionaries
- checking if the password does not match any given leaked passwords (why not? some websites are already adding in their signup/login process a check if the password is among the list of leaked ones)
- not reusing one of the X previously used password, or one of the previous passwords slightly changed like reversed or appended with 1, etc.

Also, related, I would be interested into works that goes into the direction of not having to exchange the password in the clear at all (even if we are inside TLS), because the server does not need to have the client to send it, just to make sure it can prove it has it, and there are various mechanims existing for that (but they may be complicated to port to EPP as they may need further exchanges besides our current greeting/login).
Like SRP and the example of RFC5054 "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".

Or at least, like I suggested on the policy extension, but that was not meant with a lot of enthusiasm, to implement SASL instead of the current purely login+password, so that at least other methods of authentication could be plugged in.

  Patrick Mevzek