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

[Rob Sayre]

On Wed, Sep 30, 2020 at 8:12 AM Salz, Rich  wrote:

> PSK is in the RFC. And in fact we made a point of unifying it and other
> mechanisms in the protocol.
>

I don't really feel strongly about it (because it doesn't matter to me),
but it could be taken out of the 8446-bis document.

I might also add that not all sections of every document are viewed with
equal respect.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

PSK is in the RFC. And in fact we made a point of unifying it and other 
mechanisms in the protocol.

If someone wants to say PSK isn't recommended, then they need to do the work to 
get an RFC published that says so.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

> On Sep 30, 2020, at 08:51, Watson Ladd  wrote:
> 
> Recommended N doesn't stop people from using PSK when appropriate if
> other constraints make it the most appropriate choice.

It does, because this "stop" occurs on a business level, not the technical... 
Realm of advertisement, claimed security and compliance, etc. Where a business 
manager is afraid to scare potential customers away by implementing/selling 
something "not recommended", because even if he himself managed to read the doc 
to the end and understand what that's about, he cannot trust all the customers 
to do so... Plus the potential legal cases when a customer who was cyber-hit, 
sues the manufacturer because he "did something against recommendations"... 
That's not your favorite Ivory tower, and not a peer-reviewed academic 
publication/conference. 

Now, since it's a rough morning and I feel grumpy - let me be blunt, and say 
that IMHO this whole "recommend" idea sounds *stupid*. Recommended by who and 
for who? WT... do the "recommenders" know about the spectrum of use cases? 
Based on the above exchange - not a lot. If you want to "recommend" for the Web 
browsers (which seems a fairly safe niche to pontificate) - say so explicitly, 
and enjoy. Otherwise - 


> 
>> 
>> In discussions in the IETF I notice for some the IoT computing world starts 
>> with Cortex A-class devices, as they are found in Raspberry Pis, tablets and 
>> phones. Those are high performance processors where crypto is lightning 
>> fast. But don't forget the other family of processors, of which there are 
>> probably more than a 80 billion out in the wild already.
>> 
>> Ciao
>> Hannes
>> 
>> -Original Message-
>> From: TLS  On Behalf Of Watson Ladd
>> Sent: Wednesday, September 30, 2020 2:29 AM
>> To: Blumenthal, Uri - 0553 - MITLL 
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>> 
>>> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL 
>>>  wrote:
>>> 
>>> I share Achim's concerns.
>>> 
>>> But I believe the explanations will turn out mostly useless in the real 
>>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>>> something "not recommended".
>>> 
>>> In one word: bad.
>> 
>> Why is PSK so necessary? There are very few devices that can't handle the 
>> occasional ECC operation.  The key management and forward secrecy issues 
>> with TLS-PSK are real. Steering applications that can afford the CPU away 
>> from PSK and toward hybrid modes is a good thing and why this registry 
>> exists imho.
>> 
>> 
>> --
>> Astra mortemque praestare gradatim
>> 
>> ___
>> TLS mailing list
>> 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.
> 
> 
> 
> -- 
> Astra mortemque praestare gradatim


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Wed, Sep 30, 2020 at 3:32 AM Hannes Tschofenig
 wrote:
>
> Hi Watson,
>
> through Arm I deal with customers who use microcontrollers that have all 
> sorts of limitations. So, the question is not so much whether these 
> limitations exist but rather whether you care and what exactly these 
> limitations are (CPU processing, RAM, flash memory, energy, networking 
> bandwidth, cost, physical size limitations, limitations caused by the 
> environment these devices operate in, etc.).
>
> PSK is the most efficient mechanism we have. Not only does it perform 
> extremely well when it comes to CPU performance it also reduces the size of 
> code size, and RAM utilization. Also the bandwidth requirements are minimal.
> Of course, regular 32-bit microcontrollers are all able to do public key 
> crypto operations (see a presentation I did a while ago in the LWIG group -- 
> https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf). There are, 
> however, some environments where you just cannot wait multiple seconds for a 
> handshake to complete.

This presentation doesn't mention many well known optimization
opportunities, and seems to show an M3+ device having ~100ms for an
operation. Obviously this is more expensive than the M0, but in some
cases it's worth paying. Then of course one can optimize the handshake
through extensions. RSA verification (not signing) is very cheap.

Recommended N doesn't stop people from using PSK when appropriate if
other constraints make it the most appropriate choice.

>
> In discussions in the IETF I notice for some the IoT computing world starts 
> with Cortex A-class devices, as they are found in Raspberry Pis, tablets and 
> phones. Those are high performance processors where crypto is lightning fast. 
> But don't forget the other family of processors, of which there are probably 
> more than a 80 billion out in the wild already.
>
> Ciao
> Hannes
>
> -Original Message-
> From: TLS  On Behalf Of Watson Ladd
> Sent: Wednesday, September 30, 2020 2:29 AM
> To: Blumenthal, Uri - 0553 - MITLL 
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL 
>  wrote:
> >
> > I share Achim's concerns.
> >
> > But I believe the explanations will turn out mostly useless in the real 
> > world, as the "lawyers" of the industry are guaranteed to steer away from 
> > something "not recommended".
> >
> > In one word: bad.
>
> Why is PSK so necessary? There are very few devices that can't handle the 
> occasional ECC operation.  The key management and forward secrecy issues with 
> TLS-PSK are real. Steering applications that can afford the CPU away from PSK 
> and toward hybrid modes is a good thing and why this registry exists imho.
>
>
> --
> Astra mortemque praestare gradatim
>
> ___
> TLS mailing list
> 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.



-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi Rob,

From the email Watson sent I got the impression that he does not believe there 
are CPU performance constrained devices.
Since I work in that industry I shared my experience.

I am uncertain how changing the name help us solve such an underlying problem. 
Maybe it was meant to be a joke.

Ciao
Hannes


From: Rob Sayre 
Sent: Wednesday, September 30, 2020 10:20 AM
To: Hannes Tschofenig 
Cc: Watson Ladd ; Blumenthal, Uri - 0553 - MITLL 
; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi Watson,

through Arm I deal with customers who use microcontrollers that have all sorts 
of limitations.

One way to solve this is to name it something other than "TLS", even if it 
shares some code and/or ideas.

