Re: [MLS] Improving client authentication

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Mon, 14 December 2020 05:23 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 608A13A005D for <mls@ietfa.amsl.com>; Sun, 13 Dec 2020 21:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GhB9BW8kEho8 for <mls@ietfa.amsl.com>; Sun, 13 Dec 2020 21:23:57 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 D3FCA3A00C4 for <mls@ietf.org>; Sun, 13 Dec 2020 21:23:56 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.78,417,1599516000"; d="scan'208";a="482743938"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.9]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 14 Dec 2020 06:23:44 +0100
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Mime-Version: 1.0 (1.0)
Date: Mon, 14 Dec 2020 06:23:44 +0100
Message-Id: <823434A1-E786-4ADB-AECB-BC20881A5831@inria.fr>
References: <20201214042118.GV64351@kduck.mit.edu>
Cc: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>, ML Messaging Layer Security <mls@ietf.org>
In-Reply-To: <20201214042118.GV64351@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: iPhone Mail (18B92)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/9YiZmRYcPa-qPhRRUouA9cNjMcc>
Subject: Re: [MLS] Improving client authentication
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: Mon, 14 Dec 2020 05:23:58 -0000

Good to know. I’ll have a look :)
Thanks for the info Ben !
B.

> On Dec 14, 2020, at 5:21 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Hi Ben,
> 
> Taking a bit of a tangent...
> 
>> On Wed, Dec 09, 2020 at 10:23:59AM +0100, Benjamin Beurdouche wrote:
>> 
>>> On 29 Nov 2020, at 18:13, Raphael Robert <raphael=40wire.com@dmarc.ietf.org> wrote:
>> Something less relevant to this discussion but I want to mention it
>> here...  This raises an issue that I have seen a lot over the last few
>> years: we need something which performs a similar role to the WebPKI but
>> doesn’t have the complexity of X.509.  Note that half of the attacks
>> against TLS implementations are actually attacks against ASN1/X.509
>> parsers, and we don’t really need this complexity for MLS.
>> 
>> We should probably use X.509 in many cases because it is well supported
>> by HSMs but in the long run, I think we should create WG and start
>> thinking of a replacement to X.509 for places (not the Web) that don’t
>> need the complexity.
> 
> This isn't quite what you're hoping for, but there's some work in the COSE
> WG to subset X.509 certificates and produce a more compact encoding for
> them; the same machinery will be naturally usable for making "CBOR native"
> certificates (that use COSE for the signatures instead of operating on the
> ASN.1 DER) that don't allow the full complexity of X.509.  The doc is
> draft-mattsson-cose-cbor-cert-compress (we'll be rechartering in order to
> pick it up as a WG item).
> 
> -Ben