Subject: RE: Regarding TLS 1.3 Usage

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Feb 2019 17:01:55 +0000

(Moving from the draft-specific list to the WG list.)

Given the flexibility of TLS, it seems more likely that individual ciphers or (at most) versions would be deprecated rather than TLS as a whole.  Both of those things have happened before (see RC4, SSL 3.0; TLS 1.0 and 1.1 are in the process of being deprecated) and HTTPS has survived despite mandating the use of TLS.

However, in the extreme case, two things would need to happen:  A revision to HTTP/3 permitting it to use versions of QUIC which employ a different handshake protocol, and a new version of QUIC based on something else.  That’s because TLS is still being used as a module – a different version of QUIC could choose a different handshake protocol that provides the necessary properties and would work just fine (modulo any extensions that assume the availability of a TLS stack).

From: Mantas Gridinas <[email-masked]>
Sent: Monday, February 11, 2019 12:24 AM
To: [email-masked]
Subject: Regarding TLS 1.3 Usage

Hi!

I have looked through your document about HTTP/3 and its suggestions to use QUIC as well as TLS 1.3 at transport layer and the following question occurred to me: What will happen if TLS gets deprecated? Will we need an entirely new protocol to replace HTTP/3 once that happens? Wasn't it entire point of SSL and TLS that they wouldn't be packed with any particular protocol, but instead added as a layer?

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 11 Feb 2019 11:06:51 -0800

For very constrained devices, TLS is not the ideal protocol. Some of the
ciphers in TLS 1.3 may be suitable, such as ChaCha20 and ed25519, but as a
whole there is too much overhead. So there is a case for a simpler IoT
handshake. Of course, if such a handshake breaks, it is not just
reconfiguration of TLS, but a new version of QUIC and HTTP.

Mikkel

On 11 February 2019 at 18.02.26, Mike Bishop ([email-masked]) wrote:

Given the flexibility of TLS, it seems more likely that individual ciphers
or (at most) versions would be deprecated rather than TLS as a whole.  Both
of those things have happened before (see RC4, SSL 3.0; TLS 1.0 and 1.1 are
in the process of being deprecated) and HTTPS has survived despite
mandating the use of TLS.

However, in the extreme case, two things would need to happen:  A revision
to HTTP/3 permitting it to use versions of QUIC which employ a different
handshake protocol, and a new version of QUIC based on something else.
That’s because TLS is still being used as a module – a different version of
QUIC could choose a different handshake protocol that provides the
necessary properties and would work just fine (modulo any extensions that
assume the availability of a TLS stack).

*From:* Mantas Gridinas <[email-masked]>
*Sent:* Monday, February 11, 2019 12:24 AM
*To:* [email-masked]
*Subject:* Regarding TLS 1.3 Usage

Hi!

I have looked through your document about HTTP/3 and its suggestions to use
QUIC as well as TLS 1.3 at transport layer and the following question
occurred to me: What will happen if TLS gets deprecated? Will we need an
entirely new protocol to replace HTTP/3 once that happens? Wasn't it entire
point of SSL and TLS that they wouldn't be packed with any particular
protocol, but instead added as a layer?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Feb 2019 19:40:21 +0000

>For very constrained devices, TLS is not the ideal protocol. Some of the ciphers in TLS 1.3 may be suitable, such as ChaCha20 and ed25519, but as a whole there is too much overhead. So there is a case for a simpler IoT handshake. Of course, if such a handshake breaks, it is not just reconfiguration of TLS, but a new version of QUIC and HTTP

It will be interesting if the “very constrained device” community starts with a known quantity, and then removes the things that they believe aren’t needed, and do it “properly” threat model, profiling, protocol analysis, etc. Until then, I think QUIC should stick with TLS.

---

From: Martin Duke <[email-masked]>
Date: Mon, 11 Feb 2019 13:27:59 -0800

I don't believe there's anything stopping people from distributing PSKs
using some out-of-band channel and using that for a lighter-weight
handshake.

On Mon, Feb 11, 2019 at 11:40 AM Salz, Rich <[email-masked]> wrote:

> *>*For very constrained devices, TLS is not the ideal protocol. Some of
> the ciphers in TLS 1.3 may be suitable, such as ChaCha20 and ed25519, but
> as a whole there is too much overhead. So there is a case for a simpler IoT
> reconfiguration of TLS, but a new version of QUIC and HTTP
>
>
>
> It will be interesting if the “very constrained device” community starts
> with a known quantity, and then removes the things that they believe aren’t
> needed, and do it “properly” threat model, profiling, protocol analysis,
> etc. Until then, I think QUIC should stick with TLS.
>
>
>

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 12 Feb 2019 10:10:22 +0100

> Am 11.02.2019 um 20:40 schrieb Salz, Rich <[email-masked]>:
> 
> >For very constrained devices, TLS is not the ideal protocol.

Are those the devices that some years ago could not afford to implement SSL?

It sounds as if these devices always stay just above what the market would reject right away. Which might be a good business strategy for the makers, but it seems disconnected from the purpose of this group.

- Stefan