thanks,
Rob
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
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

For me this seems to be a philosophic dispute about the
"philosopher's stone".

So, not too serious:

Great idea!

just add the number of the year to the term TLS for the main stream!
And leave the term TLS without the year numbers to those, who want to
use recommended stuff from last year also next year.

best regards
Achim Kraus

Am 30.09.20 um 10:19 schrieb Rob Sayre:

On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Watson,

through Arm I deal with customers who use microcontrollers that have
all sorts of limitations.


One way to solve this is to name it something other than "TLS", even if
it shares some code and/or ideas.

thanks,
Rob

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Sayre]

On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Watson,
>
> through Arm I deal with customers who use microcontrollers that have all
> sorts of limitations.
>

One way to solve this is to name it something other than "TLS", even if it
shares some code and/or ideas.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi Uri,

I would even argue that key management is less challenging for IoT deployments 
because devices typically talk to a single device management server only.
So, the communication patterns are pretty simplistic compared to a generic 
computing device.
RFC 7452 talks about this topic (see the device-to-cloud and device-to-gateway 
pattern).

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Wednesday, September 30, 2020 2:48 AM
To: Watson Ladd 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Because PSK is one of the affordable and reliable quantum-resistant key 
exchanges that work *today*? And done environments do not wish to do any EC 
operations.

Yes, key management issues are real. Those who need it, understand the 
implications.

Regards,
Uri

> On Sep 29, 2020, at 20:30, Watson Ladd  wrote:
>
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
>  wrote:
>>
>> I share Achim's concerns.
>>
>> But I believe the explanations will turn out mostly useless in the real 
>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>> something "not recommended".
>>
>> In one word: bad.
>
> Why is PSK so necessary? There are very few devices that can't handle
> the occasional ECC operation.  The key management and forward secrecy
> issues with TLS-PSK are real. Steering applications that can afford
> the CPU away from PSK and toward hybrid modes is a good thing and why
> this registry exists imho.
>
>
> --
> Astra mortemque praestare gradatim
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
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi Watson,

through Arm I deal with customers who use microcontrollers that have all sorts 
of limitations. So, the question is not so much whether these limitations exist 
but rather whether you care and what exactly these limitations are (CPU 
processing, RAM, flash memory, energy, networking bandwidth, cost, physical 
size limitations, limitations caused by the environment these devices operate 
in, etc.).

PSK is the most efficient mechanism we have. Not only does it perform extremely 
well when it comes to CPU performance it also reduces the size of code size, 
and RAM utilization. Also the bandwidth requirements are minimal.
Of course, regular 32-bit microcontrollers are all able to do public key crypto 
operations (see a presentation I did a while ago in the LWIG group -- 
https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf). There are, 
however, some environments where you just cannot wait multiple seconds for a 
handshake to complete.

In discussions in the IETF I notice for some the IoT computing world starts 
with Cortex A-class devices, as they are found in Raspberry Pis, tablets and 
phones. Those are high performance processors where crypto is lightning fast. 
But don't forget the other family of processors, of which there are probably 
more than a 80 billion out in the wild already.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Watson Ladd
Sent: Wednesday, September 30, 2020 2:29 AM
To: Blumenthal, Uri - 0553 - MITLL 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL 
 wrote:
>
> I share Achim's concerns.
>
> But I believe the explanations will turn out mostly useless in the real 
> world, as the "lawyers" of the industry are guaranteed to steer away from 
> something "not recommended".
>
> In one word: bad.

Why is PSK so necessary? There are very few devices that can't handle the 
occasional ECC operation.  The key management and forward secrecy issues with 
TLS-PSK are real. Steering applications that can afford the CPU away from PSK 
and toward hybrid modes is a good thing and why this registry exists imho.


--
Astra mortemque praestare gradatim

___
TLS mailing list
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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

Hi list,

exchanging arguments for N or Y again seems for me to be in vain.

Therefore my proposal to add the Y-period. For me that documents more
the fact, that the security trade off between security and resources is
changing over time. And so will the implementations and deployments.

best regards
Achim Kraus

Am 30.09.20 um 02:48 schrieb Blumenthal, Uri - 0553 - MITLL:

Because PSK is one of the affordable and reliable quantum-resistant key 
exchanges that work *today*? And done environments do not wish to do any EC 
operations.

Yes, key management issues are real. Those who need it, understand the 
implications.

Regards,
Uri


On Sep 29, 2020, at 20:30, Watson Ladd  wrote:

On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
 wrote:


I share Achim's concerns.

But I believe the explanations will turn out mostly useless in the real world, as the 
"lawyers" of the industry are guaranteed to steer away from something "not 
recommended".

In one word: bad.


Why is PSK so necessary? There are very few devices that can't handle
the occasional ECC operation.  The key management and forward secrecy
issues with TLS-PSK are real. Steering applications that can afford
the CPU away from PSK and toward hybrid modes is a good thing and why
this registry exists imho.


--
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

>  applications that can afford the CPU

a) Not all applications can afford the CPU
b) It's not just about CPU; there are use cases where bandwidth is also an 
issue.


> On Sep 29, 2020, at 5:29 PM, Watson Ladd  wrote:
> 
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
> mailto:u...@ll.mit.edu>> wrote:
>> 
>> I share Achim's concerns.
>> 
>> But I believe the explanations will turn out mostly useless in the real 
>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>> something "not recommended".
>> 
>> In one word: bad.
> 
> Why is PSK so necessary? There are very few devices that can't handle
> the occasional ECC operation.  The key management and forward secrecy
> issues with TLS-PSK are real. Steering applications that can afford
> the CPU away from PSK and toward hybrid modes is a good thing and why
> this registry exists imho.
> 
> 
> -- 
> Astra mortemque praestare gradatim
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Because PSK is one of the affordable and reliable quantum-resistant key 
exchanges that work *today*? And done environments do not wish to do any EC 
operations.

Yes, key management issues are real. Those who need it, understand the 
implications.

Regards,
Uri

