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

"Gould, James" <jgould@verisign.com> Mon, 27 January 2020 18:49 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 7352B3A092B; Mon, 27 Jan 2020 10:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Wrg9OEts7Dvl; Mon, 27 Jan 2020 10:48:50 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 2AED93A0922; Mon, 27 Jan 2020 10:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=26575; q=dns/txt; s=VRSN; t=1580150930; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=eXgivkKgoWpL4cYDQClznFr/H2AsAcZ/0/v6SCOkjhI=; b=DG2LBhKc9uA8Gz4CMDS3GJUnYmFPwqgFUxuR1bgQrTHAEwyeG8c+GMAB K4XkOuB7uOX8Y/HOx3pfvn6un3URwczDXO/gmbIsUnhsKgQDP5z3A/AnW 74eGK1fnFvY9Z2ySMD6SyGIhjRBb3egrMV7LmojFusRVD5fyRwT9s5qJb Zh6OA8lmbmsjYzrLtVq7Bvy+IV8efvxHgWCdNBZA5tqocPJaDr04SHu0H UHvLp9vJKaIbsGN9Rt5SGomk8Xv8wvyRGhxKkvTDyol78lTtKSSUCAJ0W FxdgV9OJn+tWAuLs2ShyJ7uWtj25My8v2Y4xJ7d3o+u6XJoYNE+9PXBD7 Q==;
IronPort-SDR: RHM27lz1PYaU6re4QypDBnBRQR7TaRljg/By42uNJF9doK4Fqlz9VH97D9mM5UeBmd3mP7LIlU FYG+f7kyGjdio9JlLBy4Nb7ZJsp/ydPsvCAh9a20cUUxTQ3/kXMid6i2CDKJJsDLK5LT+nkpGu LuiUHCBKzcjGdw3uxfCsES9KvrOyZXlkDNtOSx4VBDECTt1DKNOGoRzScYjMv+uoxaIerU9t1D MalwyqSoy1AW80jOefJLqx65HNxv3Lh+yzVOe1qDhet/BACjuY37XlWUv3guirufCFUF0qSPu+ EI0=
X-IronPort-AV: E=Sophos;i="5.70,370,1574121600"; d="scan'208,217";a="36673"
IronPort-PHdr: =?us-ascii?q?9a23=3A5zO4tRy2KGNBTSDXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd0ukXK/ad9pjvdHbS+e9qxAeQG9mCt7Qf0aGG7OigATVGvc/a9ihaMdRlbF?= =?us-ascii?q?wssY0uhQsuAcqIWwXQDcXBSGgEJvlET0Jv5HqhMEJYS47UblzWpWCuv3ZJQk?= =?us-ascii?q?2sfQV6Kf7oFYHMks+5y/69+4HJYwVPmTGxfa5+IA+5oAnMucQam4VvJrg+xh?= =?us-ascii?q?bKoHZDZuBayX91KV6JkBvw+8m98IR//yhMvv4q6tJNX7j9c6kkV7JTES4oM3?= =?us-ascii?q?oy5M3ltBnDSRWA634BWWgIkRRGHhbI4gjiUpj+riX1uOx92DKHPcLtVrA7RS?= =?us-ascii?q?6i76ZwRxD2jioMKiM0/3vWisx0i6JbvQ6hqhliyIPafI2ZKPxzdb7GcNgEWW?= =?us-ascii?q?ROQNpeVy1ZAoO9cYQPCfYBPf1FpIX5vlcCsAeyCRWpCO7p1zRGhGL53bci3u?= =?us-ascii?q?ohDw/IwRAgEdwNvnTartr6OqYSXvy6w6TT1zrPc/ZW1C3h5IXScB0sp+yHU7?= =?us-ascii?q?JqccrWzEkiDw3JgFSXqYz4OzOay/wBuHWf4eV6UOKglXUnpw9sqTWoxMcshY?= =?us-ascii?q?7Jhp8Ryl/Z7ih53pg6Jce5SE5gYN6kH51QuzuGOItxR8MvWmdlszs0xL0BvJ?= =?us-ascii?q?60ZikKyJI/yh7BdfOHaYmI4gniVOaeJzd4hXRld66lixmu9kigz/XwVsiu31?= =?us-ascii?q?ZMtCVJiN7MtmoC1xHV98OJSeN981+81TqTzQzf9+NJLE4umabGK5MszKQ8m5?= =?us-ascii?q?UQvEjbAyP6hF/6gLKUe0k44OSk9uvqb7b8qpOBNIJ4kg/+Pbotl8CjBOk1Nx?= =?us-ascii?q?IBUmuf9Oun0bDu81P1T6hLg/AziabUtJHXKMYeq6O3DQJY0Jss5hCiBDm8yt?= =?us-ascii?q?sYh2MILFdddRKCiIjmJk/BLejjDfe6n1SsiDBrx+3aPrH5ApXCMHzDkLD5cL?= =?us-ascii?q?tg90BS0Bc/wtBH6ZxbC74NPO//VlXvtNPECR85KRS0z/z9B9pgzI8eR3iPAr?= =?us-ascii?q?SfMK/IrVCI4ecvL/GNZI8Tpjn9N+Ao6+PygXMjhFMQf6ek0YEKZH24EPlqOU?= =?us-ascii?q?qUbHn0jtcEC2gKvw4+TOLwiF2FVD5ef3SyX6075jEmDIKpEJzORp6zj7yb3S?= =?us-ascii?q?e7BZxWZm9AClyWDXjocICEV+8WaC2OOs9hjiAEVb+5RoA7zx6usRH1y75hLu?= =?us-ascii?q?rV+S0Ysozj2cN75+LJjhEy6Tl0AN6c02GJVW10kGYITScs3K9juUx91kuD0a?= =?us-ascii?q?9gjvxZC9NT/PxJXxw7NZHC0+x6Bcr+WgXbfteGUFymWMmpASktTtItxN8De1?= =?us-ascii?q?tyG8+4gRDNwyqmGr4VmKKXBJw6667cxWb+J8ljxHfJyKktll0mQsxANW2ngK?= =?us-ascii?q?5z7hPTCJDVnEWEjaaqdLgc3S7W+WeC02WOoE9YXBR3UaXfUnAVflHWosjh5k?= =?us-ascii?q?PeU7+uDqwqMglByMGcNKRHccfmjVtHRPfnOdTReXmxl32xBRaOyLOMa5Lge3?= =?us-ascii?q?8B0yXFFEgEjwcT8G6cNQcgCSeuvW3fDCB3GV3zY0Pj6+h+qGmgTkIvzgGFcV?= =?us-ascii?q?Fh17Sv9h4Sn/ycROsZ3qgYtyc5tzV0AFG90srMC9WeqApuYqpdYc8m7VdGy2?= =?us-ascii?q?3ZqwJ9MoanL6B4iV5NOzhw6mrq2gV6G81lnMwsrXAt0kImIKud3VdHdjCfw7?= =?us-ascii?q?j+M6bLL2Dz+FahbviSkm3e3Z6315wgoKA5pk7slACkCkRk9G9ohYp7yXyZs9?= =?us-ascii?q?/lCxcWXda5cE8y+gMw7+XYbS4g44/8y3B2MLK1vTmE0NUsUrh2gi28dstSZf?= =?us-ascii?q?vXXDT5FNcXUo33cLQn?=
X-IPAS-Result: =?us-ascii?q?A2G+AAASES9e/zCZrQpcBwMbAQEBAQEBAQUBAQERAQEDA?= =?us-ascii?q?wEBAYF7gSVYgRiBMQqECpE7g26XDhclCQEBAQEBAQEBAQcBJwgBAQKBSoIvR?= =?us-ascii?q?QIXgjI4EwIDAQELAQEBBAEBAQEBBQMBAQEChiAMgjspAWkvCTkBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHIyoHIyQBAR4BBAEjV?= =?us-ascii?q?gULAgEIDiABDAcCAgIwJQIEAQ0FgltLAYF9Xi+sO4EyikaBOIw4gUI+gREnI?= =?us-ascii?q?IJMPoJkBIE2FS0KHQkBAoJGMoIsBJBRhV4kmQUDB4I5h0KJV4U5gkh4lzyOY?= =?us-ascii?q?IFKhgqBEI9jgkYCBAIEBQIVgWmBe3AVZQGCQQlHGA2TeBcVgzuFFIU/dAIMJ?= =?us-ascii?q?IsZD4EigRABAQ?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Mon, 27 Jan 2020 11:40:03 -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, 27 Jan 2020 11:40:03 -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] Re: Alexey Melnikov's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV1Rpzk4Ja8aLzeEinwaPtau5kKqf+tqcA
Date: Mon, 27 Jan 2020 16:40:03 +0000
Message-ID: <3A7016A7-409D-477C-A13C-1948184A36D9@verisign.com>
References: <157977713547.22794.12692666659052458667.idtracker@ietfa.amsl.com> <A5D19CB8-BEB8-4675-9C6E-43CE6C914464@verisign.com> <c669382f-90f0-4f55-88b1-ba7c1b3a5566@www.fastmail.com>
In-Reply-To: <c669382f-90f0-4f55-88b1-ba7c1b3a5566@www.fastmail.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: multipart/alternative; boundary="_000_3A7016A7409D477CA13C1948184A36D9verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/XMfTx7qIPwf5OaFoEx99UXYrjHA>
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: Mon, 27 Jan 2020 18:49:01 -0000

