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

"Alexey Melnikov" <> Mon, 27 January 2020 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03D3812004F; Mon, 27 Jan 2020 06:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key) header.b=wETvgvmr; dkim=pass (2048-bit key) header.b=a1RZDhJ+
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zP_xV2IQy1uZ; Mon, 27 Jan 2020 06:02:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25AB212004E; Mon, 27 Jan 2020 06:02:48 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4355F220F1; Mon, 27 Jan 2020 09:02:47 -0500 (EST)
Received: from imap1 ([]) by compute7.internal (MEProxy); Mon, 27 Jan 2020 09:02:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-777-gdb93371-fmstable-20200123v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 27 Jan 2020 14:02:25 +0000
From: Alexey Melnikov <>
To: James Gould <>, The IESG <>
Cc: "" <>, Joseph Yee <>, "" <>, "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [regext] Alexey Melnikov's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,


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

and probably more interesting:

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,