Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

michael cheng <mzhcheng@gmail.com> Tue, 26 March 2019 01:26 UTC

Return-Path: <mzhcheng@gmail.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 2976E120199 for <tls@ietfa.amsl.com>; Mon, 25 Mar 2019 18:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WtayjRpGFHBq for <tls@ietfa.amsl.com>; Mon, 25 Mar 2019 18:26:35 -0700 (PDT)
Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F84120193 for <tls@ietf.org>; Mon, 25 Mar 2019 18:26:35 -0700 (PDT)
Received: by mail-it1-x12a.google.com with SMTP id v8so1449696itf.0 for <tls@ietf.org>; Mon, 25 Mar 2019 18:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rs+12DV/W8Cd/FAU6XWI9LNjPDnR0NPem93CrI5BBjg=; b=SwDNei33o7V8nSHk1jqaB7IuSnHCm8N26kn4MMey0k5oxJbnA2tt1XuK5Stg/HYgvo tgsJ5ECPBc6BVZTugpF+bsNL9X9YeawuueBCYyt0LyNDj3ebsCWK9KSSZa00TaBgTXPV 9RV1yBS//LoxTXEhpOsnao3JpHRIou1ZYyWWJxPoNr8fGCH1pFUyUNXpxjpEC+IQgXTp K5UugGIWt6X6PbmuDPEv+0T99wOOKpauZIChx2y6ugS16zu6j+4iqyT8oZVWdj8QG6fr 8+vZZpG7Q5bhjkX928x8rFJmR24etTlq9FaCgFgGpTR4/4DU2tVV1Bz61RFIWx/VnygW u51g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rs+12DV/W8Cd/FAU6XWI9LNjPDnR0NPem93CrI5BBjg=; b=qgJsLdYfGsS8SE2ddiA3NqsV5xVNYrHCyBm2LsUDDpzytDtJadB3lBIMo+A7oi5l+F THPPDe0/2QXgnTwmiXkJTDzkHbyROUDo++B8jOkzfZva5OgeAf8tp3/Reax2+EOQC6dn Wnez9+D6vT2NKWlVQQC25v3cuEbgLUIhg8XwSlvHWkN7AoY6BUZmZhbqLTkXZIj+URhJ K0We2GoZO8RmamvTDHCYv7IeEXKE+THT3Jm2SREX/9kNR3bzwkVhyPpMfOkoT916UjNS HarfGpWU9Py37k0HYTljlafs94uOX6CIljjuhdp7QmIDH0jH6hRH2AEjKtM36LnRI7v0 xG2g==
X-Gm-Message-State: APjAAAXTZk3pTnrXCNNsZ6yVhKvZ8L0bBqBdXK5CowytSJI3T7wwQoMQ lnc9Nptm8dYQIxqEEGcvp8Zdio/vvP/ZjBVKo6s=
X-Google-Smtp-Source: APXvYqwxHN+6Jfv0884JEeVKTav0TofcE660QfMqWyK/zuXc8dQhM5NVTFPnYS4obdgXVm18AHf0uck8WAVs3NFKhoI=
X-Received: by 2002:a24:6794:: with SMTP id u142mr1638839itc.84.1553563593854; Mon, 25 Mar 2019 18:26:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAPkJ7AgWXxZVoMEX-AS=G4xfAuget+5kH57WC5JVq4mYw609Uw@mail.gmail.com> <20190325153623.GL10233@akamai.com>
In-Reply-To: <20190325153623.GL10233@akamai.com>
From: michael cheng <mzhcheng@gmail.com>
Date: Tue, 26 Mar 2019 09:26:23 +0800
Message-ID: <CAPkJ7AgCZu_+y9HuXPpDnzWMj4YG4PgnHxJzPG+_vnewhyC_hg@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: ekr@rtfm.com, wang.haiguang.shieldlab@huawei.com, tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000025d4690584f5367f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OuWk7A-u6KFfj5ItsHY3yByFYpU>
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 26 Mar 2019 01:26:37 -0000

Of course, PKG should be protected tightly, which is normally equipped with
HSM.
On the other hand, this risk is not unique to PKG. Same risk and security
requirements apply to CA's certificate signing key.
In fact, PKG's key generation process is exactly a signing process with
master key signing on identity and other info.

Michael

Benjamin Kaduk <bkaduk@akamai.com> 于2019年3月25日周一 下午11:36写道:

> On Mon, Mar 25, 2019 at 10:07:05PM +0800, michael cheng wrote:
> >
> >
> >   As for the key escrow problem frequently raised in the emails, indeed,
> > there is a PKG in the system which could generate each device's private
> > key. However, when IBS is used in TLS1.3, passively attack to recover the
> > session key is not possible. Actively man-in-the-middle attack by
> replacing
> > exchanged DH tokens and signatures would certainly leave traces even
> > transiently. Similarly, a PKG could impersonate an entity to conduct a
> TLS
> > session, just as the KMS in the symmetric key solution, but forensic
> traces
> > could be also collected in this situation. It would be hugely risky for a
> > PKG, which would usually be a trusted party, to launch such attacks. If
> > such an attack is caught in red-handed, no one would trust the PKG's
> > service anymore.
>
> The risk here is not just limited to the PKG violating the trust placed
> in it -- there is also new attack surface on the PKG itself, and the
> risk that the PKG could become operationally compromised and an attacker
> obtain secrets in that manner.
>
> -Ben
>