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

"Patrick Mevzek" <pm@dotandco.com> Tue, 02 July 2019 04:40 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C912008D for <regext@ietfa.amsl.com>; Mon, 1 Jul 2019 21:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=boeKfutn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zW+BMFPM
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZWE7LjAfA-R for <regext@ietfa.amsl.com>; Mon, 1 Jul 2019 21:40:13 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F96612004D for <regext@ietf.org>; Mon, 1 Jul 2019 21:40:13 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6D61C220F4 for <regext@ietf.org>; Tue, 2 Jul 2019 00:40:12 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Tue, 02 Jul 2019 00:40:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=ZZ4N57wrdBg1dYUC9bbQTfEHEu9uQFG mruJBDIag0XE=; b=boeKfutn4aqAFl35d5eLf8ZUjF8v2IIMo0X153gb5QI6eqB yC71/cE/X03WhYtcCgloXN6CM2HbYNElgDjxFeJDu6LpNeNwE51f1NK2BgEndfm/ kBvNlwhU0fIa43HwWR9MFCr+Vq3CGhK1ViPbQDXiPHsdlHZCTqiCwEsUOGNOY8FQ SRfUMKyXPRQWa5te2rjF0gPlQqAMptSTfAEjHKyflpk8j+7IXl4TUbt366uUBU0i AAKltOV+t/QNnIK/X9aC+zdvOAadMltaXA5Qte/TGOzRklNykFzJorAJkTra+m3i ZMeRgVeFqLIx2i0ly+0S8Yee296Mtk92bwD92Nw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=ZZ4N57 wrdBg1dYUC9bbQTfEHEu9uQFGmruJBDIag0XE=; b=zW+BMFPMr3fSbdNmR80dT3 lK2NiqaAe3jWueXlfAvg8KHY4THH0rW01N0UOal5BULfnksM2bXRoY3jyjybI4FK w9AkvPxB2hpc6xp0dNIFg2PxFwB+12gwKJ7cNdK9XidsYGnA+qWNsWSxr14SSk7x zN2V/ECkkeOy/R4OVY/rkYm+oL7cVout+dxgkSbqQWKGEUw3wnFtK+Np38ncGzIN Xyzz4SKj/tWB70FoMII5RHPQr3DHa5LbGx3uGFrXuNkNnluLPb4oiEMV/v40wvAF vAh5j3yezpibJtVf0V2THrZ+iNKM+hDcKu5smCRK4cCMKxZNtIlYbW7QvGtmgQAA ==
X-ME-Sender: <xms:K-AaXVZRxakAdISgS0EEKVOf31hxcRys0PUB7kHMlk5nJfq9mfVeDdCSEYg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdejgdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmseguohht rghnuggtohdrtghomheqnecuffhomhgrihhnpehrvghgvgiguddtuddrtghomhdpsggvlh hofidrrgdqiienucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggtohdr tghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:LOAaXdLpJqKmiLqrY2L6FR5OBihYne8QIjGgMAS-soBeqCkNX8w3vA> <xmx:LOAaXXlLrfy-fLcmrtybBVVrkUIjCNA7v36HIlHk0DAw6iA-CV3CXQ> <xmx:LOAaXc1fkMi_4UEaXh5fyWXb8fXIguF1E0eFkOMhsitYwNdmmlMMdg> <xmx:LOAaXaP1GaFPfcUWZnIj0pFbeDAtVpSpKdnKN2bGoIQ4ZZmTnWhqvw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CBEDBC200A4; Tue, 2 Jul 2019 00:40:11 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1
Mime-Version: 1.0
Message-Id: <bd61b4f8-dd8e-44e0-b14b-05c2045ea853@www.fastmail.com>
In-Reply-To: <62722D2A-6126-4589-BD8C-CF22FA17B68C@verisign.com>
References: <afac0d26-e054-54a3-306b-5ec5a49fd489@switch.ch> <7597ff38-29ba-77e3-e093-524c5cb7123a@switch.ch> <cccbc3cd-1f45-4973-9606-544f1f04425b@www.fastmail.com> <23C64725-1802-46B1-A371-9059F642E10A@verisign.com> <9735244c-3619-46e3-8ce2-f0d6bc8a9bee@www.fastmail.com> <1E28042B-759E-46D5-9D9C-5271255480D6@verisign.com> <99e7fe7e-d98c-4d80-97c8-015ff383b391@www.fastmail.com> <D192A5DB-AB8C-4B0E-90FE-B0B33213D2CD@verisign.com> <8b81134b-28d4-437f-a67f-c7d94eec5e73@www.fastmail.com> <62722D2A-6126-4589-BD8C-CF22FA17B68C@verisign.com>
Date: Mon, 01 Jul 2019 23:40:11 -0500
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/K0x5dGuLRpUI6bfQ9iCoZRB6roc>
Subject: Re: [regext] review of draft-ietf-regext-login-security-03
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2019 04:40:16 -0000

Hi James,

On Wed, Apr 10, 2019, at 12:54, Gould, James wrote:
>  
> I did the exercise of defining the PCRE the matches your password 
> format policy, which can be verified using https://regex101.com. The 
> PCRE is defined below:
> 
> 
> *(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[.,:;!?-])(?!.*(.{2,}).*\1)(?!.*(.)\2)^[\x00-\x7F]{17,33}$*

Thanks to have taken the time to prove me wrong, I bow in front of that,
but maybe you could agree that it is neither easy to write, nor to read,
and that as beautiful as it may be in general, it still can not cover 100% of
cases, because the world is like it is and regular expressions solve many problems
but not all.
So I would still claim that a regex will not be able in all cases to encode
the registry policy on passwords but you can say that it will code for the most
frequent cases/the more important subcases, and additions can be expressed in human
documents, such as it is today, so regex already go a little further than current situation.

> Should the <loginSecPolicy:pw><loginSecPolicy:expression> element be 
> made optional to address a password format policy that a PCRE cannot be 
> created for? 

I do not think anyone follows me there, so you can probably keep it mandatory...
and a registry can publish its regex to be ^.*$ which will accomodate all cases.
 
> If a server cannot define their password format policy using a PCRE, I 
> believe the policy may be too complex and should be re-evaluated. 

Maybe, but that is a business/policy problem not a protocol problem. I would disapprove
any IETF document stating which passwords policies are too complex or not and
need to be re-evaluated. Besides generic discussion on strength based on the
count of possible different values.

> Should the <loginSecPolicy:pw> element support a method to reference an 
> external resource (e.g., url) that defines the password policy 
> information?

That would then be only for human consumption, an EPP client won't be doing
anything  with it, so providing that URL through EPP does not provide any gain
I believe.
 
-- 
  Patrick Mevzek
  pm@dotandco.com