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

"Gould, James" <jgould@verisign.com> Thu, 23 January 2020 21:29 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 14F4E1200F1; Thu, 23 Jan 2020 13:29:59 -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 Q_z7INcyLVw1; Thu, 23 Jan 2020 13:29:56 -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 4278C120077; Thu, 23 Jan 2020 13:29:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8984; q=dns/txt; s=VRSN; t=1579814996; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=1eAdsiKchembL6IXIcWHEchX3fXT9b0wtYeojMdZkYo=; b=kwo+gssG/WAvZIeb1dolP77jwCVXO3rzpJGyJq8BiBMXDQv7rUvoZoaD xVClXgIN0kgUTUkmMBRuaWdJwb+yUDzpXWALeu6HqFA3VvQ5o1IHmSAHZ eGPI8rSYjyjjDKQ07EFgkuHGeCATgMxhepT/hFasbExG/+QWV5tSPJ4Vw fM190vz+nbixCIrJNy3XbK5eN/8WZ96Zgh8pvYoKwA/xskH8CNZ1oWCzo XNrv/+4UZn36UNEKLf7/AEj+7M6LWGWwBpuc7jV4xW3Aov5oBmGuHMeZa CmvryMvEGykrljOz2x9BXwo6FOjPJE4cL2TVW3XcbV50McAUWSVJmettZ w==;
IronPort-SDR: MIaPxWvjB/xU+Fmh8t0seDf/Q4rKO9VOp9wlh8WZ8m/7lHERzc3sCLH1XvCvBYiZfA2NUGfIOF hKAnlZeyw+IJX5NCezIN6AOuaczyQYa5CvBxPVZWTUeTxPPAf895L6KdPiAiRGJ1RbMH0NdY5p /tJYSbjSoc9z5kdPSrKAwOgI6xQwyCsJgSDmy8c40nkqsUJLhdflZOVCT9221Iw+GQtYN80uYr C3bbpHKpXQc7HbH0f1YV1KHJKhdZEVJPfyne07nFdGgT9gdAKH3OKkXbTh0+PHcXnOx4awETml 17s=
X-IronPort-AV: E=Sophos;i="5.70,355,1574121600"; d="scan'208";a="562771"
IronPort-PHdr: =?us-ascii?q?9a23=3ANvAkbhCqf6oukZVIWu6mUyQJP3N1i/DPJgcQr6?= =?us-ascii?q?AfoPdwSP34pcuwAkXT6L1XgUPTWs2DsrQY0raQ6fqrCDZIoc7Y9ixbK9oUD1?= =?us-ascii?q?5NoP5VtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBk?= =?us-ascii?q?e3blItdaz6FYHIksu4yf259YHNbAVUnjq9Zq55IAmroQnLucQanIRvJrwvxh?= =?us-ascii?q?fXrXdFf/pazn5sKV6Pghrw/Mi98INt/ihKp/4t68tMWrjmcqolSrBVEC4oOH?= =?us-ascii?q?0v6s3xshnDQwqP5n8CXWgTjxFFHQvL4gzkU5noqif1ufZz1yecPc3tULA7Qi?= =?us-ascii?q?+i4LtxSB/pkygIKTg0+3zKh8NqjaJbpBWhpwFjw4PRfYqYOuZycr/bcNgHXm?= =?us-ascii?q?dKQNpfWDJdDYO9d4sPDvQOPeBEr4nmulACqQKyCRSwCO/zzzNFgGL9068n3O?= =?us-ascii?q?Q7CQzI3BIuEc8SsHrar9v1OqUdXu60zKbUwjvMYOhb2Svm54jNbhwtveuBUL?= =?us-ascii?q?B2fMHMyUcvDQTFjlCIpIDrPj2V0fkNs2yG4OZ4SOmhj3QoqwRvrTi0yMsnl4?= =?us-ascii?q?7EhoAaylDD6CV5xJs6KMamSEFle96kEYBQtyCVN4twWM8tX2ZouCMjx7AApJ?= =?us-ascii?q?W1ci8KyJE9yB7ebfyKa5aI7Qz5VOaQOjd4hX1leLS+hxa07Ues0PHzVs6x0F?= =?us-ascii?q?pSoCtInMPAtncX1xzc8sSHS+Vy/luv2TqV0ADT8O5ELEYpnqTYM54s2qM8mo?= =?us-ascii?q?YJvUjeHCL7ll/6gLKWe0gq4OSl5ODqbq37qpOALYN4lwPzPrg0lsCiDuk1MR?= =?us-ascii?q?ICU3WY9Oik2r3s4070TKlPg/AziKbUs5TXKt8eq6O3HQNaz4cu5hOkADqi0d?= =?us-ascii?q?kVn3wKIVxLdR+FkofkPUzFLuriAvelmVuslS9mx/XBPrL8HJrANmPDkLL9fb?= =?us-ascii?q?Zl7E5c1RYzwchf551KDrEBJ+r+V1LtutLAExM2MxS6zenmB9lhyI8SQ3yPDb?= =?us-ascii?q?OeMKPIqV+E/PggLPSWaI8Lojb9MP4l6+Tygn8+nF8RZaip3Z0JZ3CkBvlqPl?= =?us-ascii?q?mVbWDxjtoDH2oGpBcyQezkhVGYXjNeY26+X6cm6TE6DIKmA53DRoeogLGZ3i?= =?us-ascii?q?e7EZpWZn1CCl+RCnroaZuLW+0NaCKJI89hnToEWaK9RI8m0BGirBX6xKZ/Lu?= =?us-ascii?q?rI5i0Ysoru28Jv6O3Wix4y8Tp0D8We02GKUWF5hW0ISCUt3KBjpExy0FaD0a?= =?us-ascii?q?xij/xWENxZ/+lJXRsiNZ7A0+x6DMj/WgPfcdeSR1arWdSmDi8tTtI/2dMOZF?= =?us-ascii?q?x9G9q6hBDZwyWqG6MVl6CMBJEs763cxWL+J8hhy3rf1akukUUmQsVWOW28mK?= =?us-ascii?q?F/+BbcBoHVk0mAk6aqcqsc3C/L9Gua1mqBol1XUBNqUaXEQXAeZlDbrdXn6U?= =?us-ascii?q?PeQb+iE7MnMhFOycSaMKtFdsXpjUlaRPfkINneYWKwlHmuChuT3LyMYovqe2?= =?us-ascii?q?Ec3CrHE0gIiQET/XCINQg5Hi2huX7RDCRyFVLzZEPh6fN+p220TkAqwACKc1?= =?us-ascii?q?Rt2Ka1+hEPhPycUegT06kFuCg/tzV0Ekyx39XMC9qPvwBhZrlTYcsh4Fdb0m?= =?us-ascii?q?LUrxZ9MYKvL698iV8ebx96v0Lw2BVrBIVMi88qrGklzFk6FaXN+VdMZz6Jlb?= =?us-ascii?q?X9PrvWKW7stESmYqvb3lff09GI0qkG8+g9olTn+g+sQA5qz3Vqm/h46FTUsp?= =?us-ascii?q?THFwU6UJ/tXAAw7Rcs9J/AZSxorazTyHlgdeGWuzrPwJhhUOkqzQukc/9BPb?= =?us-ascii?q?mFDw79FYsRAM34e79ioESgch9RZLMaz6UzJc7zMqLegKM=3D?=
X-IPAS-Result: =?us-ascii?q?A2EeAAAoECpe/zGZrQpbBwMbAQEBAQEBAQUBAQERAQEDA?= =?us-ascii?q?wEBAYFpBAEBAQsBgXyBGIExCoQIkROEE5VPFIErFyUJAQEBAQEBAQEBBwETE?= =?us-ascii?q?AwBAQKBSoJ0AheCLDYHDgIDAQELAQEBBAEBAQEBBQMBAQEChiAMgjspAWkvC?= =?us-ascii?q?TkBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggFAjQZB?= =?us-ascii?q?QI1EgEfBiMEDTMSEAIBCA4MAhIBAQsHAgICMBUQAgQBDQWCW0sBgwqtMH8zh?= =?us-ascii?q?ElBhTWBDioBjDCBQj6BEScMFIJMPoJkAgEBAQGBLAEHCwEHAhYXCiYBAgWCQ?= =?us-ascii?q?TKCLASNXIJ1hgKJT45CcAMHgjmHQIlWeYRAgkd4hxKQJo5eh1KBEJImAgQCB?= =?us-ascii?q?AUCFYFZCoEQWBEIcBVlAYJBCUcYDYg5gzuFFIU/dAIIAwEkilEPFQmBBIEQA?= =?us-ascii?q?QE?=
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; Thu, 23 Jan 2020 16:29:52 -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; Thu, 23 Jan 2020 16:29:51 -0500
From: "Gould, James" <jgould@verisign.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-regext-login-security@ietf.org" <draft-ietf-regext-login-security@ietf.org>, Joseph Yee <jyee@afilias.info>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV0dwejjldInwObE2aShQlbi+Ipqf4xMgA
Date: Thu, 23 Jan 2020 21:29:51 +0000
Message-ID: <A5D19CB8-BEB8-4675-9C6E-43CE6C914464@verisign.com>
References: <157977713547.22794.12692666659052458667.idtracker@ietfa.amsl.com>
In-Reply-To: <157977713547.22794.12692666659052458667.idtracker@ietfa.amsl.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: <00FA8D219C28C240AE58F9732B05040E@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/eyJjJCv0QjYlo-yO_MXmrE5bblU>
Subject: Re: [regext] Alexey Melnikov'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: Thu, 23 Jan 2020 21:29:59 -0000

