Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS

Wang Haiguang <wang.haiguang.shieldlab@huawei.com> Sat, 14 July 2018 01:44 UTC

Return-Path: <wang.haiguang.shieldlab@huawei.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C7E130F73 for <tls@ietfa.amsl.com>; Fri, 13 Jul 2018 18:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fbz4Fma3SdRC for <tls@ietfa.amsl.com>; Fri, 13 Jul 2018 18:44:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 67122130F6D for <tls@ietf.org>; Fri, 13 Jul 2018 18:44:48 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3F5D4E7133AFD for <tls@ietf.org>; Sat, 14 Jul 2018 02:44:34 +0100 (IST)
Received: from SINEML705-CAH.china.huawei.com (10.223.161.55) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 14 Jul 2018 02:44:36 +0100
Received: from SINEML521-MBS.china.huawei.com ([169.254.2.83]) by SINEML705-CAH.china.huawei.com ([10.223.161.55]) with mapi id 14.03.0382.000; Sat, 14 Jul 2018 09:44:28 +0800
From: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Regarding the identity bidding issue when using raw public key with TLS
Thread-Index: AdQZwdlVj/TBP8f2Sb2VA3i7V7Seh///qsuA//438UD//Fb5wP/4rAbQ//FXLFD/4q2/gP/FWrmw/4mgufs=
Date: Sat, 14 Jul 2018 01:44:28 +0000
Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E0B5E73@SINEML521-MBS.china.huawei.com>
References: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> <20180712121729.GA3925@LK-Perkele-VII> ,<0AE05CBFB1A6A0468C8581DAE58A31309E0B16F3@SINEML521-MBX.china.huawei.com>
In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E0B16F3@SINEML521-MBX.china.huawei.com>
Accept-Language: en-SG, en-US
Content-Language: en-SG
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.37.116]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hIkY_E7ENypp0kc3ZNwX8DdwHz4>
X-Mailman-Approved-At: Fri, 13 Jul 2018 20:53:08 -0700
Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2018 01:44:54 -0000

Dear ilari,

Thanks very much for the reply :-). Please see my comments inline below.

-----Original Message-----
From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
Sent: Thursday, July 12, 2018 8:17 PM
To: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS

On Thu, Jul 12, 2018 at 09:30:40AM +0000, Wang Haiguang wrote:
> Hello, everyone,
>
> To solve the complex issue caused by the certification, in RFC 7250,
> it is recommended to use raw public for authentication.
> However, when using RAW public directly for authentication, identity
> and public key binding is required. That is, server need to maintain a
> large table to map the public key and identity.
> For networks with huge amount of IoT devices, the maintenance of such
> a huge database might be a challenge issue.

It seems to me that getting the information to provisioning to the database is the biggest issue. Any semi-decent database program should not even be breaking sweat with million row table on quite low-end server hardware (if the indexing is even remotely sane).

[HG-1] Yes. Getting the information and provisioning to the database for massive IoT is a big issue. Using IBC as raw public key, then we might be able to get ride of this issue, especially for network operators. They may just care about the number of devices connected to network instead of knowing the details of each device.

> Currently we are thinking to use identity-base public key to solve the
> issue.  Is there any better solution to solve the identity binding
> issue?

If you do not want to use server-side database, create an internal CA and issue as compact certificates as possible. The overhead should be in low two hundred bytes.

But this does not save you from having to figure out what those IoT devices actually are!

[HG-1] Internal CA and compact certificate can help in some scenarios, but it will limit the authentication to a local domain. With IBC, we can keep the certificate compact, at same time, it can be used cross domain.

> Can anyone give us some comments regarding using IBC as raw public key
> for TLS for massive IoT authentication?

I do not think there is any way currently to do that. The only defined signature algorithms are ([*] means removed from TLS 1.3):

- RSA PKCS#1 v1.5[*]
- DSA[*]
- ECDSA
- EdDSA2 (Ed25519 and Ed448)

These are also the only algorithms that can be used with raw public key authentication. None of these is IBC algorithm..

Also, the way the raw public keys work is the same in both TLS 1.2 and
1.3 (the precise messages are different, but it still works the same).

[HG-1] Yes. With TLS-1.3, IBC algorithm is not supported at the moment. So we hope that we can develop a separate RFC based on 1.3 and support IBC for massive IoT usage scenarios only?
 RFC 6507 specifies an IBC signature method based on ECC, it is similar to ECDSA. We can start with that first.


-Ilari