Re: [MLS] Deniability without pairwise channels.

Sofía Celi <cherenkov@riseup.net> Fri, 24 January 2020 01:47 UTC

Return-Path: <cherenkov@riseup.net>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656CA1200CD for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 17:47: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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFYtfpgEeTW7 for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 17:47:47 -0800 (PST)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C573120019 for <mls@ietf.org>; Thu, 23 Jan 2020 17:47:47 -0800 (PST)
Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 483hq70pmBzDsSX for <mls@ietf.org>; Thu, 23 Jan 2020 17:47:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1579830467; bh=tPzSaAt7wTJYfbWSUeuMHJe4dbbWy3IHr+tbDLUSUhE=; h=Subject:From:To:References:Date:In-Reply-To:From; b=DWpjGh0ATtO5HobMGzjfHvDiCgZsEmT3s8SKq8Nnh+WJ4bOOSsMcKaKOo7vzzYn51 +EDuKq3gee4Fd2gLUoQ0ns5uIZAP0nVw22pCeldC4aaScVlj2ETxo3FSQ5bjFOHDcA fFPLYB0YznIQKF0Q3pXOlfoXJdgqS/aPhgBz9eb4=
X-Riseup-User-ID: 805EFDED5B25050C636FB375009CE75815C1E1403161F0DD52579936B01CA881
Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 483hq63MmfzJnWd for <mls@ietf.org>; Thu, 23 Jan 2020 17:47:46 -0800 (PST)
From: =?UTF-8?Q?Sof=c3=ada_Celi?= <cherenkov@riseup.net>
To: mls@ietf.org
References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> <C1D0D1E5-C107-487D-B302-63048109492E@wire.com> <696cb206-a261-e44b-3cce-2a157641fd68@riseup.net>
Autocrypt: addr=cherenkov@riseup.net; keydata= mQINBF2PpxoBEADAIhbOpA23OBsXzg/aQakv88vaLv8Dxt2oR92Rz9cfxca736HKDeO19IFC F1Anu6ylQsJfoT4UUgbGIjJpHtQB3OVIcgvsMagfZ0lEHd1eG8H8K9wqSjwSphUJl9ra+tMW MEbSDVmeV6qvHeO63vrazXrgUKBf0jDae0HcK++AYiSeSpbTmN+zTsY3ZXy9H1sdNhMUlkGt jcpROrna2NaSL3YG8YNJHsN+zGPoaBbPo9gQALUvuxtg0yS/ecly2xomWIeH6qJ4yJonO/Ys WqAAC96n423BeC1cAyYjij8ydygnR3csTibUI/iPkoH8xstnTyrv3djyiunVuw1BQUNqmtLV v7meRZfIFbfnNatuuPYp7S5NnL58vUwY/BwlMb5OhyzdCckRcITAXiz8sp4LANx1lxIdbaQA 9NsYv32vem9Pd0wtdN5JTW3dajgJtPAC1yfR86rw9u/+BSW9KhRqNF0/a+hX/+Njdni9fkl9 EheZiFHNO+nXeGLy0kikhUXr5iLg8626fG9I8QYuNj05WIEntegvAW65YjGTYSCdVgLx2bvv oGwC/4/jWxNm8MTzv38f/9YAZ5u5DSG3dFKYAjwOhf1IgEMTEWj+bKDFvgpv5fdTFumLxNey M/v3viwuNjS1hscRbi6IO36v4sFce4K1C5GU93YIgao2j01M8QARAQABtB1yaXNldXAgPGNo ZXJlbmtvdkByaXNldXAubmV0PokCVAQTAQgAPhYhBPq5Ptx83RGY3P1FWJG7a0VvRC0CBQJd j6caAhsDBQkHhh+ABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJG7a0VvRC0CEV0P/2UN rjx8LYmz/ydk2XO/uNWyobCtj/y9XBhZG9dpB8R43VC8OS5gv4Nw2ZLDrrpLQmaQ2dXjAeLL +9eCM++QT//VP2j2QS3YKbIcRreXSnl7DI6bMpD+Pu3JwiYHSyBs1zZT+VGm4nTS6QH588XJ VrslKyDYJFfzaHgkIGtxAWgqaHWAZHtjqh6PNEWMe2t571YYcVlk29cWsJ5ITsSPb+0Y0xJn u5HKQOc4TOdraedpLSFb5CZRlusNgWvhqmL4VyIcfjSEY0B8JVOgVpUeNTy0sZcDflYJ6uSN 9B1m79kb8STnVOtFS9gjnWbVwjAunqkkb/joRZhYfjeANVyYC4skh0uqJLFtqJw4r8s9+MrE p4lBy30lQ7mYYyqvRcwyEgoRRLHUvzV6cIHau/HV1pw0lwcbiXk3jP+TMf6OKOzg6lGJ/zX0 ZD+s0OAvHh8GM+5TDlgEM4Dwp6Q+9Jr1m9sp1QDQVbU7xrXXndXDd8RLEkiMDLovyyDtN6Jn HsW9PVMtu6sXvmbn0AHeHzHU/+bwB1LF4sx8O82tWKCgZlm270p+Bk6mjYmrlO4eQ11/AOF6 3ZlVoeXSaM4X0yoKa3ltdWaRoy9L0a4p7JuQYhBYIzjARbVjp9CmxctuQqW2qNSCJfagsUl8 mpcrs7xdhzfhzZHf8kQYWQcPYPPWLWqIuQINBF2PpxoBEACow9T4wPaQvKNG2LBnXeuLkDxf VGrZ/fDk0yfhG0174SjWXvDMIAgdNmfn2F4CM4F2FfPI32NZT34Td89fyWEWvP5/2I9HywyI QI/ubQvbqvm0l+DyzsdZNj4MBmNLy34Rg3K8uScgG7YbakzUplalbQKuzHrSW5OL5aBeKOG2 NGKJK7VZ4MzbdxhCLnXYvQwgnSkJ6B3AoBGv0LsLYzGUixzlMbNmYEhlQcK2scqprmFoX9rQ ymStV8b4Z37gkVmYeWGG2D9zl8gLj0u5Xw/KlF45JNxtMFBSL+Px7E1c+GJTWJxIENBhxRAu fxvbvduyJdXTObI51bqgV57510RjoLdzvVVqUpevmIdaMnavyUnDZOb8sBg3JG6NozZVzlXf S3FAvvK82zRShpd06ZNUbxPtNkruH/dT+6QV8gW3jX15gKGp2CtvhxLbi8ysV6zwtqxPkba2 03J0RAq2lVzxE/CSAP2qGPttElzHOPqhdmL6XjdmTw/WpF+qT8acB6Te8HZF+DriR/xG6EA1 MSdIK0vX4r5+U5bd0r7sh1ysSaYk/RI8hqxZZ4VGdPbVhFCOdT8AVcEXRoLsv+oN4x5WYJ9g 8G8Xw9+DvCNjFLxaGcL0ATHc8u8TyeegGRF3ZQNsRCqfVOLEYclYX+DqIly4ebCawAoIeWg2 GvN9cJAnFwARAQABiQI8BBgBCAAmFiEE+rk+3HzdEZjc/UVYkbtrRW9ELQIFAl2PpxoCGwwF CQeGH4AACgkQkbtrRW9ELQJX3g/8DAxtZTUJAlbKkluY30zITfcUwH4h9Rppxx/RvibZ1R4k 960OlvwyoRZ5rv2XiQA5VxOaVlh1tJErZnAyqgYwHr5CGQBjPEgkmRWBzme4W62uvCXOahxJ 4lNpr0TrVGRNOu223zYQcaN5S4Q5H2U9XNUFx8UF5leZIL6/Z6/bSGEW27vSuCxY6v8MkhQC 6l8T5RJqDsJmhwcVg9KDm8eGLkiu+kXS8iKl/Bw4o9257BI8hswBVRhN8kpHsecP2MGzKwn9 ccXWnOfM75qiq566UI26MY5priaGz5i+eCo26Rc0edm0IXxNs6rUZKVQUoxfMb/A/buJknYZ lUYXAgG2eDHEjlXvqNxQWHgfhIGqKFXDWuMt0sKP7Ta/lvGVPx9IHCTvkRZn9mtIN2/F9Lt5 sK3kezAlFw3BK6AIbD2v+g8TZnvKWSBidJHyhh7OEmKg3gXA3DxBpb7TU6iVUfG5e10RJUvQ qQNTSxv6mxJOgE3mEXizzj+tC6aEG/BzBwDsQpKquzUIKGCF2EGX9C7CZBhlsng/zmL3TFH6 EnY1tqV/lEg2/+gCLy/OE2dlE+EDZEtAiV183lzZNBs5Bg9NIz0Gq6a4ZkA8zDOFuxL2BFH2 EqrT33ladX2AIyKPMF50IwY4TMxGRlKhAjb4++pb55vBwVBLaTC09mvA+CuupPU=
Message-ID: <b26db4a2-2d31-7f5c-36ec-053d1d382e14@riseup.net>
Date: Thu, 23 Jan 2020 20:47:45 -0500
MIME-Version: 1.0
In-Reply-To: <696cb206-a261-e44b-3cce-2a157641fd68@riseup.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/iJarxOmgK756Z8eyIyUfXjrp6yE>
Subject: Re: [MLS] Deniability without pairwise channels.
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2020 01:47:50 -0000