Alexey,

Thank you for your review and feedback.  My responses are embedded below.

-- 
 
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 1/23/20, 5:59 AM, "Alexey Melnikov via Datatracker" <noreply@ietf.org> wrote:

    Alexey Melnikov has entered the following ballot position for
    draft-ietf-regext-login-security-07: Discuss
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/
    
    
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    Thank you for this document. I have several small comments similar to what was
    raised by Roman and Ben:
    
    1) In 4.1:
    
       <loginSec:userAgent>:  OPTIONAL client user agent that identifies the
           client application software, technology, and operating system
           used by the server to identify functional or security
           constraints, current security issues, and potential future
           functional or security issues for the client.  The
           <loginSec:userAgent> element MUST contain at least one of the
           following child elements:
    
           <loginSec:app>:  OPTIONAL name of the client application software
               with version if available, such as the name of the client SDK
               "EPP SDK 1.0.0".
           <loginSec:tech>:  OPTIONAL technology used for the client
               software with version if available, such as "Java 11.0.2".
           <loginSec:os>:  OPTIONAL client operating system used with
               version if available, such as "x86_64 Mac OS X 10.11.6".
    
    Is there a registry of allowed values or at least some instructions how to
    construct these values? There are probably several existing IETF registries
    that can be reused.

JG - I'm not aware of any registries that exist that describes how to construct these values.  I believe to address Roman's, Ben's and your feedback, I will provide an example of how to construct these values.
    
    If these values are not supposed to be used by servers for anything other than
    logging (i.e. if they can't be used to work around bugs), then the document
    needs to say that.

JG - The servers can leverage this information for more than logging; although logging is the most common use case.  The most useful element for identification is the <loginSec:app>, where if there is a known client application such as an EPP SDK, the server can key off of the EPP SDK version to proactively identify potential security issues to report back to the client.  The server may already know the client application patterns or can identify the client application patterns using the logs to create rules for specific clients applications.  The additional <loginSec:tech> and <loginSec:os>  elements are useful to identify future security policy issues, such as deprecating or removing TLS cipher suites or TLS protocols.  The short answer to your question is that the server can utilize the elements for logging and for driving security event rules, but this is beyond the scope of the extension specification.       
    
    2) In the same section:
    
       <loginSec:pw>:  OPTIONAL plain text password that is case sensitive,
           has a minimum length of 6 characters, and has a maximum length
           that is up to server policy.  All leading and trailing whitespace
           is removed, and all internal contiguous whitespace that includes
           #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20
           (space) is replaced with a single #x20 (space).  This element
           MUST only be used if the [RFC5730] <pw> element is set to the
           "[LOGIN-SECURITY]" value.
    
    What is the definition of "whitespace"? Does this only include characters
    listed above or does it also include other Unicode characters (e.g. Unicode
    whitespace property)? If the former, then instead of using "whitespace that
    includes ..." use something like "whitespace is defined as one of ..."
   