> On Sep 29, 2020, at 20:30, Watson Ladd  wrote:
> 
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
>  wrote:
>> 
>> I share Achim's concerns.
>> 
>> But I believe the explanations will turn out mostly useless in the real 
>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>> something "not recommended".
>> 
>> In one word: bad.
> 
> Why is PSK so necessary? There are very few devices that can't handle
> the occasional ECC operation.  The key management and forward secrecy
> issues with TLS-PSK are real. Steering applications that can afford
> the CPU away from PSK and toward hybrid modes is a good thing and why
> this registry exists imho.
> 
> 
> -- 
> Astra mortemque praestare gradatim


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
 wrote:
>
> I share Achim's concerns.
>
> But I believe the explanations will turn out mostly useless in the real 
> world, as the "lawyers" of the industry are guaranteed to steer away from 
> something "not recommended".
>
> In one word: bad.

Why is PSK so necessary? There are very few devices that can't handle
the occasional ECC operation.  The key management and forward secrecy
issues with TLS-PSK are real. Steering applications that can afford
the CPU away from PSK and toward hybrid modes is a good thing and why
this registry exists imho.


-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I share Achim's concerns. 

But I believe the explanations will turn out mostly useless in the real world, 
as the "lawyers" of the industry are guaranteed to steer away from something 
"not recommended".

In one word: bad.

On 9/29/20, 12:31, "TLS on behalf of Achim Kraus"  wrote:

Hi list,

I'm still worrying about the "recommended" and the (mis-)interpretation
of that. I'm fine with the explanation

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

but, I feel uncomfortable considering too many decision makers will not
read that details. Though the "recommendation" is changing over the
time, I would feel more comfortable, if the N would be amended by the
Y-period.

e.g. N (was Y 2001-2015)

FMPOV, if someone reads that, it may explain, that the N is a recent one
and some use-case will still need some time to adapt for the new
recommendations.

best regards
Achim Kraus

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

Hi list,

I'm still worrying about the "recommended" and the (mis-)interpretation
of that. I'm fine with the explanation

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

but, I feel uncomfortable considering too many decision makers will not
read that details. Though the "recommendation" is changing over the
time, I would feel more comfortable, if the N would be amended by the
Y-period.

e.g. N (was Y 2001-2015)

FMPOV, if someone reads that, it may explain, that the N is a recent one
and some use-case will still need some time to adapt for the new
recommendations.

best regards
Achim Kraus

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Pascal Urien]

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 
a écrit :

>
>
> Ping me when it becomes available or post a link to the UTA mailing list.
>
>
>
> *From:* Pascal Urien 
> *Sent:* Monday, September 21, 2020 4:18 PM
> *To:* Hannes Tschofenig 
> *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.tschofe...@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 
> *Sent:* Monday, September 21, 2020 2:54 PM
> *To:* Hannes Tschofenig 
> *Cc:* Filippo Valsorda ; 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  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.tschofe...@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 
> *Sent:* Monday, September 21, 2020 2:01 PM
> *To:* Hannes Tschofenig 
> *Cc:* Filippo Valsorda ; 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.tschofe...@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 
> Sent: Monday, September 21, 2020 11:44 AM
> To: Hannes Tschofenig 
> Cc: Filippo Valsorda ; 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  hannes.tschofe...@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 rec

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

[Salz, Rich]

>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or 
NSS
>or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

Even if this is true (proof by assertion): So what?  Do those users not get to 
be a participant?



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Pascal Urien]

Hi all

Payment terminal use TLS (see for example
https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-for-POS-POI-Connections.docx
)

They are not WEB browser...may be IoT devices ? because they are connected



Le jeu. 24 sept. 2020 à 16:12, Filippo Valsorda  a
écrit :

> 2020-09-24 12:02 GMT+02:00 Peter Gutmann :
>
> Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
> generally "non-web use", [...]
>
>
> "The web" and "resource-constrained use cases which can't afford ECDH"
> feels like a false dichotomy, and it sounds unlikely that most M2M cases
> would fit the latter description.
>
> Anyway, David has made a better case than I did for marking psk_ke as N,
> like TLS_PSK_WITH_AES_128_GCM_SHA256 already is, so I don't want to
> distract from that thread.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Filippo Valsorda]

2020-09-24 12:02 GMT+02:00 Peter Gutmann :
> Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
> generally "non-web use", [...]

"The web" and "resource-constrained use cases which can't afford ECDH" feels 
like a false dichotomy, and it sounds unlikely that most M2M cases would fit 
the latter description.

Anyway, David has made a better case than I did for marking psk_ke as N, like 
TLS_PSK_WITH_AES_128_GCM_SHA256 already is, so I don't want to distract from 
that thread.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Nicely said, Peter.

To add: this is also the reason why the UTA group has been working on two sets 
of documents to capture profiles for the web (+email+IM) and IoT:
1) RFC 7590 and now draft-ietf-uta-tls13-iot-profile-00
2) RFC 7525 and now draft-sheffer-uta-rfc7525bis

-Original Message-
From: Peter Gutmann 
Sent: Thursday, September 24, 2020 12:02 PM
To: Filippo Valsorda ; Hannes Tschofenig 
; Carrick Bartle 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Filippo Valsorda  writes:

>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls
>or NSS or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

How do you know that?  I don't know of any data supporting that (I'd love to 
see it if you've got it, non-web use of TLS is the submerged part of the 
iceberg).  Taking "SCADA/IoT/etc" to be a placeholder for M2M or more generally 
"non-web use", an awful lot of TLS gets done outside the web, which uses it it 
completely different ways than web users do.  For example pretty much all of 
the fancy features in TLS 1.3, both in the core protocol and the endless 
add-ons, have no purpose or function in M2M communications.  So perhaps the 
answer is to have two sets of requirements, one for web use, one for everything 
else.  If you try for a one-size-fits-all approach you'll either get the 
currently widespread "TLS == the web" or have to include two mostly 
nonintersecting sets of options to cover web vs. M2M use.

Peter.


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
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Filippo Valsorda  writes:

>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS
>or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

How do you know that?  I don't know of any data supporting that (I'd love to
see it if you've got it, non-web use of TLS is the submerged part of the
iceberg).  Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
generally "non-web use", an awful lot of TLS gets done outside the web, which
uses it it completely different ways than web users do.  For example pretty
much all of the fancy features in TLS 1.3, both in the core protocol and the
endless add-ons, have no purpose or function in M2M communications.  So
perhaps the answer is to have two sets of requirements, one for web use, one
for everything else.  If you try for a one-size-fits-all approach you'll
either get the currently widespread "TLS == the web" or have to include two
mostly nonintersecting sets of options to cover web vs. M2M use.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Lanlan Pan]

David Benjamin  于2020年9月24日周四 上午12:32写道：

> It sounds like the registry may be confusing, so perhaps we, independent
> of the existing criteria for Y vs N, need to do a better job of presenting
> the information. That sounds like an orthogonal issue to whether psk_ke
> should be marked as recommended. There are plenty of recommended = N cipher
> suites in the registry that went through the IETF process. Security
> expectations evolve or we may make mistakes, and this is one tool we have
> for realigning things when that happens.
>
> Regarding how psk_ke should be marked, we have already marked the
> analogous cipher suite in TLS 1.2, TLS_PSK_WITH_AES_128_GCM_SHA256, as N.
> There is indeed a problem with the use of that mode. TLS 1.3 was intended
> to provide forward secrecy, and psk_ke does not do so. This is especially
> problematic with external PSKs, such as the smartcards folks mentioned,
> because it means all traffic hinges on a long-lived shared secret. The one
> footnote is that TLS 1.3 uses the same code points for external PSKs and
> resumption, and the precedent is less clear for resumption. But TLS 1.2
> resumption's lack of fresh key exchange is a well-documented problem that
> we happily fixed with psk_dhe_ke, so I'm perfectly fine extending the
> status to psk_ke with resumption.
>
> This is separate from psk_dhe_ke, which is analogous to TLS 1.2's
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256. That one is still recommended Y. For
> that matter, psk_dhe_ke is used in ECDH-ful resumption, so if the WG wants
> to say something stronger about external PSKs, we'd need a new values in
> that column anyway...
>

+1,  psk_ecdhe_ke is  useful at IoT scenario without certificate.

maybe we can just mark N for those who doesn't provide forward secrecy.


> (An aside, psk_dhe_ke and psk_ke are PSK key exchange modes, not cipher
> suites.)
>
> On Wed, Sep 23, 2020 at 12:03 PM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
>> Hi David,
>>
>>
>>
>> my problem is that the IANA registry only says “not recommended” but it
>> does not say for what environments these ciphersuites are not recommended.
>> Worse, it also wants to indicate whether the specification has gone through
>> the IETF process.
>>
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>> *From:* David Benjamin 
>> *Sent:* Wednesday, September 23, 2020 5:47 PM
>> *To:* Salz, Rich 
>> *Cc:* Hannes Tschofenig ; Filippo Valsorda <
>> fili...@ml.filippo.io>; Carrick Bartle ;
>> tls@ietf.org
>> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>>
>>
>>
>> There are two different code points involved in TLS 1.3 PSK, and I think
>> there may be some mixup here:
>>
>> 1. Whether TLS 1.3 psk_ke should be marked N
>>
>> 2. Whether TLS 1.3. psk_dhe_ke should be marked N
>>
>>
>>
>> Avoiding psk_ke does not remove compatibility with any authentication
>> method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
>> the handshake mixes an additional (EC)DH exchange into the key schedule.
>> We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
>> seems to me psk_ke with an external PSK should be similar. Handshakes using
>> psk_ke with an external PSK incorporate no secrets in the key exchange
>> apart from a (often long-lived) external symmetric secret. Compromise that
>> secret, and all traffic ever authenticated with that PSK is compromised.
>> Resumption PSKs use short-lived keys, so psk_ke is less immediately
>> disastrous but given the equivalent construction in TLS 1.2 has forward
>> secrecy issues
>> <https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it
>> as N across the board seems a good idea to me. (BoringSSL does not
>> implement psk_ke for this reason. Looks like Go and NSS do not implement it
>> either.)
>>
>>
>>
>> psk_dhe_ke I suppose depends on how one interprets "specific use case",
>> so I don't feel very strongly here.
>>
>>
>>
>> David
>>
>>
>>
>> On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich > 40akamai@dmarc.ietf.org> wrote:
>>
>> I agree with Hannes’s reasoning.
>>
>>
>>
>> I am also concerned about devolving TLS to be just Web browser/server.
>>
>>
>>
>> ___
>> TLS mailing list
>> 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.
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

I didn't mention SCADA at all. Did you mean to address this question to Filippo 
or Peter?


> On Sep 23, 2020, at 4:49 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Carrick, 
>  
> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.
>  
> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.
>  
> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  
>  
> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?
>  
> Ciao
> Hannes
>  
> From: Carrick Bartle  
> Sent: Monday, September 21, 2020 6:19 PM
> To: Hannes Tschofenig 
> Cc: Carrick Bartle ; Filippo Valsorda 
> ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> Can you justify your reasoning? 
>  
> Which part?
>  
> 
> 
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  <mailto:hannes.tschofe...@arm.com>> wrote:
>  
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
> Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
> Cc: tls@ietf.org <mailto:tls@ietf.org>
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  <mailto:fili...@ml.filippo.io>> wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  <mailto:pgut...@cs.auckland.ac.nz>>:
> John Mattsson  <mailto:40ericsson@dmarc.ietf.org>> writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> 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.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <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

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

[David Benjamin]

It sounds like the registry may be confusing, so perhaps we, independent of
the existing criteria for Y vs N, need to do a better job of presenting the
information. That sounds like an orthogonal issue to whether psk_ke should
be marked as recommended. There are plenty of recommended = N cipher suites
in the registry that went through the IETF process. Security expectations
evolve or we may make mistakes, and this is one tool we have for realigning
things when that happens.

Regarding how psk_ke should be marked, we have already marked the analogous
cipher suite in TLS 1.2, TLS_PSK_WITH_AES_128_GCM_SHA256, as N. There is
indeed a problem with the use of that mode. TLS 1.3 was intended to provide
forward secrecy, and psk_ke does not do so. This is especially problematic
with external PSKs, such as the smartcards folks mentioned, because it
means all traffic hinges on a long-lived shared secret. The one footnote is
that TLS 1.3 uses the same code points for external PSKs and resumption,
and the precedent is less clear for resumption. But TLS 1.2 resumption's
lack of fresh key exchange is a well-documented problem that we happily
fixed with psk_dhe_ke, so I'm perfectly fine extending the status to psk_ke
with resumption.

