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

From: Achim Kraus <[email-masked]>
Date: Tue, 29 Sep 2020 18:30:32 +0200

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 29 Sep 2020 16:49:04 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi list,

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

    best regards
    Achim Kraus

    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Tue, 29 Sep 2020 20:29:25 -0400

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

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 30 Sep 2020 00:48:28 +0000

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 <[email-masked]> wrote:
>

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 29 Sep 2020 18:03:09 -0700

>  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 <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Achim Kraus <[email-masked]>
Date: Wed, 30 Sep 2020 07:21:45 +0200

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Sep 2020 07:32:07 +0000

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 <[email-masked]> On Behalf Of Watson Ladd
Sent: Wednesday, September 30, 2020 2:29 AM
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

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

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.

_______________________________________________
TLS mailing list
[email-masked]
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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Sep 2020 08:08:33 +0000

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 <[email-masked]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Wednesday, September 30, 2020 2:48 AM
To: Watson Ladd <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Regards,
Uri

---

From: Rob Sayre <[email-masked]>
Date: Wed, 30 Sep 2020 01:19:44 -0700

On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig <
[email-masked]> 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

---

From: Achim Kraus <[email-masked]>
Date: Wed, 30 Sep 2020 10:39:34 +0200

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
> <[email-masked] <mailto:[email-masked]>> 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
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Sep 2020 08:42:43 +0000

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 <[email-masked]>
Sent: Wednesday, September 30, 2020 10:20 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Watson Ladd <[email-masked]>; Blumenthal, Uri - 0553 - MITLL <[email-masked]>; [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> 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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Sep 2020 08:50:31 -0400

> 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/slid…

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.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 30 Sep 2020 13:09:43 +0000

> On Sep 30, 2020, at 08:51, Watson Ladd <[email-masked]> wrote:
> 

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Sep 2020 15:12:27 +0000

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.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 30 Sep 2020 18:06:22 -0700

> 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