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

"Alexey Melnikov" <aamelnikov@fastmail.fm> Mon, 27 January 2020 14:02 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 03D3812004F; Mon, 27 Jan 2020 06:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.fm header.b=wETvgvmr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a1RZDhJ+
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 zP_xV2IQy1uZ; Mon, 27 Jan 2020 06:02:48 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AB212004E; Mon, 27 Jan 2020 06:02:48 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4355F220F1; Mon, 27 Jan 2020 09:02:47 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 27 Jan 2020 09:02:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=uCfpRmkypzrnT8wYpxmjs8r8AXa8/Gi 4/Jo3HvKF/io=; b=wETvgvmra3Y/qhIU0ylD8xcFdRNMI60CeSZSYAxRQ+bqdcO GG2mZzZrm7i2PyZGBABWzvs0w1yj67/MarH4hRKugXVLQnl73xnZLxhQ2mu6+62a nJC8nyYMGGlXbqwmVpbcARXQ7e1JARjOPP35iVbcDwo98CKth1dUyxmmHhPTMXCw P86cvymukJ1jVjtYmjqBnJi4rG7gWMV1AHPwg8D0nZzAHSap3cyfUcNPmhtJnCWq hhto7rIsOwpXX0E6QaWB5/kLzKMgnM2mXu6afGvZWMFKYqxXKdHsSNzYv2ZC9bU/ iBFMex8s2Aj5+yF/QI6Gy0w2x/AjDcduL7bFZuw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=uCfpRm kypzrnT8wYpxmjs8r8AXa8/Gi4/Jo3HvKF/io=; b=a1RZDhJ+T74MdCtZ9oqIBj RO0ZGyT1gsRYsPd2Hrt/Mf9QNi5OPyj2p+Rt97D2W4n96D+X03B8xkuSxMX8zeDl fQLdcWfMGhy3716OcLpX00SXDTQLEkSabZpi+Qf05Sy/3mruS1O2MRVXggQCQer7 HjyA+JaPIDfqddvRuSjn6yEWA+lgaJ4VjfxUMXyq4aCp+VCfNFvQ5kGG1kxMlakF x8Pmb/WUUQgJxYL6QmDQVka6FsaxA3XicO2QfzqR6FaEUe3zWON6GgQwOnia3nUa i0aYa3LkBAOnfB/VHTDGVsLNRhIeQaBJFlTfFLK08925eNwoqMc/tjeKsfb0swpw ==
X-ME-Sender: <xms:h-0uXicM12cLA0s6RTSVCnpmtKj3xMzdg6DMFn9SPCdYJEWSN0vUAg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfedvgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgrnhgrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhm
X-ME-Proxy: <xmx:h-0uXo6CGX8LYtcr7ZXmwA-PORP1mjELKH1C-FojcD8jzL1El53GYA> <xmx:h-0uXnYN_gHC9C1G566JFywcKQNYT_rCuK8J5o763vGd7IxyShrySw> <xmx:h-0uXqGy0XOZ9Y6Yeo6_jHiVPTYod3nzOI9WMD3bQ7s9x2EtucwPXg> <xmx:h-0uXrkxKnz9VetLQtecs3lQIBRz_-WWj_y3P7pJT5532zkE3hRFuw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A40FC200A4; Mon, 27 Jan 2020 09:02:47 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-777-gdb93371-fmstable-20200123v1
Mime-Version: 1.0
Message-Id: <c669382f-90f0-4f55-88b1-ba7c1b3a5566@www.fastmail.com>
In-Reply-To: <A5D19CB8-BEB8-4675-9C6E-43CE6C914464@verisign.com>
References: <157977713547.22794.12692666659052458667.idtracker@ietfa.amsl.com> <A5D19CB8-BEB8-4675-9C6E-43CE6C914464@verisign.com>
Date: Mon, 27 Jan 2020 14:02:25 +0000
From: "Alexey Melnikov" <aamelnikov@fastmail.fm>
To: "James Gould" <jgould@verisign.com>, "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>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/aRyp7AvaX-WAhT3AfKfZhy-Pq30>
Subject: Re: [regext] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-reg?= =?utf-8?q?ext-login-security-07=3A_=28with_DISCUSS_and_COMMENT=29?=
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 14:02:50 -0000

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

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

Best Regards,
Alexey