This is separate from psk_dhe_ke, which is analogous to TLS 1.2's
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256. That one is still recommended Y. For
that matter, psk_dhe_ke is used in ECDH-ful resumption, so if the WG wants
to say something stronger about external PSKs, we'd need a new values in
that column anyway...

(An aside, psk_dhe_ke and psk_ke are PSK key exchange modes, not cipher
suites.)

On Wed, Sep 23, 2020 at 12:03 PM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi David,
>
>
>
> my problem is that the IANA registry only says “not recommended” but it
> does not say for what environments these ciphersuites are not recommended.
> Worse, it also wants to indicate whether the specification has gone through
> the IETF process.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* David Benjamin 
> *Sent:* Wednesday, September 23, 2020 5:47 PM
> *To:* Salz, Rich 
> *Cc:* Hannes Tschofenig ; Filippo Valsorda <
> fili...@ml.filippo.io>; Carrick Bartle ;
> tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> There are two different code points involved in TLS 1.3 PSK, and I think
> there may be some mixup here:
>
> 1. Whether TLS 1.3 psk_ke should be marked N
>
> 2. Whether TLS 1.3. psk_dhe_ke should be marked N
>
>
>
> Avoiding psk_ke does not remove compatibility with any authentication
> method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
> the handshake mixes an additional (EC)DH exchange into the key schedule.
> We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
> seems to me psk_ke with an external PSK should be similar. Handshakes using
> psk_ke with an external PSK incorporate no secrets in the key exchange
> apart from a (often long-lived) external symmetric secret. Compromise that
> secret, and all traffic ever authenticated with that PSK is compromised.
> Resumption PSKs use short-lived keys, so psk_ke is less immediately
> disastrous but given the equivalent construction in TLS 1.2 has forward
> secrecy issues
> <https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it
> as N across the board seems a good idea to me. (BoringSSL does not
> implement psk_ke for this reason. Looks like Go and NSS do not implement it
> either.)
>
>
>
> psk_dhe_ke I suppose depends on how one interprets "specific use case", so
> I don't feel very strongly here.
>
>
>
> David
>
>
>
> On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
> I agree with Hannes’s reasoning.
>
>
>
> I am also concerned about devolving TLS to be just Web browser/server.
>
>
>
> ___
> TLS mailing list
> 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.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi David,

my problem is that the IANA registry only says “not recommended” but it does 
not say for what environments these ciphersuites are not recommended. Worse, it 
also wants to indicate whether the specification has gone through the IETF 
process.

Ciao
Hannes

From: David Benjamin 
Sent: Wednesday, September 23, 2020 5:47 PM
To: Salz, Rich 
Cc: Hannes Tschofenig ; Filippo Valsorda 
; Carrick Bartle ; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

