Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

"Gould, James" <jgould@verisign.com> Tue, 25 February 2020 16:33 UTC

Return-Path: <jgould@verisign.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 161343A105B; Tue, 25 Feb 2020 08:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=verisign.com
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 RSM4bKJYCHKn; Tue, 25 Feb 2020 08:33:39 -0800 (PST)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AB53A1055; Tue, 25 Feb 2020 08:33:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=17108; q=dns/txt; s=VRSN; t=1582648419; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=FAnE4Qrpwj5/UHdheTTWgt0iVJjoUAddsCVAIwK1DvI=; b=HL3Hwu0oP+KWzMxenx2iXJMHOb+uYFLhthoqDjvHYX7c12RVnxkUZZBa cssCYx5EA/Is/6J6344DNK7IiecIuatQQ6hUrIqq+DasgN8aeqB/dj/68 1itbdK1cf3vnh6+1nfzGKZdf6NBGORZaoA6XCq4WtTXNF8HwB0WCQAA5k 7nWC25632usdOE4B3ufOl9Da580uQdYDv1CfbaQDL0CsZHRg0V3ArDnb7 F+gZ/3AMxUQog3mf2yAzbRPp3GRxY+tNr3QRVdZ6iTutyH6PkAUD3t8yh NlDlRt/buALTGeFcrsSvo8gwGKfnAnuBLH/QvxuZ1oslGeen//6IUISeu Q==;
IronPort-SDR: P/vBZzsKdXLSWdEIpDEoKLzMulsqmUcxFei0e86e+jEatSN6z98WsiTa+jafGn/rJITUydR4Wj 2cvzw6NeRrY1Em66SA598aF6rXwsoaiLVfuaGIvG0w5BrxrfmYi2KGYcFZ3W7PTExUkAYz0GVo zn/H1QO4p0yb/mAjPt26xtQ5eQfWdbAEOeojTw6+wiZZ6+HaUF9FykmsRFZ0BaTrKhlcRJu9Tx g//vQhadnWxMINRCWEeF+0LctaA8wcR0u7q39HVfBs65fafedLizNSMFGR46+HeBRBZfwJBlqN PGI=
X-IronPort-AV: E=Sophos;i="5.70,484,1574139600"; d="scan'208";a="750056"
IronPort-PHdr: 9a23:VRjJRRbbo46deg+rPBcfUx//LSx+4OfEezUN459isYplN5qZps29bR7h7PlgxGXEQZ/co6odzbaP7+axAydQvt6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrogjdrM0bjZVtJqsyyBbCv2dFdflRyW50Kl2fmArx6N2t95B56SRQvPwh989EUarkeqkzUKJVAjc7PW0r/cPnrRbMQxeB6XsaSWUWjwFHAxPZ4xHgX5f+qTX1u+xg0ySHJ8L2TLQ0WTO/76d3TRLjlSkKOyIl/GzRl8d9ir9QrhC8qBxl24PaYJ+bOudifq3Tft0aS2hOUchQVyNdDY2zYJACD/YaMuZds4Xxu0EDoBm4CAKxBO3v0DhIhnru0KE00uohFhzG3Ag9EN4WrX/aqM/6NKIMXuCuwqXD0DLOb/FZ2Tf69YjIdg0urOqSXb1ua8rRyFIvFwLKjlWWs4DqIzSV1uEUvmWd8uFuW+Wvi2s9pAFwpDii3tkshZfThoIU0VDE9Cp5wIA0Jd2+VEF3e8KrEJxVtyycKoB4QdsiTnl1tCom0LEKpJy2cSYQxJg6xxPSZeaLfoeM7x77SeqdPS10iG9ndb6jnRq+7Eetx+7mWsWp01tGtiRFncfPu3wR0hHe79KIR/h580i63DuC2R7f5fxFLE0xjqXWL58sz7w1m5cdv0nOHDL5lUPrh6GMbEok4PKn6+H/b7XjoZ+TKpF7hxnlMqQrhsy/GeM4MhUSX2SD+eSzyrnj/UrhTbhXkvM4irTVv5DCK8oUp6G1HxFZ3pw96xmjCDemyswYkWMdI11YYh6HkZLpO0rIIPziEfi/hFGsnC9qx/DAILLhHo3AImXfnLv7YLpw6UBRxBAuwd1f6Z9YEL4MLfbrVk/0rtPYDxs5MwKuw+bgDdVwzoEeWW2IAq+ENKPdrESF5vwxLOmWZY8Vozf9K/cj5/L0kXA5nlodcbGz3ZQLcHC4AuhmI0KBbHrvmNgODHoKvgklQezviV2CTSRfaGivUKIh/js7Ep6pDZ/fRoCxh7yMxDy0EYdMZmBcClGMFWnnd4SfVPgWcy+dPshhkjkcVbi8V48uywuuuBX9y7p9Iere4jcYuo771Nhp++3Tkgk/+iFuD8uH3WGNU3h4nmIWSD8q0qBzuFZ9xUmM0admjP1YCcVf5/dOUgc1NJ7cyfV2C8vsVQ3dY9eJUlemQsmmADwqT9I+3cMOY0hnF9WllBDD0DKgA6UJmLyTGJw07qXc0mDwJ8lj0HbG27Isj1g4TctTO22qnKl/9xLcB4TRiUWWi76qdbgA3C7K7GqD13SBvE5GXw9/TaXIRnEfaVXKrdT3/E/CSKWuCbt0ejdGnISBI6dXafXsjEkASfv+cpyKYGu9hmSYABeUgL6AcdyuMy8X1T/HGUwJkgoa1X2BMBAjGiq75WXEA3YmQVjmeVn99eR/onqTRUgx1xyWYlcn0KC6rE07n/uZHrk82a8AtGNpiTxxEU33l4bUBN2dowZJYqhGYMg871EB3mXc4V8udqe8Jrxv0wZNOz98uFnjgk16
X-IPAS-Result: A2FZAAAMTFVe/zGZrQpiAw4MAQEBAQEBAQEBAwEBAQERAQEBAgIBAQEBgXuDFYExCoQKYZA6g26XEzwJAQEBAQEBAQEBBwEfEAQBAQKEPgIXggw4EwIDAQELAQEBBQEBAQEBBQMBAQEChiAMgjsidi8JOQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCCAdNB0cBAR4BBSMRRRACAQgYAgISAQELBwICAjAVEAIEAQ0FgyYBsR2BMoo9gQ4qjD6BQj6BOCCBTn4+hCMGAQEILwomAQIFB4I7MoIsBI1oM4JGhhSZIQMHgjyHUYVNhBqFSYJJfZdojnCBTYYVgRqSSwIEAgQFAhWBaYF7cBU7KgGCQQlHGA2OVYM7ihg9dA4kjBIBDxWBDYEQAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 25 Feb 2020 11:33:04 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Tue, 25 Feb 2020 11:33:04 -0500
From: "Gould, James" <jgould@verisign.com>
To: "kaduk@mit.edu" <kaduk@mit.edu>, "barryleiba@computer.org" <barryleiba@computer.org>
CC: "draft-ietf-regext-login-security@ietf.org" <draft-ietf-regext-login-security@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV6xZFBm1OfwwSLU6IpJWlcLWqHagq0AyAgAB6pACAANHKAA==
Date: Tue, 25 Feb 2020 16:33:04 +0000
Message-ID: <C10706F0-12A7-4B46-8B7B-505FD22BD039@verisign.com>
References: <639F7D2A-A0D7-4DB6-B846-2A75589E4466@verisign.com> <CALaySJKiGEJgwurOfEtB_drjF+miiu-SWUvwXGj+i348GBg9jA@mail.gmail.com> <20200224230244.GB5814@kduck.mit.edu>
In-Reply-To: <20200224230244.GB5814@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <20B02C1E3FCDEC42B1E09D2AFB0133BF@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/WI-mPRYICOfSmbFuYPXFvLkZxg0>
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
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, 25 Feb 2020 16:33:42 -0000

Ben,

I believe I found the topic and the proposed text associated with identifying the nature of the need, which is outlined below.  I propose adding the sentence " EPP [RFC 5730] includes a maximum password length of 16 characters that inhibits implementing stronger password security policies with higher entropy." as the second sentence of the introduction.  This can be added to draft-ietf-regext-login-security-10.  Do you agree with this change?  Are there any other changes that are needed prior to the posting of draft-ietf-regext-login-security-10?

    Thanks for pointing to the list discussion of potential alternative
    authentication approaches, and I'll see if I can make time to write
    something down.  I'm not opposed to publishing an evolutionary improvement
    while revolutionary changes are immature, but I do think that the document
    should be more explicit about the nature of the need.  Yes, artificial
    password-length limitations are bad and I'm happy to see this work to
    remove them from EPP, but are there particular security deployment
    considerations driving this, such as a desire to support memorable
    passphrases that contain sufficent entropy?  From a purely
    information-theoretic perspective, if we limit ourselves to the ASCII
    alphabet from 0x20 to 0x7e, 16 charcters gives roughly 104 bits of entropy
    available, which is not catastrophically bad; in combination with the
    prerequirement for TLS client-certificate authentication, a server could
    block or rate-limit brute-force guessing attacks and achieve a level of
    security that is reasonable for many if not most web-available services
    today.  Even if the perceived need is just "artificial limitations on
    password length are detrimental to future evolution in security practice"
    (which seems unlikely to me based on my bayesian prior), it seems worth
    saying.  I suspect that there's more motivation in play, and would like to
    better understand it.
 
