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

Ash Wilson <ash.wilson@valimail.com> Wed, 18 November 2020 18:38 UTC

Return-Path: <ash.wilson@valimail.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 C6F083A067A for <iot-onboarding@ietfa.amsl.com>; Wed, 18 Nov 2020 10:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=valimail.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 WHakZ5FnpwRr for <iot-onboarding@ietfa.amsl.com>; Wed, 18 Nov 2020 10:38:05 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 85A8C3A02BB for <iot-onboarding@ietf.org>; Wed, 18 Nov 2020 10:38:05 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id f93so2354675qtb.10 for <iot-onboarding@ietf.org>; Wed, 18 Nov 2020 10:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RvSok90v9jWEK9JswVR8IGPWZXHzrzxgITwx2ZdLDgg=; b=DFeUCR7jm6aClrjn2Gr6vN193HSqRfZS18r4QMMHjBY4uu8KmrQB+XX1WljjF6IpTE Px5JBlQcrCnJRpIOS5plCuqs6Rb0deutwDGuws85h12r1RB4gONcZ2YBh1cm/D1/Q++G tgwNC2aRRgyzDUR1hQ/TjpHgFTkJqk8jUxc00Al0SCjqtnL97rKJTQPP3t+NNhPW+v3X gho4qty4KDyrHijg+oPDwsb1Sv87bqeSvtbVjgHU9bneGQH9QMm5jRP07DTyuWlFureG Q7RVJ3bx3yCFtBR/eHeO9QZwq+VYOUSRwVFvXlf0m5JEL3NXZ9m+zTL5t53IEV+1vVum nRTw==
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=RvSok90v9jWEK9JswVR8IGPWZXHzrzxgITwx2ZdLDgg=; b=EP6vETXV90OFo7wQc1YX+uyRyjwGJgwSGS6BbR0A/qFaCwDWlLrlz8hoVMEEn9iwIa z6+x6sNsl6iBEFAgRKpDecoI0he6gkhefus7FtxLkdZvNanWcX2X4fwrpuvsPT/6JUDV 1qGRj0NoCUfyH0XXfTli2dzk5usDG5Qjr2T8sWqcJeygwDUDUgBK/eBsQu4Nggl5U4lf 8dPkeNLRIZAA3FLyPCaQCAZXJYjv4fwNF0sVnqzY8mzC+2q84fIAhJDHOL31rGzM/Me8 oF+Cpk8hyY1wH08TncwITWbCO153xlkCsR2QfLhhmx94IhY2I3Rs/brCTDkUB14Z4Qxp mUyw==
X-Gm-Message-State: AOAM5311jCakIJ7cxoemeOeY7nE0odS1CvoZmOJc4r6Xzw1ZTjo++laA HtKviFM9G0B/vk6b7th71u+JUdgi6U35HUFPtlCbOg==
X-Google-Smtp-Source: ABdhPJyU727/tIB7yvvg6nG9b8UDZNNSjHS40AWcDLbahZHEZb46BlaI1b6WjneeQ98EgT1dPgacOoA8horTCU01yF4=
X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr5595428qtw.298.1605724684192; Wed, 18 Nov 2020 10:38:04 -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> <dedb5fb7-f0bc-7e35-4f90-fddc2d093873@ericsson.com> <CAHPuVdVyfiLa0om8=-WZ+8yutTOYLLre1fKkSPjAdvhnffQhag@mail.gmail.com> <8f313965-c6e7-8c5f-4f04-9d3cd01ee41e@ericsson.com> <CAHPuVdVxdv++i1VKGKop9DHkskNnQaRHL_WiYpVQgjYW70gNSQ@mail.gmail.com>
In-Reply-To: <CAHPuVdVxdv++i1VKGKop9DHkskNnQaRHL_WiYpVQgjYW70gNSQ@mail.gmail.com>
From: Ash Wilson <ash.wilson@valimail.com>
Date: Wed, 18 Nov 2020 10:37:53 -0800
Message-ID: <CAEfM=vQmoDcq_riXVT0BUjspLtJnz4h5gEUkHdW+TFfszQmTPg@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, IETF SecDispatch <secdispatch@ietf.org>, Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068a1f905b465e95e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/ZXaqpmYgTYuyOYuL8aqMsSkoy6Q>
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 18:38:08 -0000

Hi Mohit,
  You are correct- using DANE for server authentication in use cases
without Internet connectivity (EAP-TLS, for instance) is challenging, and
may require other modifications to the process. It may make more sense for
the EAP-TLS use case to use another mechanism like the TLS DNSSEC chain
extension, or traditional PKI, to get around the lack of internet
connectivity for the server part of mutual authentication.

  Using DANE for client identity is expected to work well because the
authentication server typically has sufficient connectivity to interact
with DNS.

  These proposals aren't intended to replace any identity bootstrapping
protocols. Rather, they are intended to work in concert with existing
protocols to make public keys easily discoverable.

On Wed, Nov 18, 2020 at 7:48 AM Shumon Huque <shuque@gmail.com> wrote:

> I assume we can cover this at tomorrow's side meeting. I'm not fully
> informed of the details of the network access authentication use case
> specifically (I'm sure Ash will elaborate), but I assume there are other
> possibilities for authenticating the server side in those environments,
> such as straight PKIX auth with a pre-provisioned small trust anchor set.
>
> Shumon.
>
> On Wed, Nov 18, 2020 at 10:10 AM Mohit Sethi M <mohit.m.sethi@ericsson.com>
> wrote:
>
>> Hi Shumon,
>>
>> Why won't the same issue apply to the IoT bootstrapping and the SIM card
>> use case you described.  You would likely authenticate the server before
>> revealing the client identity. And that cannot happen with DANE because of
>> lack of initial Internet connectivity. If this is the case, then I fail to
>> understand some of the excitement for use in IoT bootstrapping. Also, I am
>> not sure if verifying DNSSEC signatures sent inside the proposed TLS
>> extension would be simple and lightweight for IoT devices?
>>
>> --Mohit
>> On 11/18/20 4:09 PM, Shumon Huque wrote:
>>
>> On Wed, Nov 18, 2020 at 7:58 AM Mohit Sethi M <mohit.m.sethi=
>> 40ericsson.com@dmarc.ietf.org> wrote:
>>
>>> Hi Ash and Shumon,
>>>
>>> My understanding is that your solution is applicable to any scenario
>>> that uses client certificates. Obviously IoT might be one application area
>>> for this, but there are many other uses of client authentication with
>>> certificates.
>>>
>> Mohit - yes, there are certainly other application use cases and the
>> protocol is general purpose. Some SMTP transport security folks are
>> interested in this to give one example.
>>
>> I don't have any strong opinions about whether this is useful or not. But
>>> it might be good to have a separate focused DANE working group for these
>>> drafts if there is strong demand for such a solution. Your presentation
>>> also highlighted your intention of defining new RRtype and/or expanding the
>>> scope of TLSA. These things (along with DANE light etc.) would require the
>>> input of DNS and TLS folks (in addition to the IoT requirements).
>>>
>>
>> Yup, we will certainly need to get their input on this topic. I think I
>> saw a couple folks in the chat suggest resurrecting the DANE wg, which I'm
>> open to, but there was pushback too (I think more detailed discussion on
>> list was deemed necessary first).
>>
>> Also, I didn't understand how would server authentication work? I
>>> probably did not listen to your presentation carefully enough but I suppose
>>> you cannot use DANE for server authentication in scenarios where the client
>>> device does not yet have Internet connectivity. So how would server
>>> authentication work in EAP-TLS/SIM card/IoT bootstrapping scenarios you
>>> discussed?
>>>
>>
>> Yeah, the EAP-TLS case is trickier for DANE server authentication. There
>> are possible mechanisms though - the TLS DNSSEC chain extension (which
>> failed to gain consensus in the TLS WG a while back, but which will
>> probably be published through the IETF's independent stream) would provide
>> a way for the TLS server to deliver its DNS authentication chain inside the
>> TLS handshake, obviating the need for the client to perform DNS queries
>> prior to Internet connectivity. There are probably other solutions that
>> could be devised.
>>
>> Shumon.
>>
>>
>> --
> Iot-onboarding mailing list
> Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding
>


-- 

*Ash Wilson* | Technical Director
*e:* ash.wilson@valimail.com


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.