There are two different code points involved in TLS 1.3 PSK, and I think there 
may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication method. 
psk_ke and psk_dhe_ke use the same PSKs. The difference is whether the 
handshake mixes an additional (EC)DH exchange into the key schedule. We've 
already marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it seems to me 
psk_ke with an external PSK should be similar. Handshakes using psk_ke with an 
external PSK incorporate no secrets in the key exchange apart from a (often 
long-lived) external symmetric secret. Compromise that secret, and all traffic 
ever authenticated with that PSK is compromised. Resumption PSKs use 
short-lived keys, so psk_ke is less immediately disastrous but given the 
equivalent construction in TLS 1.2 has forward secrecy 
issues<https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it 
as N across the board seems a good idea to me. (BoringSSL does not implement 
psk_ke for this reason. Looks like Go and NSS do not implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so I 
don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
I agree with Hannes’s reasoning.

I am also concerned about devolving TLS to be just Web browser/server.

___
TLS mailing list
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

There are two different code points involved in TLS 1.3 PSK, and I think
there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication
method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
the handshake mixes an additional (EC)DH exchange into the key schedule.
We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
seems to me psk_ke with an external PSK should be similar. Handshakes using
psk_ke with an external PSK incorporate no secrets in the key exchange
apart from a (often long-lived) external symmetric secret. Compromise that
secret, and all traffic ever authenticated with that PSK is compromised.
Resumption PSKs use short-lived keys, so psk_ke is less immediately
disastrous but given the equivalent construction in TLS 1.2 has forward
secrecy issues ,
marking it as N across the board seems a good idea to me. (BoringSSL does
not implement psk_ke for this reason. Looks like Go and NSS do not
implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so
I don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich  wrote:

> I agree with Hannes’s reasoning.
>
>
>
> I am also concerned about devolving TLS to be just Web browser/server.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

I agree with Hannes’s reasoning.

I am also concerned about devolving TLS to be just Web browser/server.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi Filippo,

I worry that labelling ciphersuites that is deployed in parts of the industry 
as “not recommended” will confuse those who look at the IANA website.

Only those readers who look at the note will then learn that not recommended 
means three things, whereby the option "has not been through the IETF consensus 
process" should not give readers great confidence either.

I hope this explains my concern.

There is no problem with the use of these PSK ciphersuites, so why mark them as 
“not recommended”?

Ciao
Hannes

From: Filippo Valsorda 
Sent: Wednesday, September 23, 2020 3:39 PM
To: Hannes Tschofenig ; Carrick Bartle 

Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>:

Hi Carrick,



you note that SCADA is a pretty specific use case. SCADA sounds specific but 
TLS is used widely in the IoT market. It is even used in devices that use smart 
cards, which use TLS with PSK to protect their provisioning protocol.



I am worried that marking a ciphersuite as N with the meaning that it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases" is hard for readers to understand which 
of these three cases were actually the reason for marking it as “N”. The "has 
not been through the IETF consensus process" will scare off many people.



For most people the web is the generic case and everything else is a “specific 
use case”. Sure, the web is very important but TLS is a generic protocol used 
in many environments.

By this reasoning, what is a specific use case? My interpretation is "anything 
you shouldn't use unless you have specific requirements". Compatibility with 
smart cards is clearly a specific requirement, and you should definitely use an 
ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or 
Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of 
whether they talk to browsers or other services.


I don’t understand John’s motivation. The LAKE group makes a decision to remove 
PSK support. That’s good for them. Does this imply that the TLS group also 
needs to make the same decision?

(Again, no one is suggesting dropping anything, as far as I can tell.)


Ciao

Hannes


From: Carrick Bartle mailto:cbartle...@icloud.com>>
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Carrick Bartle 
mailto:cbartle891=40icloud@dmarc.ietf.org>>;
 Filippo Valsorda mailto:fili...@ml.filippo.io>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3



Can you justify your reasoning?



Which part?




On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:



Hi Carrick,



Can you justify your reasoning?



The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.



I don’t see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.



Ciao

Hannes


From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3



I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.







On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:



2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:

John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:



>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and

>especially psk_ke are both marked as RECOMMENDED. If used in the initial

>handshake, both modes have severe privacy problems,



PSK is used a fair bit in SCADA.  There are no privacy problems there.  So

just because there's a concern for one specific environment doesn't mean it

should be banned for any use.  In particular, I think if a specific industry

has a particular concern, they should profile it for use in that industry but

not require that everyone else change their behaviour.



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 Interne

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

[David Woodhouse]

On Sat, 2020-09-19 at 11:30 +, John Mattsson wrote:
> Hi,
> 
> Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric
> keys for authentication and key exchange made me think about the
> future role of external PSK in TLS.
> 
> https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/
> 
> I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy
> systems. Due to the major privacy, security, and deployment
> limitations with PSK, I see little need to use PSK (besides
> resumption) in new systems, except for the use case in RFC 8773.

Some VPN protocols (e.g. Cisco AnyConnect) attempt to establish a DTLS
session in parallel with an existing TLS session, to avoid TCP-over-TCP 
where possible.

Cisco does it by fabricating a DTLS session (details exchanged over the
existing authenticated TLS channel) and then "resuming" it. Using this
method, the DTLS protocol version and all options are hard-coded when
the session is fabricated. This makes me sad.

In the open source implementation of client/server we have extended the
protocol to exchange a PSK over the existing TLS session, then
negotiate DTLS the "normal" way using that PSK.

That's a lot cleaner (IMO) and seems like a valid use case for PSK.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Filippo Valsorda]

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig :
> Hi Carrick,

>  

> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.

>  

> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.

>  

> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  


By this reasoning, what is a specific use case? My interpretation is "anything 
you shouldn't use unless you have specific requirements". Compatibility with 
smart cards is clearly a specific requirement, and you should definitely use an 
ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or 
Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of 
whether they talk to browsers or other services.

> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?


(Again, no one is suggesting dropping anything, as far as I can tell.)

> Ciao

> Hannes

>  


> *From:* Carrick Bartle  
> *Sent:* Monday, September 21, 2020 6:19 PM
> *To:* Hannes Tschofenig 
> *Cc:* Carrick Bartle ; Filippo 
> Valsorda ; tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3

>  

>> Can you justify your reasoning? 

>  

> Which part?

>  


> 

>> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
>> wrote:

>>  

>> Hi Carrick, 

>>  

>> Can you justify your reasoning? 

>>  

>> The challenge I have with the work on IoT in the IETF that the preferences 
>> for pretty much everything changes on a regular basis.

>>  

>> I don’t see a problem that requires a change. In fact, I have just posted a 
>> mail to the UTA list that gives an overview of the implementation status of 
>> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  

>>  

>> Ciao

>> Hannes

>>  


>> *From:* TLS  *On Behalf Of *Carrick Bartle
>> *Sent:* Monday, September 21, 2020 5:31 AM
>> *To:* Filippo Valsorda 
>> *Cc:* tls@ietf.org
>> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3

>>  

>> I'm also fine with marking psk_ke as not recommended to be consistent with 
>> the non-PFS ciphers, but there are plenty of valid use cases that justify 
>> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
>> cases are detailed in draft-ietf-tls-external-psk-guidance-00.

>>  

>>  

>>  

>>> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:

>>>  

>>> 2020-09-19 13:48 GMT+02:00 Peter Gutmann :

>>>> John Mattsson  writes:

>>>>  

>>>> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke 
>>>> >and

>>>> >especially psk_ke are both marked as RECOMMENDED. If used in the initial

>>>> >handshake, both modes have severe privacy problems,

>>>>  

>>>> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So

>>>> just because there's a concern for one specific environment doesn't mean it

>>>> should be banned for any use.  In particular, I think if a specific 
>>>> industry

>>>> has a particular concern, they should profile it for use in that industry 
>>>> but

>>>> not require that everyone else change their behaviour.

>>>  

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

>>>  

>>> Setting Recommended to N is not "banning" anything, it's saying it "has not 
>>> been through the IETF consensus process, has limited applicability, or is 
>>> intended only for specific use cases". SCADA sounds like a pretty specific 
>>> use case.

>>>  

>>> I don't have a strong opinion on 

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

[Blumenthal, Uri - 0553 - MITLL]

I sincerely hope that the TLS group will NOT make the same decision [as LAKE - 
to drop PSK].

Regards,
Uri

> On Sep 23, 2020, at 07:50, Hannes Tschofenig  
> wrote:
> 
> 
> Hi Carrick,
>  
> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.
>  
> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.
>  
> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  
>  
> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?
>  
> Ciao
> Hannes
>  
> From: Carrick Bartle  
> Sent: Monday, September 21, 2020 6:19 PM
> To: Hannes Tschofenig 
> Cc: Carrick Bartle ; Filippo Valsorda 
> ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> Can you justify your reasoning? 
>  
> Which part?
>  
> 
> 
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
> wrote:
>  
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS  On Behalf Of Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda 
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann :
> John Mattsson  writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> 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.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> 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. 
> ___
> TLS mailing list
> 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 

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

[Hannes Tschofenig]

Hi Carrick,

you note that SCADA is a pretty specific use case. SCADA sounds specific but 
TLS is used widely in the IoT market. It is even used in devices that use smart 
cards, which use TLS with PSK to protect their provisioning protocol.

I am worried that marking a ciphersuite as N with the meaning that it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases" is hard for readers to understand which 
of these three cases were actually the reason for marking it as “N”. The "has 
not been through the IETF consensus process" will scare off many people.

For most people the web is the generic case and everything else is a “specific 
use case”. Sure, the web is very important but TLS is a generic protocol used 
in many environments.

I don’t understand John’s motivation. The LAKE group makes a decision to remove 
PSK support. That’s good for them. Does this imply that the TLS group also 
needs to make the same decision?

Ciao
Hannes

From: Carrick Bartle 
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig 
Cc: Carrick Bartle ; Filippo Valsorda 
; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Can you justify your reasoning?

Which part?



On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Carrick,

Can you justify your reasoning?

The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.

I don’t see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.

Ciao
Hannes

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:

2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:
John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

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.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.
___
TLS mailing list
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. ___
TLS mailing list
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

ks with ESP8266 or
 >         Arduino+Ethernet boards 
 >
 >         __ __
 >
 >         For client software we use OPENSSL or WolfSSL
 >
 >         __ __
 >
 >         Pascal
 >
 >         __ __
 >
 >         __ __
 >
 >         __ __
 >
 >         __ __
 >
 >         Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig
 >         mailto:hannes.tschofe...@arm.com> <mailto:hannes.tschofe...@arm.com
<mailto:hannes.tschofe...@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 mailto:pascal.ur...@gmail.com>
 >             <mailto:pascal.ur...@gmail.com
<mailto:pascal.ur...@gmail.com>>>
 >             Sent: Monday, September 21, 2020 11:44 AM
 >             To: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>
 >             <mailto:hannes.tschofe...@arm.com
<mailto:hannes.tschofe...@arm.com>>>
 >             Cc: Filippo Valsorda mailto:fili...@ml.filippo.io>
 >             <mailto:fili...@ml.filippo.io
<mailto:fili...@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.tschofe...@arm.com
<mailto:hannes.tschofe...@arm.com>
 >             <mailto:hannes.tschofe...@arm.com
<mailto:hannes.tschofe...@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 a

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

[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  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  > <mailto:pascal.ur...@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
> > mailto:hannes.tschofe...@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  > <mailto:pascal.ur...@gmail.com>>
> > *Sent:* Monday, September 21, 2020 2:01 PM
> > *To:* Hannes Tschofenig  > <mailto:hannes.tschofe...@arm.com>>
> > *Cc:* Filippo Valsorda  > <mailto:fili...@ml.filippo.io>>; tls@ietf.org  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
> > mailto:hannes.tschofe...@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  > <mailto:pascal.ur...@gmail.com>>
> > Sent: Monday, September 21, 2020 11:44 AM
> >  

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

[Achim Kraus]

Hi John,

I can only fully agree with Hannes's arguments!

PSK is in my experience for some constraint devices currently the only
choice. Devices, which are able to execute a PSKs with ECDHE handshakes,
will be able to use RPK.

I'm not sure, if sometimes the arguments, not to recommend something,
should be more differentiated. Pretty sure, outside IoT, there may be no
reason left to use that. But inside IoT, it may take some more time
until almost all device can use it.

best regards
Achim

Am 20.09.20 um 13:18 schrieb Hannes Tschofenig:

John,

The use of plain PSK makes a lot of sense because it provides the lowest 
footprint solution for really constrained systems. Given that the LAKE group 
wanted to focus on constrained IoT devices makes the decision by the group 
questionable.

As you know, TLS 1.3 merged the handling of PSKs previously found in three 
different RFCs, namely session resumption, ciphersuites with PSK, and session 
resumption without server-side state into one solution. As such, there is not 
even extra cost associated with external PSKs.

I have been arguing that a solution that uses PSKs with ECDHE, as you proposed 
in RFC 8442, is less useful because very constrained are not going to use the 
asymmetric crypto needed for the ECDHE. Those deployments could instead go 
directly to a raw public key solution instead.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of John Mattsson
Sent: Saturday, September 19, 2020 1:30 PM
To: TLS@ietf.org
Subject: [TLS] The future of external PSK in TLS 1.3

Hi,

Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric keys for 
authentication and key exchange made me think about the future role of external 
PSK in TLS.

https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/

I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy systems. 
Due to the major privacy, security, and deployment limitations with PSK, I see 
little need to use PSK (besides resumption) in new systems, except for the use 
case in RFC 8773.

LAKE recently removed PSK authentication completely as it does not produce 
smaller messages and comes with severe privacy and deployments problems. 
Increasing code size (a few kB) and slightly increased computation/latency was 
not seen as a big problems.

Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and 
especially psk_ke are both marked as RECOMMENDED. If used in the initial 
handshake, both modes have severe privacy problems, and psk_ke does not give 
PFS, thus making pervasive monitoring much easier. If groups keys are used, 
additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE 
has for good reasons been marked as NOT RECOMMENDED.

I have recently seen several people arguing that the inclusion of PSK in TLS 
1.3 means that the use external PSKs are now recommended. I don't think that 
was the intension of the TLS WG.

I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. 
Irrespectively of what ‘Y’ in the recommended column actually means, people are 
and will read it as recommended to use.

Cheers,
John

___
TLS mailing list
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

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 mailto:pascal.ur...@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
mailto:hannes.tschofe...@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 mailto:pascal.ur...@gmail.com>>
*Sent:* Monday, September 21, 2020 2:01 PM
*To:* Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
*Cc:* Filippo Valsorda mailto:fili...@ml.filippo.io>>; 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
mailto:hannes.tschofe...@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 mailto:pascal.ur...@gmail.com>>
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Cc: Filippo Valsorda mailto:fili...@ml.filippo.io>>; 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.tschofe...@arm.com
<mailto:hannes.tschofe...@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 “o

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

[Carrick Bartle]

> Can you justify your reasoning? 

Which part?


> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS  On Behalf Of Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda 
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  <mailto:fili...@ml.filippo.io>> wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  <mailto:pgut...@cs.auckland.ac.nz>>:
> John Mattsson  <mailto:40ericsson@dmarc.ietf.org>> writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> 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.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <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. 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[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  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.tschofe...@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 
>> *Sent:* Monday, September 21, 2020 2:01 PM
>> *To:* Hannes Tschofenig 
>> *Cc:* Filippo Valsorda ; 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.tschofe...@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 
>> Sent: Monday, September 21, 2020 11:44 AM
>> To: Hannes Tschofenig 
>> Cc: Filippo Valsorda ; 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 > hannes.tschofe...@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.
>> __

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

[Pascal Urien]

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

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

[Hannes Tschofenig]

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 
Sent: Monday, September 21, 2020 2:01 PM
To: Hannes Tschofenig 
Cc: Filippo Valsorda ; 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 
mailto:hannes.tschofe...@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 mailto:pascal.ur...@gmail.com>>
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Filippo Valsorda mailto:fili...@ml.filippo.io>>; 
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.tschofe...@arm.com<mailto:hannes.tschofe...@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>
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
https://www.ietf.org/mailman/listinfo/tls

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

[Pascal Urien]

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 
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 
> Sent: Monday, September 21, 2020 11:44 AM
> To: Hannes Tschofenig 
> Cc: Filippo Valsorda ; 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  hannes.tschofe...@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.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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 
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig 
Cc: Filippo Valsorda ; 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.tschofe...@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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Pascal Urien]

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 
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 draft-sheffer-uta-rfc7525bis-00
> 
>
>
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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 
draft-sheffer-uta-rfc7525bis-00

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi Carrick,

Can you justify your reasoning?

The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.

I don't see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.

Ciao
Hannes

From: TLS  On Behalf Of Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:

2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:
John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

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.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.
___
TLS mailing list
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:
> 
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  >:
>> John Mattsson > > writes:
>> 
>> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
>> >handshake, both modes have severe privacy problems,
>> 
>> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
>> just because there's a concern for one specific environment doesn't mean it
>> should be banned for any use.  In particular, I think if a specific industry
>> has a particular concern, they should profile it for use in that industry but
>> not require that everyone else change their behaviour.
> 
> 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.
> 
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
> 
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

John,

The use of plain PSK makes a lot of sense because it provides the lowest 
footprint solution for really constrained systems. Given that the LAKE group 
wanted to focus on constrained IoT devices makes the decision by the group 
questionable.

As you know, TLS 1.3 merged the handling of PSKs previously found in three 
different RFCs, namely session resumption, ciphersuites with PSK, and session 
resumption without server-side state into one solution. As such, there is not 
even extra cost associated with external PSKs.

I have been arguing that a solution that uses PSKs with ECDHE, as you proposed 
in RFC 8442, is less useful because very constrained are not going to use the 
asymmetric crypto needed for the ECDHE. Those deployments could instead go 
directly to a raw public key solution instead.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of John Mattsson
Sent: Saturday, September 19, 2020 1:30 PM
To: TLS@ietf.org
Subject: [TLS] The future of external PSK in TLS 1.3

Hi,

Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric keys for 
authentication and key exchange made me think about the future role of external 
PSK in TLS.

https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/

I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy systems. 
Due to the major privacy, security, and deployment limitations with PSK, I see 
little need to use PSK (besides resumption) in new systems, except for the use 
case in RFC 8773.

LAKE recently removed PSK authentication completely as it does not produce 
smaller messages and comes with severe privacy and deployments problems. 
Increasing code size (a few kB) and slightly increased computation/latency was 
not seen as a big problems.

Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and 
especially psk_ke are both marked as RECOMMENDED. If used in the initial 
handshake, both modes have severe privacy problems, and psk_ke does not give 
PFS, thus making pervasive monitoring much easier. If groups keys are used, 
additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE 
has for good reasons been marked as NOT RECOMMENDED.

I have recently seen several people arguing that the inclusion of PSK in TLS 
1.3 means that the use external PSKs are now recommended. I don't think that 
was the intension of the TLS WG.

I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. 
Irrespectively of what ‘Y’ in the recommended column actually means, people are 
and will read it as recommended to use.

Cheers,
John

___
TLS mailing list
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

On Sat, Sep 19, 2020 at 06:00:00PM +0200, Filippo Valsorda wrote:

> Setting Recommended to N is not "banning" anything, it's saying it
> "has not been through the IETF consensus process, has limited
> applicability, or is intended only for specific use cases". SCADA
> sounds like a pretty specific use case.
> 
> I don't have a strong opinion on psk_dhe_ke, but I see no reason
> psk_ke wouldn't be marked N like all suites lacking PFS.

Is there actually a problem here?  "Nobody" is using external PSK "on
the open Internet", because, perhaps not surprisingly, you need to have
a pre-shared key for that.  Thus, browsers and the like just don't have
pre-shared keys with each and every web-server the user might direct
them at.

By the time external PSK (i.e. not resumption session tickets) is actually
in use, we're already well outside the use cases where we're protecting
the privacy of Joe-consumer using commodity software.

Perhaps in the IoT space one can envision some device "calling home" to
the manufacturer or supplier in a manner that identifies the device
slightly more than just the source and destination IP addresses, ...
but I don't see this as motivating a compelling need to change the
registry.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Filippo Valsorda]

2020-09-19 13:48 GMT+02:00 Peter Gutmann :
> John Mattsson  writes:
> 
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
> 
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.

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.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

John Mattsson  writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] The future of external PSK in TLS 1.3

[John Mattsson]

Hi,

Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric keys for 
authentication and key exchange made me think about the future role of external 
PSK in TLS.

https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/

I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy systems. 
Due to the major privacy, security, and deployment limitations with PSK, I see 
little need to use PSK (besides resumption) in new systems, except for the use 
case in RFC 8773.

LAKE recently removed PSK authentication completely as it does not produce 
smaller messages and comes with severe privacy and deployments problems. 
Increasing code size (a few kB) and slightly increased computation/latency was 
not seen as a big problems.

Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and 
especially psk_ke are both marked as RECOMMENDED. If used in the initial 
handshake, both modes have severe privacy problems, and psk_ke does not give 
PFS, thus making pervasive monitoring much easier. If groups keys are used, 
additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE 
has for good reasons been marked as NOT RECOMMENDED.

I have recently seen several people arguing that the inclusion of PSK in TLS 
1.3 means that the use external PSKs are now recommended. I don't think that 
was the intension of the TLS WG.

I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. 
Irrespectively of what ‘Y’ in the recommended column actually means, people are 
and will read it as recommended to use.

Cheers,
John

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls