Re: [TLS] The future of external PSK in TLS 1.3
Achim Kraus <achimkraus@gmx.net> Tue, 22 September 2020 05:21 UTC
Return-Path: <achimkraus@gmx.net>
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 336F43A139E for <tls@ietfa.amsl.com>; Mon, 21 Sep 2020 22:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net
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 mvbxgfyqfrQU for <tls@ietfa.amsl.com>; Mon, 21 Sep 2020 22:21:54 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 020953A13D7 for <tls@ietf.org>; Mon, 21 Sep 2020 22:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1600752106; bh=NX8OrConzFfMi2Hhxlv1CPo48ym9SuF+hpCdSwDjrAc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=T+3oRJcxGZtoX/8XDJPNAU1sEuZ5TDdTVt2pqPOdZ1pmLk7WF5H2qlhUU9sem35nF U8reP4dJj0scv9zxr6kGJEBuBBrSMEnYFPKWNbMhAUIItUgakZAcEdluC4BY57iflA v/Upla8YdUW39afJBEqk5P1sPPJTvtyRV3orqNEc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([88.64.89.22]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M8hV5-1kOjU308av-004j3F; Tue, 22 Sep 2020 07:21:46 +0200
To: Pascal Urien <pascal.urien@gmail.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, tls@ietf.org
References: <77039F11-188E-4408-8B39-57B908DDCB80@ericsson.com> <1600516093048.75181@cs.auckland.ac.nz> <2f2ecb30-bef5-414a-8ff7-d707d773c7ea@www.fastmail.com> <AM0PR08MB3716AAADBE7D2A6F3E29664BFA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <CAEQGKXQdVO_SAVT1kciiH1EgQqenaYDeXnFD9gfa3BKTNFBjig@mail.gmail.com> <AM0PR08MB3716D1CD8D13C68C91ADE322FA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <CAEQGKXS-HyESGOU9iiYCXKdJk-wMkDnO4eYK2iVs21E3gtVOPQ@mail.gmail.com> <AM0PR08MB3716239A095ED0F7D6072CE4FA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <CAEQGKXQ9aNOYtRT8ZUbWT81wjYeqZzQOx_McSefTedG6Lpbr_A@mail.gmail.com> <CAEQGKXSA6SgGqxUbwik3twesNC+zFm+ek3f+5rjbAQBm_bz0Zg@mail.gmail.com> <89e3b32e-82d6-3a44-7b48-1cc8d0c12496@gmx.net> <CAEQGKXRvJtLHAbGJ-ViuHGV1tYQANV9sCR0dz1AoGRg3Jcc4Gw@mail.gmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <9d1b4f3c-5a90-375c-b6e4-67767cd50020@gmx.net>
Date: Tue, 22 Sep 2020 07:21:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAEQGKXRvJtLHAbGJ-ViuHGV1tYQANV9sCR0dz1AoGRg3Jcc4Gw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:GKYwou0WJJmKnaco/ztafe/P1q54zh7GuKGM0fYWjZsAHJft7do CRPCtKpYJxfy/fNf0Hv1Ni/pxtShLimRsNvq0BcEdTXTKc/bPhY2+ffFF2PsGjFFU88DiXI AyNBbp7npl88CqxqyqU/c/pT+pbqvx2gGW3ikD2q3BDtSXPChgfh2unyJz+ZoU5put4+1HD S8bEm9NzpnNXQQUkq05Ug==
X-UI-Out-Filterresults: notjunk:1;V03:K0:9mbFt0WfJE8=:6IBz6CqqgOq8vMz2+5uA8d bLx6P5Yyix8UukveCYEVnXaqlj/0WOm89nf0THnjM06qDDZCow82oPqSlqcJDzJQhWPCWtb62 BL19o24GTpneJWOWFlara1zFa8+9loqm5qG7lXbkmsqypsjK2muxUE7NuZM4EIaqzMed5//Ab PPQL4d4x9o9Z1ikQLjRv5zd4+WdqWg++j1ezwsIFb5vTY+0SpOxsMMIW+SUJNeu4Quddzwiwv K5Q2AHnazsjcan6O//j07ObxwBBPsYpvxBThbB9I9DajS1lYmQlS7UOELrrASy7qFQy5o36KH H169vaffCDK04b5CSBPyh5Nk8FDBGioXwAOI4TJJ1kOqxMh5iJdjS8BevmJZ3iyJdIAmH7DKO RNeViLN1o0pxB8wlBM0r03xLNUfWZGOh8GN2rHpKC7WaFIARTau1Wn/Y12jBmYTXkMAacIdkZ fzsn6HxdwJWokZG9KOaSqh7SjYwfYT98+rwp4D0nRfJsY7Ci345uP7q4nk8DjPMKYW1alo6W3 5OXClmzRznz/UhqQIaMAw3WJRAdqWXGotwhQn+X3y5Bxifdm9T7LhgfIiTp0hF8huxvQRn1F4 UfzC7ZRqoOSHChmY04cR6BgTrtSUP5+n4Vfxu6azJKr/0+06vXZrrls6pTuJbga8v4fWN0i6V 9pn7f7XK4eloyEj/Gym3Bfk7o+jWnVuEUAfriY7ypsTGzVatyPBVqws0x2zOkDokKr2ATfGx3 8T04IW+zrHVBzcPuKPQK25OKtpbQ9L0AMUFZMOaOk0JxLljqSGP+c0jp2fbmZsgVHmLjbpe2t hL/eHVxgyIWZTlBfvJ98G+OD+AGANBBCKBn2wrr9dediJ6HK+1d5uFhQZRmnMFlselk5xwqSv Swff7nV3i5YaKEGRgrSJ/4MZEvhFn4Z/z8YBUVxPTpqk/85H9lXqCvnsUQiGIaukTgyS7KZsA tqZhdEdwo31ROCvasbr5eAKhldX+zagBYPTrR/qPdJzhGWG0Zo2PHWx9vvoaXUtBlOaH4Sa1c jhu9pMmvD8BizJ608s5EAxEDkPTnH2nJl7iHA+yU7ciwUscAbkb+zrNhVAocwsTRxyv5OTcWL q60051ytma9GCIt9ncncHmz1cfu6IFUGshWivDnoBLFmxYzwZVyQPtAoTVTHBieoyVvBZhASH Ii+/84T58UIPTbfxHrB1z46c0E3GRzbj+dWcoq52wYXQRA/nKfiyg0dbRS61cZJDRA85tp+wF aoC98F0my/WUKBIs/Z3KZ1akBOEwbebQ2uqHRlg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TCZIm4tUz71Kc1a5Z65kH2RegiM>
Subject: Re: [TLS] The future of external PSK in TLS 1.3
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, 22 Sep 2020 05:21:56 -0000
Hi Pascal, > But what about heath devices, autonomous cars, nuclear plants, > blockchain transfers ?. Maybe, they are not in the IoT scope... Agreed. Therefore I wrote >> Isn't it always a question of what to protect in which environment? Maybe, one column with recommended (Y/N/<blank>), is not enough. ############################## Note If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases ############################## best regards Achim Am 21.09.20 um 22:57 schrieb Pascal Urien: > Hi Achim > > Your local network "light bulb" is likely not a big issue > > But what about heath devices, autonomous cars, nuclear plants, > blockchain transfers ?. Maybe, they are not in the IoT scope... > > Best Regards > > Pascal > > > Le lun. 21 sept. 2020 à 19:57, Achim Kraus <achimkraus@gmx.net > <mailto:achimkraus@gmx.net>> a écrit : > > Hi Pascal, > > that using these ISO 7816 card is fast and save, doesn't say too much > about the use-case without that card, or? For sure, there are > micro-controller, which are also equipped with hw-ecc or hw-rsa. And > there are more secure-devices protecting credentials. But there are also > still ones without. > I'm not sure, if I want spend too much money in my local network "light > bulb". Isn't it always a question of what to protect in which > environment? > > best regards > Achim > > Am 21.09.20 um 14:53 schrieb Pascal Urien: > > tls-se memory footprint is > > flash 《 40KB > > ram 《 1KB > > > > time to open a tls session 1.4 seconds > > > > > > Le lun. 21 sept. 2020 à 14:47, Pascal Urien > <pascal.urien@gmail.com <mailto:pascal.urien@gmail.com> > > <mailto:pascal.urien@gmail.com <mailto:pascal.urien@gmail.com>>> > a écrit : > > > > hi Hannes > > > > no openssl or wolfssl are used as client in order to check > > interoperability with tls-se server > > > > tls-se is of course a specific implémentation for tls13 server in > > javacard..it is written in java but an ôter implémentation is > > written in c for constraint notes. as written in the draft tls-se > > implementation has three software blocks: crypto lib, tls state > > machine, and tls lib > > > > > > > > Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig > > <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com> > <mailto:Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com>>> a écrit : > > > > Hi Pascal, ____ > > > > __ __ > > > > are you saying that the stack on the secure element uses > WolfSSL > > or OpenSSL? I am sure that WolfSSL works well but for > code size > > reasons I doubt OpenSSL is possible. Can you confirm? ____ > > > > __ __ > > > > In case of WolfSSL, you have multiple options for > credentials, > > including plain PSK, PSK-ECDHE, raw public keys, and > > certificates as I noted in my mail to the UTA list: ____ > > > > > https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/____ > > > > __ __ > > > > Ciao____ > > > > Hannes____ > > > > __ __ > > > > *From:* Pascal Urien <pascal.urien@gmail.com > <mailto:pascal.urien@gmail.com> > > <mailto:pascal.urien@gmail.com > <mailto:pascal.urien@gmail.com>>> > > *Sent:* Monday, September 21, 2020 2:01 PM > > *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com> > > <mailto:Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com>>> > > *Cc:* Filippo Valsorda <filippo@ml.filippo.io > <mailto:filippo@ml.filippo.io> > > <mailto:filippo@ml.filippo.io > <mailto:filippo@ml.filippo.io>>>; tls@ietf.org <mailto:tls@ietf.org> > <mailto:tls@ietf.org <mailto:tls@ietf.org>> > > *Subject:* Re: [TLS] The future of external PSK in TLS > 1.3____ > > > > __ __ > > > > Hi Hannes____ > > > > __ __ > > > > Yes it has been tested with several 3.04 Javacards > > commercially available____ > > > > __ __ > > > > In the draft > https://tools.ietf.org/html/draft-urien-tls-se-00 > > Section 5-ISO 7816 Use Case, the exchanges are done > with the > > existing implementation____ > > > > __ __ > > > > TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or > > Arduino+Ethernet boards ____ > > > > __ __ > > > > For client software we use OPENSSL or WolfSSL____ > > > > __ __ > > > > Pascal____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > __ __ > > > > Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig > > <Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com> <mailto:Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com>>> a > > écrit :____ > > > > Hi Pascal, > > > > Thanks for the pointer to the draft. > > > > Since I am surveying implementations for the update > of RFC > > 7925 (see > > https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) > > I was wondering whether there is an implementation of > this > > approach. > > > > Ciao > > Hannes > > > > > > From: Pascal Urien <pascal.urien@gmail.com > <mailto:pascal.urien@gmail.com> > > <mailto:pascal.urien@gmail.com > <mailto:pascal.urien@gmail.com>>> > > Sent: Monday, September 21, 2020 11:44 AM > > To: Hannes Tschofenig <Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com> > > <mailto:Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com>>> > > Cc: Filippo Valsorda <filippo@ml.filippo.io > <mailto:filippo@ml.filippo.io> > > <mailto:filippo@ml.filippo.io > <mailto:filippo@ml.filippo.io>>>; tls@ietf.org <mailto:tls@ietf.org> > > <mailto:tls@ietf.org <mailto:tls@ietf.org>> > > Subject: Re: [TLS] The future of external PSK in TLS 1.3 > > > > Hi All > > > > Here is an example of PSK+ECDHE for IoT > > > > https://tools.ietf.org/html/draft-urien-tls-se-00 uses > > TLS1.3 server PSK+ECDHE for secure elements > > > > The security level in these devices is as high as EAL5+ > > > > The computing time is about 1.4s for a PSK+ECDHE session > > (AES-128-CCM, + secp256r1) > > > > The real critical resource is the required RAM size, less > > than 1KB in our experiments > > > > The secure element only needs a classical TCP/IP > interface > > (i.e. sockets like) > > > > Trusted PSK should avoid selfie attacks > > > > Pascal > > > > > > > > Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig > > <mailto:Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com> > > <mailto:Hannes.Tschofenig@arm.com > <mailto:Hannes.Tschofenig@arm.com>>> a écrit : > > Hi Filippo, > > > > • Indeed, if the SCADA industry has a particular > need, they > > should profile TLS for use in that industry, and not > require > > we change the recommendation for the open Internet. > > > > We have an IoT profile for TLS and it talks about the > use of > > PSK, see https://tools.ietf.org/html/rfc7925 > > > > On the “open Internet” (probably referring to the Web > usage) > > you are not going to use PSKs in TLS. There is a separate > > RFC that provides recommendations for that > environmnent, see > > RFC 752. That RFC is currently being revised, see > > https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/ > > > > Ciao > > Hannes > > > > IMPORTANT NOTICE: The contents of this email and any > > attachments are confidential and may also be > privileged. If > > you are not the intended recipient, please notify the > sender > > immediately and do not disclose the contents to any other > > person, use it for any purpose, or store or copy the > > information in any medium. Thank you. > > _______________________________________________ > > TLS mailing list > > mailto:TLS@ietf.org <mailto:TLS@ietf.org> > <mailto:TLS@ietf.org <mailto:TLS@ietf.org>> > > https://www.ietf.org/mailman/listinfo/tls > > IMPORTANT NOTICE: The contents of this email and any > > attachments are confidential and may also be > privileged. If > > you are not the intended recipient, please notify the > sender > > immediately and do not disclose the contents to any other > > person, use it for any purpose, or store or copy the > > information in any medium. Thank you.____ > > > > IMPORTANT NOTICE: The contents of this email and any > attachments > > are confidential and may also be privileged. If you are > not the > > intended recipient, please notify the sender immediately > and do > > not disclose the contents to any other person, use it for any > > purpose, or store or copy the information in any medium. > Thank you. > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > >
- Re: [TLS] The future of external PSK in TLS 1.3 Peter Gutmann
- [TLS] The future of external PSK in TLS 1.3 John Mattsson
- Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda
- Re: [TLS] The future of external PSK in TLS 1.3 Viktor Dukhovni
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda
- Re: [TLS] The future of external PSK in TLS 1.3 David Woodhouse
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Salz, Rich
- Re: [TLS] The future of external PSK in TLS 1.3 David Benjamin
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 David Benjamin
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Lanlan Pan
- Re: [TLS] The future of external PSK in TLS 1.3 Peter Gutmann
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Salz, Rich
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Watson Ladd
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Rob Sayre
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Watson Ladd
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Salz, Rich
- Re: [TLS] The future of external PSK in TLS 1.3 Rob Sayre