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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> *Sent:* Monday, September 21, 2020 2:01 PM
> *To:* Hannes Tschofenig <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> *Cc:* Filippo Valsorda <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>; [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> *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
> <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> Sent: Monday, September 21, 2020 11:44 AM
> To: Hannes Tschofenig <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> Cc: Filippo Valsorda <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>; [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> 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:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> 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:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> 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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