Alexey,



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/27/20, 9:02 AM, "Alexey Melnikov" <aamelnikov@fastmail.fm> wrote:



    Hi James,



    On Thu, Jan 23, 2020, at 9:29 PM, Gould, James wrote:

    > Alexey,



     [snip]



    >

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



    I am not insisting that you should use these, but some examples:



    https://www.iana.org/assignments/operating-system-names/operating-system-names.xhtml#operating-system-names-1



    and probably more interesting:



    https://www.iana.org/assignments/iodef2/iodef2.xhtml#softwarereference-dtype



    The latter points to NIST's Common Platform Enumeration and ISO 19770 software identification (SWID).



JG - I believe inclusion of the example ABNF for constructing the <loginSec:userAgent> child element values will provide the needed clarification.  It looks like you feel the same way based on your response to Roman's thread.  I'll address the usage of the information.





    >

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



    I think saying something along these lines would be helpful.



JG - To address this, I can update the description of the <loginSec:userAgent> as:



OPTIONAL client user agent information 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 server may use the information for real-time identification and client notification of security issues, such as keying off of the client application software for executing security rule checks.  The server may capture the information to identify future security policy issues, such as deprecating or removing TLS cipher suites or TLS protocols.  The <loginSec:userAgent> element MUST contain at least one of the following child elements:





    Best Regards,

    Alexey