I forgot to include paper [3]

3. http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf

Thanks!

On 1/23/20 8:42 PM, Sofía Celi wrote:
> Hello!
> 
> Very interesting insight!
> 
>> What has become clearer in some of the discussion is that a “sign & reveal” scheme puts the burden of proof on the victim to some (large) extent. The attacker can publish a signature chain that starts with the public identity of the victim and ends with the signature of a specific message. This signature chain will most likely look valid to a third party at first sight. It then becomes the duty of the victim to prove that they indeed published secret keys and that therefore anyone could have signed the last part in the signature chain. For the victim, this is painful at best and impossible at worst. It would be much nicer if the attacker couldn’t publish such a signature chain in the first place.
> 
> The "sign & reveal" mechanism is something that can be considered coming
> from OTR, because in it you reveal the MAC keys. But the idea, since the
> first paper of OTR[1] was to use the revelation of keys as an additional
> measure to expand the set of possible message forgers. Message
> unlinkability and deniability was provided in some previous version of
> OTR by using MAC keys instead of long-term keys for signing messages.
> OTR even provides a stronger notion for it by also using malleable
> encryption so anyone can forge a message. So only revealing keys is not
> enough to achieve strong offline deniability. OTR also used an
> authenticated key exchange where conversation partners are able to reuse
> ephemeral keys signed by the other party in forged transcripts, thereby
> providing partial participation repudiation. This insight by Trevor
> Perrin is nice to read[2]
> 
> 
> It depends on what kind of notions of deniability want to be provided.
> 
>> There might be another problem, regarding synchronicity: since MLS is
> completely asynchronous no one should publish a secret key too early
> (i.e. before others have consumed the encrypted messages) otherwise we
> might not be able to trust the authentication any longer.
> 
> This is super interesting and it is problem ;), see section '3.4 Message
> Integrity' of this paper[3].
> 
> 
> I think the notions of deniability in a cryptographic sense have evolved
> and new ways of achieving it have been studied. So many things can be
> done ;)
> 
> 
> 1. https://otr.cypherpunks.ca/otr-wpes.pdf
> 2. https://lists.cypherpunks.ca/pipermail/otr-dev/2013-July/001796.html
> 
> 
> 

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02