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

"Gould, James" <jgould@verisign.com> Tue, 18 February 2020 13:27 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 78BED120013; Tue, 18 Feb 2020 05:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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 f4a--5UrQGBw; Tue, 18 Feb 2020 05:27:16 -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 21110120115; Tue, 18 Feb 2020 05:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6910; q=dns/txt; s=VRSN; t=1582032436; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=AvSlpSas7ovY0/ednDNAupsWCplTQJ19efUFDvP/oAU=; b=oOAkJe6Rp9ZGmQpR6gcN7LlKi+bREu87MjFTo8/y44gdUNsOX2QIx+2m Q7sGh7ERJ1qdyE+E6igW7j65Gg7d6vZHfgRWo+gdzKYunHZYcqDkPkoI+ cgPVEp6jfBjktcNoz0z5UQZIyq5N7uDO+0QawmBP6xM5BsQQWHbCSd5Hm XDxivPrEe6A4D4iP0f6mGxHg5BsgnzQKvOIHSPLidI7f1379dCejGa7Se yhjYseQpi8iyDzGPf8YNFTquwkluHpcHwZkCRgWj8ndAUhNxdxaK76ohu yTtkPNHFLBikYCi+43ODNA9xTuAkydGmKSf7wePN1MbSueuPRZW5AEWJ5 g==;
IronPort-SDR: epnnqwjDASR+7yau6zEX8viuvCpINIzMIDh5tw1gYdCniBHbjjc4o3l0fwunpxg0OhQ98WktCr CBetJdR5ZCKHlMXHAz9hy9XZXb7NPgT/RlCNBePo/zs93cHHY2m9Egi+E4CsLeMKEzlQilXUOv D6pP0uNEZ+S4f1Pu80R5oNpCldsGOk8q+HlUrs/bPeyy3FmqpjqDV4OdBqnS4tUPwiYjX/bvh7 eWEBHJ1NqadyMnS8YZFN8Yp9C9JI+G797IXWodt2tEPARpGTvY+VXxP3M6DzFsIdB3sGcg6GnG gl8=
X-IronPort-AV: E=Sophos;i="5.70,456,1574121600"; d="scan'208";a="768436"
IronPort-PHdr: =?us-ascii?q?9a23=3AJI1xEBbznKCJ6nHy25Sp84r/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZps29bR7h7PlgxGXEQZ/co6odzbaP7+a/CSddu96oizMrTt9lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrogjdrMsbjIhtJqsx1B?= =?us-ascii?q?fCv2dFdflRyW50Kl2fmArx6N2t95B56SRQvPwh989EUarkeqkzUKJVAjc7PW?= =?us-ascii?q?0r/cPnrRbMQxeB6XsaSWUWjwFHAxPZ4xHgX5f+qTX1u+xg0ySHJ8L2TLQ0WT?= =?us-ascii?q?O/76d3TRLjlSkKOyIl/GzRl8d9ir9QrhC8qBxl24PaYJ+bOudifq3Tft0aS2?= =?us-ascii?q?hOUchQVyNdDY2zYJACD/YaMuZds4Xxu0EDoBm4CAKxBO3v0DhIhnru0KE00u?= =?us-ascii?q?ohFhzG3Ag9EN4WrX/aqM/6NKIMXuCuwqXD0DLOb/FZ2Tf69YjIdg0urOqSXb?= =?us-ascii?q?1ua8rRyFIvFwLKjlWWs4DqIzSV1uEUvmWd8uFuW+Wvi2s9pAFwpDii3tkshZ?= =?us-ascii?q?fThoIU0VDE9Cp5wIA0Jd2+VEF3e8KrEJxVtyycKoB4QdsiTnl1tCom0LEKpJ?= =?us-ascii?q?y2cSYQxJg6xxPSZeaLfoeM7x77SeqdPS10iG9ndb6jnRq+7Eetx+7mWsWp01?= =?us-ascii?q?tGtiRFncfPu3wR0hHe79KIR/h580i63DuC2R7f5fxFLE0xjqXWL58sz7w1m5?= =?us-ascii?q?cdv0nOHDL5lUPrh6GMbEok4PKn6+H/b7XjoZ+TKpF7hxnlMqQrhsy/GeM4Mh?= =?us-ascii?q?USX2SD+eSzyrnj/UrhTbhXkvM4irTVv5DCK8oUp6G1HxFZ3pw96xmjCDemys?= =?us-ascii?q?wYkWMdI11YYh6HkZLpO0rIIPziEfi/hFGsnC9qx/DAILLhHo3AImXfnLv7YL?= =?us-ascii?q?pw6UBRxBAuwd1f6Z9YEL4MLfbrVk/0rtPYDxs5MwKuw+bgDdVwzoEeWW2IAq?= =?us-ascii?q?+ENKPdrESF5vwxLOmWZY8Vozf9K/cj5/L0kXA5nlodcbGz3ZQLcHC4AuhmI0?= =?us-ascii?q?KBbHX3mNgBC30Kvwo6TOP0iV2NSiRcam2uUKI74zE7EJ+mDZvdSYC3mrCB2z?= =?us-ascii?q?27HpJObGBcFl+MCWvod5mDW/oUayKdONJukiEHVbW6To8h1A2uuBXkxLV6M+?= =?us-ascii?q?re4jcYuo771Nhp++3Tkgk/+iFuD8uH3WGNU3h4nmIWSD8q0qBzuFZ9xUmM0a?= =?us-ascii?q?dmjP1YCcVf5/dOUgc1NJ7cyfV2C8vsVQ3dY9eJUlemQsmmADwqT9I+3cMOY0?= =?us-ascii?q?hnF9WllBDD0DKgA6UJmLyTGJw07qXc0mDwJ8lj0HbG27Isj1g4TctTO22qnK?= =?us-ascii?q?l/9xLcB4TRiUWWi76qdbgA3C7K7GqD13SBvE5GXw9/TaXIRnEfaVXKrdT3/E?= =?us-ascii?q?/CSKWuCbt0ejdGnISII7FQe9nkjF9PbPzkPczDf2+r3WCqClzAkrmFdpD7f2?= =?us-ascii?q?gc1iz1A08Bix0P8GzAMhIxUGPp6WHXACFtPVfufwXh/fQ04Ce4R0MpzCmPbl?= =?us-ascii?q?En2raorE07n/uZHrk82a8AtGNpiTxxEU33l4bUBN2dowZJYqhGYMg871EB3m?= =?us-ascii?q?Xc4V8udqe8Jrxv0wZNOz98uFnjgk16?=
X-IPAS-Result: =?us-ascii?q?A2FrDACU5Ute/zGZrQpjAw4OAQEBAQEHAQERAQQEAQGBe?= =?us-ascii?q?wKDE4ExCoQKkSKDboF4k1qBPjwJAQEBAQEBAQEBBwEfEAQBAQKEPgIXghE7A?= =?us-ascii?q?w0CAwEBCwEBAQUBAQEBAQUDAQEBAoYgDII7InkvCTkBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHAQEeAQQBIxFFEAIBCBoCE?= =?us-ascii?q?gEBCwcCAgIwFRACBAENBYMmAYJbrFyBMop1gQ4qjD6BQj6BOCCCTD6EKQEBC?= =?us-ascii?q?C8KJgECBYJBgl4EjWSCeZ8tAweCO4dPiWGFRYNGl2CObYdfgRiRZWICBAIEB?= =?us-ascii?q?QIVgXwDgWVwFWUBgkEJRxgNjlWDO4oYO3QOJI4aDxWBDYEQAQE?=
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, 18 Feb 2020 08:26:29 -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, 18 Feb 2020 08:26:29 -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: [EXTERNAL] Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV0jFdashv30ELO0+bzrNuu7jhjaf6T++AgBTqLICADPJdgIAE7WKA
Date: Tue, 18 Feb 2020 13:26:29 +0000
Message-ID: <0BB3B45D-8D7F-4B59-A82E-684620872514@verisign.com>
References: <157974662537.12206.13846873427945988950.idtracker@ietfa.amsl.com> <97D81809-84A7-48ED-8B92-9FC99B585DAA@verisign.com> <20200123210836.GP80030@kduck.mit.edu> <1AFA5304-FCC2-4915-B228-1A699E5237A4@verisign.com> <20200206232955.GE14382@kduck.mit.edu> <CALaySJJ1JU41xmcbYC3e6ah43zRGSSB0b+ccYJxVWHVtc0_Zbw@mail.gmail.com>
In-Reply-To: <CALaySJJ1JU41xmcbYC3e6ah43zRGSSB0b+ccYJxVWHVtc0_Zbw@mail.gmail.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: <579DDE22D6481D44A41E31BD5CEF79F9@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/hsKxW5VkdzslR2C8F0skzBzX2dw>
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, 18 Feb 2020 13:27:19 -0000

Barry,

I have no issue with changing "recommended" to "RECOMMENDED" in:

       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].

This will be included in draft-ietf-regext-login-security-09 assuming there are no additional changes needed to address this final DISCUSS item.

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/15/20, 12:12 AM, "Barry Leiba" <barryleiba@computer.org> 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.
    
    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
    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.
    
    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?
    
    Barry