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

"Gould, James" <jgould@verisign.com> Mon, 24 February 2020 13:28 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 7DE353A0B3E; Mon, 24 Feb 2020 05:28:50 -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 4rLbkO47vwTe; Mon, 24 Feb 2020 05:28:47 -0800 (PST)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 204DA3A0B46; Mon, 24 Feb 2020 05:28:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10440; q=dns/txt; s=VRSN; t=1582550927; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kR0nog4og/hCdow9N+/6a0HgrdM2tFQW+wyzwXTguAE=; b=ZBFHvC/OClXT1FQBFbcA97Occf2mRwMEAQf0h/8JuA9V9bYy7qd9BnFy oC+YMGIMkE6SS40ectqWDDPS7TYWinTKHWnCZ1Xpxpvy9Z0nOl9qqRvvd qbfbPNTF++HYxvyhEgvGJ5Err55WlSPj13VAdlddehYpu4y58L/a2rbGq aW+19Wi1BA4ntvzkHaMKWpl4xvXtf9QiPUR/7Hma92ykpuJj5EcC0HU3P X1r2f1vR55qSE4i+ofM+AZUag3rPdVwkYgVcByCs/91N5pbjvAYMO1RJX KGWYlx6XAZrnpyBg/0kCOnUjf5b57Fm/8eUae8VCXGCiPDisOlxO2i5pv Q==;
IronPort-SDR: 3nc0bizQWFLrEqOUhXjWYSiCIh+2KIHZ5k7h3NobM5RODLDchLVRXQFF4Sy1hD/+Pzj+u7QQoX D2WVDpCXi5LS8Vbau/JzezXNCqYoQ62kFOjiA0ar+Mr4M+nLgDirUfdyjpgfnwMl42ZS5pAaAz Kzztx8Vvd0fFPmZw+LuuL/rBa/XrAjwT5LyEmUUUtOBx5bt7JzSXCAiU0Vz4F6nAii6VeyJuDN fgqGsSvdA3hRbC4RuGIitRNeHqbq5kwRuZj16Z79rSxxHT3avP6CY7f2LkS+9PNlPiZit/ppsk eFY=
X-IronPort-AV: E=Sophos;i="5.70,480,1574121600"; d="scan'208";a="816058"
IronPort-PHdr: =?us-ascii?q?9a23=3ACr9mWBdseA/fohLmgQcOhGodlGMj4u6mDksu8p?= =?us-ascii?q?Mizoh2WeGdxc27YxGN2/xhgRfzUJnB7Loc0qyK6vymCDRLvM/JmUtBWaIPfi?= =?us-ascii?q?dNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV?= =?us-ascii?q?3wOgVvO+v6BJPZgdip2OCu4Z3TZBhDiCagbb9oIxi6sArcutMSjId+Jao8yg?= =?us-ascii?q?bFqWZUdupLwm9lOV2ckxHg68mq4ZVt6T5Qu/Uv985BVaX1YaE1RqFGATolLm?= =?us-ascii?q?44+tTluQHMQgWT6HQcVH4WkgdTDAje8B76RJbxvTDkued7xSKXINf5TbEwWT?= =?us-ascii?q?Sl8qdrVBrlgzoJOjIl7G3ajNF7gaRGqxyjuhN/2ZbZboGLOvRjYqPTc9AUSm?= =?us-ascii?q?RAXslNWCJODZixb5cUAOoEIepUs5PwqlkIoBCjBQesHuTvyjpQi3P43KM61P?= =?us-ascii?q?khEQXb0wA4AtkAtG7brNDrO6cJX+y+0a7FzTfMb/NRxDf97JXHfws/of6SR7?= =?us-ascii?q?JwcNHRyUggFwPDlFmftYvlPzaM2+kLrmOV4e1gVee1hG4mrQF8uiavydk2io?= =?us-ascii?q?nInYIVy1/E9SN4wIYzOdK0UlJ0YdmhEJZWqiqUNJN2T9s/T210oio2178LtJ?= =?us-ascii?q?ChcCQXyJkqyQTTZvODfoSQ/x7vSPydLSp6iX55Yr6zmhm//Eu6xuHhVcS4yF?= =?us-ascii?q?hKoTRGn9XQs30A0gbc58uDR/Rm+0qs1yiD2B3S5+xBOk85kavWJpwkz7M+mJ?= =?us-ascii?q?ces1nMEynrk0vslqCWbF8r+u2w5uTiZbXpu4GTOpdvigH7LqQugsu/AfkkMg?= =?us-ascii?q?QWX2iU5+C81Lr78EDkXLtEluA6nanBvp7VJMsXurC1DxVL0ok/7Ba/FS+m3M?= =?us-ascii?q?4CknYaNl5FZgiHj5PvO13UPP/4CvK/j0ytkDdt2f/GIqXsDojRInTZjbvsf7?= =?us-ascii?q?hw51RBxAczw91T/Z1ZB7UZLPL2QEDxtdjYDhEjMwyzxubqENd91owZWWKSBq?= =?us-ascii?q?+WLbjfsUGW6eI1IumMf44VuDn7K/Q/+/Huino5lUcHfaa1xZsXdGy4HvN+Lk?= =?us-ascii?q?qCe3XsmM0BEGcOvgUgTezlk0eNXCVPaHa1WqI8/iw7CJ64AofZXIyth6aB3C?= =?us-ascii?q?ijFJ1Mem9GEkyMEWvvd4icWPcDcj+dItJikjEfULihSpMh2QuwuwDn1rptNv?= =?us-ascii?q?DU9TEAtZL/yNh14PXemgwo9TNuAcSdz3iBT2BqkWMUST86xbp/rlJyylid3q?= =?us-ascii?q?l4n+VUFdhU5/NGUwc6M4fQz/dkBN/uRwLBZNaJSEqmQ9i9ADE+UM4xw9EUb0?= =?us-ascii?q?Z6AdWigQjJ3zC2DL8Ni7yLGJs0/7rd33fvPMZ9xG3L1Kg/gFk6TMtDL2qmhr?= =?us-ascii?q?Rw9wLLHY7Gj12Zl7q2daQbxCPN7nmMzWWQs0BXTA59SqTFUm4DZkvYt9j54V?= =?us-ascii?q?nCT7D9QYggZ0FLwNSYO69Ha9fgpV5BQe/+JNnEJWWrlC34URyB3KmdaIfrcW?= =?us-ascii?q?w11yLYEFUYnhpV+myJY0x2TCSor3/dJDlvCRTib16mub19oX+mTWcxzh3MYk?= =?us-ascii?q?F8gemb4BkQ0LazTO4X0vZMmi4kpi4+VAK/0NXLD9aouQd7fb5dbtV761BCgz?= =?us-ascii?q?GK/zdhN4CtevgxzmUVdB566hvj?=
X-IPAS-Result: =?us-ascii?q?A2HdAgAjz1Ne/zGZrQpiAw4OAQEBAQEHAQERAQQEAQGBe?= =?us-ascii?q?4MVgTEKhAqRF4NulxM8CQEBAQEBAQEBAQcBHxAEAQEChD4Zghs4EwIDAQELA?= =?us-ascii?q?QEBBQEBAQEBBQMBAQEChiAMgjsidi8JOQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQUCCAdNB0cBAR0BAQICASMRRRIBCBgCAhIBAQsHA?= =?us-ascii?q?gQwFRIEAQ0FgyYBglusDXWBMoougQ4qjD6BQj6BOCCCTD6EKQEBCC8KJgECB?= =?us-ascii?q?YJCMoIsBI1ognmfNQMHgjyHUYVNhBqFSYJJfZdojnCBTYYVgRqSSwIEAgQFA?= =?us-ascii?q?hWBaYF7cBVlAYJBCUcYDY5VgzuKGD10DiSMTA8VgQ2BEAEB?=
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; Mon, 24 Feb 2020 08:28:17 -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; Mon, 24 Feb 2020 08:28:17 -0500
From: "Gould, James" <jgould@verisign.com>
To: "barryleiba@computer.org" <barryleiba@computer.org>, "kaduk@mit.edu" <kaduk@mit.edu>
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: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV6xZFBm1OfwwSLU6IpJWlcLWqHQ==
Date: Mon, 24 Feb 2020 13:28:17 +0000
Message-ID: <639F7D2A-A0D7-4DB6-B846-2A75589E4466@verisign.com>
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: <B9BFE1DBD873E44AA9FD068F22B28A08@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/uIONV1tfnI4tmj4RNT6geP8sl5w>
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: Mon, 24 Feb 2020 13:28:51 -0000

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