Re: [TLS] The future of external PSK in TLS 1.3

Pascal Urien <pascal.urien@gmail.com> Mon, 21 September 2020 12:54 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 835213A0E31 for <tls@ietfa.amsl.com>; Mon, 21 Sep 2020 05:54:08 -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 lC5UHYuk9kHO for <tls@ietfa.amsl.com>; Mon, 21 Sep 2020 05:54:06 -0700 (PDT)
Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 40CDE3A0E1B for <tls@ietf.org>; Mon, 21 Sep 2020 05:54:06 -0700 (PDT)
Received: by mail-vk1-xa30.google.com with SMTP id c63so3321548vkb.7 for <tls@ietf.org>; Mon, 21 Sep 2020 05:54:06 -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=FlwWiPMRrk/TSw1rYRMfHwL0ozkQ1jYDsynkZrf5724=; b=K7NsbkHcQ70Zi+ILbMKnV5j4qW/0LogumY1qykCAoqmZERV1geruEcR96kzNLKz9lo dsMYgPpLhVp7casRvCkbf2tGiYZ49aHHSMRjY/IX8r33GeDbvH3w7Umk/XO1nEcvr/Ep y5GPFl/358fnPXiNxFPZLHVKmkCrYrS/6iCjahPL9iwZr8L3cDsXRnIXvAt49DhTUc2w K79dfNlrBoAGvie82/uNSE9TlLbyewQB4gr4HnH6QM5zyRgzPFf6s5KwbOxzclQv5ryx IRxrW8HS5jO+28Ubwufxg6b9qKEuYMEqiqg1kwrZ+Rjxb6ZurCQ0aj0m12xmfMhqyZt/ eF/w==
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=FlwWiPMRrk/TSw1rYRMfHwL0ozkQ1jYDsynkZrf5724=; b=d3+zGvO67PAGxDONZyDJLpZs1QGBXkaPlpUPA8falUuzDQHbWIPjzWj5RU988Lqkf4 korbTaC/Y7LPEG1CSjAZJokgb9guC/XQ/naCH3qIvBGoUhpDBlNjUgXSJ3gUKUPwG2Jh OXwP3qqXJVvmTBJscfXq4j/kvGtewlsdW9pnUiLsNSa5+hUX/uJdT7JsEm0g89yFIO7h tneJyFHjzgP6Muw5W820Zd0zt1I9sdZM+MHdJTLGaZLrHmDT+HVVv002g6P5Ja/crq/P 7zf+7i/xTUYgsE/7T6C5BqGUApmshrTL3DdK4SSD106qvmSTNwgFNcmbQEglIRJ2mY/H pWhg==
X-Gm-Message-State: AOAM531pathcqh+5T/63gX0YgC38TUR0E2Z9s+ApYZKIvwEoCpifJ7kl 84ruH+44A7xNOXd953ADIpzb7wimh09D9+Hl0n5kfOujG3s=
X-Google-Smtp-Source: ABdhPJyPIjGq+OiqHfsXiGKYad7Pb0oYNIVvEXQxjdfO3J5ptjD811yOIqAweG1gFdDIAcgk5aM1czcBoLX4Mk5d8wo=
X-Received: by 2002:a1f:7f15:: with SMTP id o21mr18392118vki.20.1600692845305; Mon, 21 Sep 2020 05:54:05 -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>
In-Reply-To: <CAEQGKXQ9aNOYtRT8ZUbWT81wjYeqZzQOx_McSefTedG6Lpbr_A@mail.gmail.com>
From: Pascal Urien <pascal.urien@gmail.com>
Date: Mon, 21 Sep 2020 14:53:53 +0200
Message-ID: <CAEQGKXSA6SgGqxUbwik3twesNC+zFm+ek3f+5rjbAQBm_bz0Zg@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Filippo Valsorda <filippo@ml.filippo.io>, tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000070650405afd258ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nLF_8ZRywmpe8kbu4gnHQ3JavN4>
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, 21 Sep 2020 12:54:09 -0000

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>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>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.
>>
>