Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?)

t.petch <ietfc@btconnect.com> Fri, 21 March 2014 14:50 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F971A0993 for <tls@ietfa.amsl.com>; Fri, 21 Mar 2014 07:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 vdl-G4bAY2TG for <tls@ietfa.amsl.com>; Fri, 21 Mar 2014 07:50:37 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) by ietfa.amsl.com (Postfix) with ESMTP id B40541A0989 for <tls@ietf.org>; Fri, 21 Mar 2014 07:50:36 -0700 (PDT)
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 14:50:25 +0000
Message-ID: <045401cf4514$1c0e5ec0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Michael Sweet <msweet@apple.com>, Rene Struik <rstruik.ext@gmail.com>
References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <CALCETrUz8zCBHiq42GTnkkSaBcpA5pjSvk6kwwPjzn+MtBKMgA@mail.gmail.com> <e38419e3ada3233dbb3f860048703347.squirrel@webmail.dreamhost.com> <CALCETrVgJxfdCxZqc9ttHHNKHm-hdtGbqzHvsQ-6yd5BK=9PDw@mail.gmail.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <CADrU+d+GkGU1Da3W6xGuOq4qvd40DdT6+sO6WEZeEag7Q1OiVQ@mail.gmail.com> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com>
Date: Fri, 21 Mar 2014 14:44:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-ClientProxiedBy: AM3PR07CA003.eurprd07.prod.outlook.com (10.242.16.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Forefront-PRVS: 0157DEB61B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(24454002)(51914003)(13464003)(377454003)(189002)(199002)(479174003)(74366001)(50466002)(83072002)(85852003)(15202345003)(42186004)(88136002)(4396001)(77982001)(56816005)(90146001)(19580395003)(83322001)(19580405001)(46102001)(63696002)(89996001)(53806001)(44716002)(62236002)(50226001)(79102001)(47736001)(51856001)(44736004)(87976001)(33646001)(47776003)(49866001)(59766001)(74706001)(20776003)(50986001)(65816001)(93136001)(76482001)(92566001)(80022001)(92726001)(87266001)(23756003)(56776001)(93516002)(54316002)(77156001)(76786001)(77096001)(97186001)(85306002)(325944007)(74876001)(66066001)(87286001)(61296002)(94316002)(74662001)(80976001)(561944002)(47976001)(69226001)(14496001)(76796001)(31966008)(62966002)(93916002)(47446002)(86362001)(81342001)(74502001)(81542001)(94946001)(95666003)(15975445006)(95416001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; FPR:F6D7F4F4.9EF867E1.BDF45DBF.C2E5D979.204C5; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4bvDzwHFDTdxcqK_468YjQed71s
Cc: tls@ietf.org
Subject: Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 21 Mar 2014 14:50:43 -0000

----- Original Message -----
From: "Michael Sweet" <msweet@apple.com>
To: "Rene Struik" <rstruik.ext@gmail.com>
Cc: <tls@ietf.org>
Sent: Friday, March 21, 2014 12:26 PM

Rene,

Installing device certificates during manufacturing is not a simple
process - the factory would need to act as a CA or would need to have a
supply of certificates that matches whatever identifiers are used by the
devices.  Not to mention how you'd manage revocation if the root was
compromised...

<tp>

Michael

In the context of syslog security, some years ago now, the question of
device certificates arose and it was said there that they were quite
common.  They would be self-signed, which gives much of the needed
security, while avoiding issues of CA and root compromise.

Tom Petch

On Mar 20, 2014, at 9:52 PM, Rene Struik <rstruik.ext@gmail.com> wrote:

> Hi Robert:
>
> Wouldn't it be much easier to embed device certificates with
constrained devices at manufacturing? This may do away with need
to store info that is not public on servers.
>
> If you could provide some links to discussions in "IoT community
groups" interested in this, that would help.
>
> Best regards, Rene
>
> ==
> There is a lot of interest in the IoT community in using some form of
PAKE in conjunction with DTLS (or TLS with EAP) for authenticating
commissioning/bootstrapping of IoT devices onto IoT networks
>
> On 3/20/2014 1:21 PM, Robert Cragie wrote:
>> It should be remembered that TLS is used in places other than web
browsers - the existence of the DICE WG is testament to this. There is a
lot of interest in the IoT community in using some form of PAKE in
conjunction with DTLS (or TLS with EAP) for authenticating
commissioning/bootstrapping of IoT devices onto IoT networks. I realise
this is different to the original proposition in this thread but wanted
to draw this to the attention of the WG nevertheless.
>>
>> Robert
>>
>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>
wrote:
>> On 03/20/2014 12:18 PM, Paul Hoffman wrote:
>> > As an important note, you did not define "we" above. A few possible
expansions would be:
>> >
>> > - The TLS WG, where this thread currently lives, does not get to
define Web UI without a charter change.
>> >
>> > - The HTTPbis WG has not asked the TLS WG to take over this work,
nor has it embraced anything like it.
>> >
>> > - The IETF doesn't do this kind of work as a whole body.
>> >
>> > - The IAB (of which none of us are part of the "we") might take the
topic on and suggest ways which the IETF might do the work.
>>
>> yep, thanks for the clarification.  I actually meant "we" in the
broad
>> sense of "the community of people who care about making
communications
>> on the web more secure", which includes groups you didn't even
mention
>> above, like web site designers, systems administrators, etc.
>>
>> It's still on-topic here (despite the broad scope implied above)
because
>> the TLS WG does have a role to play, by considering the merits of
>> proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as
>> well as considering alternatives that deal with this particular use
case.
>>
>> >> option (A) is seriously hard, maybe impossible given the state of
the
>> >> web.  option (B) is terrible.
>> >
>> > Exactly right, for any value of "we".
>>
>> :(
>>
>>         --dkg
>>
>> > --
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair