Re: [TLS] The future of external PSK in TLS 1.3
Pascal Urien <pascal.urien@gmail.com> Mon, 28 September 2020 11:12 UTC
Return-Path: <pascal.urien@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 E29C73A0FD9; Mon, 28 Sep 2020 04:12:39 -0700 (PDT)
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=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 J6LGWEIkbMrG; Mon, 28 Sep 2020 04:12:37 -0700 (PDT)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 A22F53A0FD5; Mon, 28 Sep 2020 04:12:37 -0700 (PDT)
Received: by mail-ua1-x932.google.com with SMTP id h15so2043975uab.3; Mon, 28 Sep 2020 04:12:37 -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=zXbSFzJiiaHbykE/sHIr5OAzY6O07LP4ICpR7M74nrk=; b=Uqnw8vGruwUqqHNmRuGJ32xiU6yhJw1Bvi7cda54oACe8Vz2hUL13JqAV9j5W44gRa fvrUoWPpmcYgNyHLogQrwFQ93d2SQHULzWFtMLn8syx1ICBhoYzd1JAS8SWsbpU6nhff 4i0iSZ0Q4difiVNypj6MdTuFLsCLS2EuDjpPDPlhFBz2ZB7m7465Mg9SMpckJAIdLDB6 yDztISjlDTUGSom8iHVL8OVScmNTH2aQtAdbVlje6b6huriBYwXSxH+tqMwU/EoA5pXS BuZSFwjidgPPF7w+Je8flUHtE71Bhykc2Yeq4wPSSRL7RLNk5OHgUEV/C54L5qGTcSIm NIQw==
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=zXbSFzJiiaHbykE/sHIr5OAzY6O07LP4ICpR7M74nrk=; b=pSMQclKFndoY3Db0ordIi9I9t14tXQRna96yIJInMVeDpHE3vZ39S++u2Utibf8cfJ 7XH3WnegnnI9iiTgC77LBaM+INKaffDlvkCvj1pWV0OU2nMZWcmffFLMjbwc2Is0CJjB LdPbMMnuuvlIVTKpjm7qhxvoYOD4ryAhE+nlLYFc9Y2aWzEToIL+BXA+GhaXiQdo2Kz1 FDOIL0TVOU4Y9yTWSXvSBEDlI5IbQWjLf2K2bcmKrE+aMwUp0GCnbx0NaBxLKJwoS9UK BPPlwWcSQ3zQuYPJh3L+Yn3ME56HcbPeFJUiFiT0zOFTmIwwC8iWBov2DlhwNK5JbgeP i1/w==
X-Gm-Message-State: AOAM531RLBs+DxV8CFSVwD/UBQO/QNt+tB6Vbyow1zw/ZA4o0wnJ0+Uy Kq2ki8FXTLKT4Y3K+nWQxsgrEnj0QuY/1hrDOrJWZO921v9wiA==
X-Google-Smtp-Source: ABdhPJydpKEhc5UTN8iIsjhng2zTkaQo7NKEcIzdhGvxl4A7Lj3JOCV5dW3G5MoiRWivlx4lfd6IO6PakfLS6SUNYws=
X-Received: by 2002:a9f:35e3:: with SMTP id u32mr254549uad.99.1601291556528; Mon, 28 Sep 2020 04:12:36 -0700 (PDT)
MIME-Version: 1.0
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> <AM0PR08MB37164FAB5CF915CF69401A9FFA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <CAEQGKXT3SURvBa52w6H1j8cNbfpzLJg6yEg1wTxpM+0ZQGpTYQ@mail.gmail.com> <AM0PR08MB37167874EF77202D6ECE0A23FA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB37167874EF77202D6ECE0A23FA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Pascal Urien <pascal.urien@gmail.com>
Date: Mon, 28 Sep 2020 13:12:23 +0200
Message-ID: <CAEQGKXQrWw94CahjodXOY-o-E3URcHt9izpzqkJcwDzNqussLw@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: tls@ietf.org, uta@ietf.org
Content-Type: multipart/alternative; boundary="00000000000068a42f05b05dbe42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8Nu8P0UfLq2tAz23FsB1d0xdfdI>
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: Mon, 28 Sep 2020 11:12:40 -0000
Hi Hannes The TLS-SE code is now published https://github.com/purien/TLS-SE It also comprises software tools for testing This code is a TLS1.3 ECDH-PSK server for a javacard as specified in https://tools.ietf.org/html/draft-urien-tls-se-01 It has been tested with several javacard 3.04 This code also implements https://tools.ietf.org/html/draft-urien-tls-im-03 Pascal Le lun. 21 sept. 2020 à 17:05, Hannes Tschofenig <Hannes.Tschofenig@arm.com> a écrit : > > > Ping me when it becomes available or post a link to the UTA mailing list. > > > > *From:* Pascal Urien <pascal.urien@gmail.com> > *Sent:* Monday, September 21, 2020 4:18 PM > *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com> > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > > > > Not at this moment but the code will be pusblished on github > > > > Le lun. 21 sept. 2020 à 15:30, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> a écrit : > > Thanks for the details. > > > > Is the code for the tls13 server on the javacard open source? > > > > Ciao > > Hannes > > > > > > *From:* Pascal Urien <pascal.urien@gmail.com> > *Sent:* Monday, September 21, 2020 2:54 PM > *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com> > *Cc:* Filippo Valsorda <filippo@ml.filippo.io>; tls@ietf.org > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > > > > 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> 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> 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> > *Sent:* Monday, September 21, 2020 2:01 PM > *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com> > *Cc:* Filippo Valsorda <filippo@ml.filippo.io>; 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> 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> > Sent: Monday, September 21, 2020 11:44 AM > To: Hannes Tschofenig <Hannes.Tschofenig@arm.com> > Cc: Filippo Valsorda <filippo@ml.filippo.io>; 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> 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 > 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. > > 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. >
- 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