Re: [hrpc] draft-celi-irtf-hrpc-ipvc-00 (and notification aspects of authentication systems)

Sofía Celi <cherenkov@riseup.net> Thu, 20 April 2023 12:31 UTC

Return-Path: <cherenkov@riseup.net>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361D5C14CE5F for <hrpc@ietfa.amsl.com>; Thu, 20 Apr 2023 05:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeH2wKOiBCPh for <hrpc@ietfa.amsl.com>; Thu, 20 Apr 2023 05:31:08 -0700 (PDT)
Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2CCC151522 for <hrpc@irtf.org>; Thu, 20 Apr 2023 05:31:08 -0700 (PDT)
Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx0.riseup.net (Postfix) with ESMTPS id 4Q2H7v751Yz9t8K for <hrpc@irtf.org>; Thu, 20 Apr 2023 12:31:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1681993868; bh=gnDVq9DYF/lQWpD2zwgRk994/atVoAmlOmcF6TsHHQg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=BmQJGSOx7qZHI1r6wRhl5V2vPtvfzhYETyvTCxDDsogDH8XD02+eQIFZAGHVO+7hF SL4S7sLo3/OwDocfWH7/b+1TvwN7AhWScWHJk7F6qy0Z+FBNCSslkYz0ZZ98PQCzVo aNLwYw3Dk3Ulh4dO1KCGudF0/lWfS/bdTKZ6Jtbo=
X-Riseup-User-ID: 567807944C349ACF2D4729B5EB98F19E13714D4D89563A6FEEFC854E8B1DB80A
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4Q2H7v3xH8zFsQy for <hrpc@irtf.org>; Thu, 20 Apr 2023 12:31:07 +0000 (UTC)
Message-ID: <afe7b78e-7ebb-2f2d-b01b-0da083adcfda@riseup.net>
Date: Thu, 20 Apr 2023 13:31:05 +0100
MIME-Version: 1.0
To: hrpc@irtf.org
References: <B56A2B94-ADFF-480C-A21D-73F70B70942D@istaff.org>
From: Sofía Celi <cherenkov@riseup.net>
In-Reply-To: <B56A2B94-ADFF-480C-A21D-73F70B70942D@istaff.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/2M0IRPXSfF1ksI9W1TA1GYKw3tw>
Subject: Re: [hrpc] draft-celi-irtf-hrpc-ipvc-00 (and notification aspects of authentication systems)
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: hrpc discussion list <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2023 12:31:13 -0000

Dear, John,

Thank you very much! Apologies for the delay, but there were a couple of 
deadlines on my table ;)

>     Regarding the /Recommendation/ section, I note that the document
>     doesn’t include any mention of importance of the notification
>     capabilities of authentication systems as a means for mitigation
>     possible abuser use of technology.
> 
>     As means of example, I’d refer to the work of the National Network
>     to End Domestic Violence (NNEDV) and Facebook in making clear
>     possible mitigations to technology by abusers, and their publication
>     "A guide for Survivors of Abuse”
>     <https://nnedv.org/wp-content/uploads/2019/07/Library_TH_2018_Privacy_Safety_Facebook_Guide_Survivors_Abuse.pdf <https://nnedv.org/wp-content/uploads/2019/07/Library_TH_2018_Privacy_Safety_Facebook_Guide_Survivors_Abuse.pdf>>, which calls out the usefulness of notifications in detecting misuse of technology by abusers -
> 
>>     Login notifications
>>
>>     You can be notified, either by email or text message, if someone
>>     tries to access your account from a computer or device that you
>>     haven’t used before.
>>
>>     Login approvals
>>
>>     If you are logging into your account from a different web browser
>>     or device, you must have a security code to access your account.
>>
>>     Recognized devices
>>
>>     You can manage the devices that are allowed to have access to your
>>     account and be notified if an unknown device tries to access your
>>     account. This is particularly helpful for a survivor who may have
>>     wanted to access their account from their partner’s device, but
>>     now no longer wants that device to have access.
>>
>>     Active sessions
>>
>>     This is important to note because it shows sessions that are
>>     currently active or logged on. You may have active sessions if
>>     you’ve accessed your account or are using an app and forgot to log
>>     off. This also will show if someone else might have accessed your
>>     account. In that case, you can choose to ‘End Activity,’ which
>>     will block that device from continuing to access your account.
>>
>     This usefulness of such controls echoed in another recent paper "A
>     Domestic Violence Dystopia: Abuse via the Internet of Things and
>     Remedies Under Current Law”
>     <https://californialawreview.org/print/a-domestic-violence-dystopia-abuse-via-the-internet-of-things-and-remedies-under-current-law/#clr-toc-heading-10 <https://californialawreview.org/print/a-domestic-violence-dystopia-abuse-via-the-internet-of-things-and-remedies-under-current-law/#clr-toc-heading-10>>. which notes implications of technology design on those facing potential abuse – "Safe design should also include automatic generation of weekly or monthly reports informing users about their data and account logins, a system notification that shows which registered user initiated the controls, and the standard of requiring that users opt into rather than out of data-sharing between members of a household. “
> 
>     I’d encourage some further discussion on the list of the
>     notification aspects of authentication systems and their potential
>     use in mitigation of abuse via technology, and if found useful,
>     inclusion of additional text in the authentication systems portion
>     of the recommendations.

That is certainly a great point! I opened this github issue to keep it 
in mind: https://github.com/claucece/draft-celi-ipvc/issues/3 I did a 
very quick reading on some literature:

"More broadly, our findings clearly show a need for new tools that help 
users build better mental models of information flows and authorization 
dependencies across their devices and accounts. Reminder notifications 
are one such mechanism, but our interactions with clients suggests that
misunderstanding of information flow is pervasive (e.g., images being 
synced across accounts, files accessible from different devices). Both 
users and consultants also need to better understand authorization 
dependencies — what accounts or devices can be authorized to access a 
particular technology asset. Current approaches, such as configuration 
screens listing backup emails/phone numbers for recovering account 
access or which apps have been authorized to access an account’s
data are disjointed and poorly understood by clients.

One approach would be to design visualization tools that help users 
understand information flow and authorization dependency relationships. 
Our technograph can be seen as a pen-and-paper approach to doing so, but 
digital versions that extract configuration information from accounts to
graphically depict information flows and authorization relationships 
would likely be more accurate and informative. In turn, companies could 
provide “sharing summaries” that provide users with guided tours that 
make sense of an account’s information and authorization flows. 
Transitive cross-platform flows will be significantly harder to 
similarly visualize, since they would rely on compositions of security 
and sharing configurations on distinct platforms. Nevertheless one can 
imagine building a tool that gathers such information to drive a 
visualization."

- From "“Is my phone hacked?” Analyzing Clinical Computer Security 
Interventions with Survivors of Intimate Partner Violence"

I think I agree with all the points noted, but I'll read more some 
references. I do also think we ought to be careful on the recommendation 
as "Register of login details: Regular notifications of login locations 
(i.e., where) and associated timestamps (i.e., when) may be accessible 
to victim’s/survivor’s through their account settings (Parkin et al., 
2019). Crucially, these should be sufficiently vague so as not to put a 
victim/survivor in danger should a perpetrator access this information." 
from "Threat Modeling Intimate Partner Violence: Tech Abuse as a 
Cybersecurity Challenge in the Internet of Things". I think we should 
include the vagueness caveat in some of the points.

Thank you,

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
Chair of hprc at IRTF and anti-fraud at W3C.
Reach me out at: cherenkov@riseup.net
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6