JG - The definition of "whitespace" is based on the definition for XML schema whiteSpace (https://www.w3.org/TR/xmlschema11-2/#rf-whiteSpace), which does not include non-ASCII whitespace.  Validating XML parsers will apply the XML schema whitespace rules defined for the XML Schema "token" type (https://www.w3.org/TR/xmlschema11-2/#token), which is explicitly included in the description of the <loginSec:pw> element based on feedback from the working group.  I don't recommend use of non-ASCII characters for passwords, but I don't believe the extension should disallow it.  

 
       <loginSec:newPW>:  OPTIONAL plain text new password that is case
           sensitive, has a minimum length of 6 characters, and has a
           maximum length that is up to server policy.  All leading and
           trailing whitespace is removed, and all internal contiguous
           whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage
           return), and #x20 (space) is replaced with a single #x20 (space).
           This element MUST only be used if the [RFC5730] <newPW> element
           is set to the "[LOGIN-SECURITY]" value.
    
    As above.
    
JG - Same answer as for the <loginSec:pw> element above.
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    8.  Security Considerations
    
       The extension leaves the password (<pw> element) and new password
       (<newPW> element) minimum length beyond 6 characters and the maximum
       length up to sever policy.
    
    Typo: sever -> server
    
JG - I found this as well upon further review, so it will be addressed.