Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

Shumon Huque <shuque@gmail.com> Wed, 18 November 2020 13:52 UTC

Return-Path: <shuque@gmail.com>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3D3A044A for <iot-onboarding@ietfa.amsl.com>; Wed, 18 Nov 2020 05:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 jZljj1fFUkqK for <iot-onboarding@ietfa.amsl.com>; Wed, 18 Nov 2020 05:52:22 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 DF7633A0420 for <iot-onboarding@ietf.org>; Wed, 18 Nov 2020 05:52:21 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id y4so2071069edy.5 for <iot-onboarding@ietf.org>; Wed, 18 Nov 2020 05:52:21 -0800 (PST)
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=K7Zy/imtXkphZgE4GU3eo32cp+FIp4YlAfDYD5JYoFg=; b=L8I8MaGTd/xmV7pCjLk4BO6pAlTJOc/zExHwhTw58mR/lGE/1BEJHq1SzOxMckcdNF O1vHb5JQeJWzxhDxJA9S+sSsNbSfhzHHyNTqR1EbcpFXPUGXIpyLMhzvovm+52njN80a +JbF0e4pSDrP501A5XjLva/Px1L1OwM0Va7+PCNcjUGOgPENT2rB/PxtsNMMPcJRfX0E fq/b33AA7eBzDk+0Sf+NnqH5OdkcD7HH8hW4vheAYeor745vCiFBrxS+k61NB5tHuPz7 4tbR61JJOA4xQb/xdQ/S+cnkES1q4wvKeWg9ehpws42+mWa1d4YeznaQs+TVTE3s91VD 31tQ==
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=K7Zy/imtXkphZgE4GU3eo32cp+FIp4YlAfDYD5JYoFg=; b=DGIcGgUtXN4aDqTNYUdgap6PI8MmMfT6TlaoAoMUQKfyxXGC3MimPXEffwXxoiAj4+ 16ZjiYBxE9XaoWoit6aG63UQhZpFDhXXBoGzNHyJ1lULzupWco2eu5FJ4ypahsIljSzA DAl/Znwur4PNFvrHNz3nzbAwPIiQuNe8E+Py8twBMe6g7aBkv3bsu0NGU91hNWfO4wIp 24db4VkS0xBHVrgiJDd1pZU3jS42KWwxMy1bti57TY6WJoMwwkyuolFs1RzwkR/eiOJs QhHrH5meIjF52P0Bt4wvB9pUbM7hbFK/x4vow58OX9MK5wdKNF3n0CldBpnwcAImeM8V y7ZQ==
X-Gm-Message-State: AOAM532Mb3tr+R3ZHOCH8tps94ptqmNFKfIY8nXQ3FpYS/ZC2xOgmS1/ 174/KG4+XjYeFqvOt7LpT+OhFcS1btYCOpbJKVk=
X-Google-Smtp-Source: ABdhPJwbqaGqGERtj8g4NamgzEUMDqVfatbhinIsMZuP/zYTt8VNDKBTvq87nTQbHoIwylco7ZCFIUV6OK9xJc9rMrc=
X-Received: by 2002:a05:6402:1c8e:: with SMTP id cy14mr26799629edb.39.1605707540240; Wed, 18 Nov 2020 05:52:20 -0800 (PST)
MIME-Version: 1.0
References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com> <b178d5066d6b4371a59ffe59bb6d6447@huawei.com> <CAHPuVdXo1o0d_WzLqTZ5s9+JNG=3kbNdTO1BrS7BdEBDd2F1Lw@mail.gmail.com> <CAEfM=vRotGf-SuYz8PKNop8zdCCA_-x+3xU81rMS6Le6EUOOFw@mail.gmail.com> <2FE1E13B-E313-43F9-932E-6682DF72E18D@cisco.com> <20201117074330.GP39343@faui48f.informatik.uni-erlangen.de> <CAEfM=vTDPi6fQXR+EQ7jW04RsyZQRQXHw3R-fH+QiC70JKSZaA@mail.gmail.com>
In-Reply-To: <CAEfM=vTDPi6fQXR+EQ7jW04RsyZQRQXHw3R-fH+QiC70JKSZaA@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 18 Nov 2020 08:52:09 -0500
Message-ID: <CAHPuVdVP+puyggDeWgNm=4vtG023gS2PEpQwAouNMoSfA967TQ@mail.gmail.com>
To: Ash Wilson <ash.wilson@valimail.com>
Cc: Toerless Eckert <tte@cs.fau.de>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Ash Wilson <ash.wilson=40valimail.com@dmarc.ietf.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "Panwei (William)" <william.panwei@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000008c9d7805b461ebf5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/QUqe7_7dw2iqNKVx_kaW2W9Q_h4>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 13:52:25 -0000

On Tue, Nov 17, 2020 at 1:53 PM Ash Wilson <ash.wilson@valimail.com> wrote:

>
> It's called "public" keys ;-)) But indeed, DNS makes it easier for
>> discovery of public keys == identities
>> of devices. And their names. I am probably more worried about the
>> publicity of names.
>>
>
> Good point. There are a few areas we should be mindful of as we proceed.
>   Knowing the device's name is a sure way to access the public key, if the
> public key is in DNS. But you must first know (or guess) the device's name.
> Not putting unnecessary information in a certificate is a good way to
> lessen the impact of a guessed device name.
>   Don't put device certificates into CT logs. Unless there's a good reason
> that's completely escaping me... that's a surefire way to signal the size
> of your fleet, together with whatever metadata the certificates contain.
> This is a risk that has nothing to do with making DANE work for Client ID
> or cert discovery use cases, but it's worth mentioning. DANE makes the
> certificate discoverable, without making the fleet easily enumerable.
>   Passive DNS might be a vector for fleet enumeration, but it has its own
> challenges.
>   Let's ensure that the TLS implementation does a good job of protecting
> the dane_clientid field. I think that's where we may have an opportunity
> for discovery by packet capture, if it passes in plaintext. Discovery via
> this method would provide a source and destination IP/NAT address as well
> as an identity name, which could be used for certificate discovery. If we
> pass the dane_clientid encrypted, this vector is mitigated.
>

Just to elaborate on this point, with TLS 1.3 it should be possible to
fully protect the dane_clientid. In the next revision of the draft we will
move the use of the extension into the CertificateRequest and Certificate
messages which are both encrypted. TLS 1.2 on the other hand, will be a
challenge: ClientHello extensions and the client's Certificate message are
both in the clear (and ECH is not being designed for 1.2).

Shumon.