JG2 - The only deployment consideration is being able to set passwords beyond the 16 character limit of RFC 5730 for the critical domain name registry systems.  Yes, there is multi-factor authentication with EPP (user name/password and client certificate, and optionally client IP address), but there is the operational need to enhance the security of the passwords with longer lengths and higher entropy (e.g., at least 128 bits).  Are you looking for a sentence being added to the introduction that identifies the problem more explicitly, such as:
 
EPP [RFC 5730] includes a maximum password length of 16 characters that inhibits implementing stronger password security policies with higher entropy.

-- 
 
JG



James Gould
Distinguished Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 2/24/20, 6:02 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    This text regarding internationalization/normalization works for me.
    
    Looking at the diff from -07 to -09, we seem in pretty good shape overall;
    were we going to add a note to abstract and/or introduction about "this
    extension allows for the use of strong passwords with EPP"?  (I think Jim
    had proposed actual text at some point that's better than my paraphrased
    version here.)
    
    -Ben
    
    On Mon, Feb 24, 2020 at 07:43:47AM -0800, Barry Leiba wrote:
    > Great; thanks, Jim.  Ben, are you OK with this now?
    > 
    > Barry
    > 
    > On Mon, Feb 24, 2020 at 5:28 AM Gould, James <jgould@verisign.com> wrote:
    > >
    > > Barry & Ben,
    > >
    > > Thanks for the detailed discussion.  I will change the "recommended" to the normative "RECOMMENDED" and change the PRECIS sentence to match Ben's proposal.  The end result will be:
    > >
    > > It is RECOMMENDED that the plain text password in the <loginSec:pw> and <loginSec:newPw> elements use printable ASCII characters #x20 (space) - #x7E (~), with high entropy, such as 128 bits. If non-ASCII characters are supported with the plain text password, then use a standard for passwords with international characters; the OpaqueString PRECIS profile in [RFC8265] is recommended in the absence of other considerations.
    > >
    > > I'll include this change in the posting of draft-ietf-regext-login-security-09.
    > >
    > > Thanks,
    > >
    > > --
    > >
    > > JG
    > >
    > >
    > >
    > > James Gould
    > > Distinguished Engineer
    > > jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>
    > >
    > > 703-948-3271
    > > 12061 Bluemont Way
    > > Reston, VA 20190
    > >
    > > Verisign.com <http://verisigninc.com/>
    > >
    > > On 2/22/20, 6:15 PM, "Barry Leiba" <barryleiba@computer.org> wrote:
    > >
    > >     Thanks, Ben; this helps a lot.
    > >
    > >     Jim, are you good with Ben's suggestion or a variation of that?  It's
    > >     just a small update to what you have, and makes it clearer that if you
    > >     need I18N, PRECIS is the weay to do it.
    > >
    > >     Barry
    > >
    > >     On Fri, Feb 21, 2020 at 10:08 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
    > >     >
    > >     > Hi Barry,
    > >     >
    > >     > On Sat, Feb 15, 2020 at 12:12:29AM -0500, Barry Leiba wrote:
    > >     > > Hi, all...
    > >     > >
    > >     > > I'm sorry if I'm not completely clear about where the discussion is,
    > >     > > but what Jim's mail system does to the quoting is horrendous (as is
    > >     > > the case with most HTML-based mail systems), and I can't easily follow
    > >     > > the thread.
    > >     >
    > >     > I sympathize; I find that with some regularity I end up saving the
    > >     > text/html component to a file and opening it in a browser in order to have
    > >     > a chance of figuring out what's going on.
    > >     >
    > >     > > So I'm just picking up this recent bit from Ben:
    > >     > >
    > >     > > > I think it would probably be helpful for the responsible AD to chime in; my
    > >     > > > understanding is still that the PRECIS profiles are to be used as part of a
    > >     > > > protocol as opposed to part of a deployment, and that allowing for
    > >     > > > different rules to be used in different sites is risky.  I understand that
    > >     > > > there's the extra context here of the potential for preexisting deployments
    > >     > > > that started using non-ASCII passwords in the absence of any guidance from
    > >     > > > the IETF on how to do so, and we have to consider whether what we do will
    > >     > > > break them, and so hearing from someone versed in the matter who has
    > >     > > > thought about this particular case would help assuage my concerns.  One
    > >     > > > possible route (given that, as I understand it, a lot of EPP deployments
    > >     > > > involve exchange of configuration and deployment information between peers
    > >     > > > out of band) would be to say that the PRECIS profile is used as a default
    > >     > > > in the absence of other configuration knowledge for a given deployment,
    > >     > > > though I acknowledge that this is not without flaws.
    > >     > >
    > >     > > I had discussed the PRECIS issue with Jim, which is what resulted in this text:
    > >     > >
    > >     > >    It is recommended that the plain text password in the <loginSec:pw>
    > >     > >    and <loginSec:newPw> elements use printable ASCII characters #x20
    > >     > >    (space) - #x7E (~), with high entropy, such as 128 bits.  If non-
    > >     > >    ASCII characters are supported with the plain text password, then use
    > >     > >    a standard for passwords with international characters, such as the
    > >     > >    OpaqueString PRECIS profile in [RFC8265].
    > >     > >
    > >     > > I think that's adequate, given that (1) we really are expecting that
    > >     > > almost all passwords out there are ASCII, and we're recommending
    > >     > > keeping it that way, (2) we need to allow, but discourage, non-ASCII
    > >     > > UTF-8 passwords for the (expectedly rare) cases where they might be
    > >     > > used, and (3) these are stored passwords that are passed around,
    > >     > > rather than passwords entered by users and subject to issues created
    > >     > > by different input mechanisms and effects on eyeballs.
    > >     > >
    > >     > > I can see that we might want to change "recommended" to "RECOMMENDED",
    > >     > > and I don't object to that (Jim?).  Beyond that, I'm not sure where
    > >     > > you're going with "PRECIS profiles are to be used as part of a
    > >     > > protocol as opposed to part of a deployment."  It's really both,
    > >     > > depending upon the situation.  In this case, it's saying that if your
    > >     > > server supports non-ASCII passwords, you'd better use the OpaqueString
    > >     > > profile to handle them.  If your server doesn't (it supports only
    > >     >
    > >     > I'm much happier with your prose description here than the snippet quoted
    > >     > from the document -- what's in the document now seems to be weaker than
    > >     > what you say ("pick a standard; PRECIS is a standard" vs "you should use
    > >     > PRECIS, though here's an out if you can't for some reason").
    > >     >
    > >     > My primary concern here is that the client and server need to know to use
    > >     > the same standard (whatever it is).  Making this RFC say flatly "use
    > >     > PRECIS" is IMO the easiest way to do that, though given how much other
    > >     > stuff in EPP has to be set by out-of-band configuration I won't raise a
    > >     > fuss if this ends up being another one.  If it does need to be known out of
    > >     > band, though, my preference is always for that need to be stated in the
    > >     > RFC.
    > >     >
    > >     > > ASCII passwords), we're good.  From a PRECIS point of view, I don't
    > >     > > see more that needs to be done with this.
    > >     > >
    > >     > > I think a large part of the point of the text that Jim added is an
    > >     > > acknowledgement that in the common case of ASCII-only passwords, we
    > >     > > don't have to worry about normalization/canonicalization of password
    > >     > > strings at all, and just doing straight byte-string comparisons works.
    > >     > > And the OpaqueString profile is there for cases where it's needed.
    > >     > >
    > >     > > Now, it's certainly true that if a server *supports* non-ASCII
    > >     > > passwords, then *all* password processing on that server has to use
    > >     > > the OpaqueString profile, even if there are not any actual non-ASCII
    > >     > > passwords present... just in case one might show up.  And I think the
    > >     > > text does say that.
    > >     >
    > >     > (repeating myself, but I think the text says "all password processing on
    > >     > that server has to use the chosen standard for non-ASCII passwords" [which
    > >     > is not necessarily the OpaqueString PRECIS profile])
    > >     >
    > >     > > Is there something in this discussion that I'm missing that I need to
    > >     > > address?  Is there specific text you might suggest?  Are there other
    > >     > > issues beyond this one that are still open?  How close are we to
    > >     > > resolving this?
    > >     >
    > >     > I think just adding the extra background and your sense of what the text is
    > >     > trying to convey has been a big help.  I would suggest rewording to:
    > >     >
    > >     >   [...].  If non-
    > >     >   ASCII characters are supported with the plain text password, then use
    > >     >   a standard for passwords with international characters; the
    > >     >   OpaqueString PRECIS profile in [RFC8265] is recommended in the absence of
    > >     >   other considerations.
    > >     >
    > >     > Your explanation suffices such that I will not require this change to clear
    > >     > my Discuss, though.
    > >     >
    > >     > -Ben
    > >
    > >