Subject: [TLS] Authentication Only Ciphersuites RFC

From: Jack Visoky <[email-masked]>
Date: Tue, 26 Feb 2019 20:54:20 +0000

TLS Colleagues,

If you recall we discussed a draft for authentication only ciphersuites over email back in August of 2018.  We've since made some updates to that draft.  We also have gotten IANA assignments to the authentication only ciphersuites for TLS 1.3 and have updated the draft to reflect the new assignments.

To that extent, as the IoT community is looking to adopt these ciphersuites, we would like to solicit review of the draft:

    https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02

and request that it be published as informational draft given that the IoT forums are looking to adopt its use and the draft can serve as the guide for use and interoperability.

Thanks and Best Regards,

--Jack (and Nancy)

---

From: Hanno Böck <[email-masked]>
Date: Tue, 26 Feb 2019 22:03:35 +0100

I think I have raised my concerns before, but I have serious doubts
there's real need for such ciphersuites.

The reasoning seems to be that performance constrained devices are
unable to do "normal" TLS. I don't have benchmarks, but it's my
experience that people vastly overestimate the costs of symmetric
encryption operations (by far the largest computational cost of TLS is
the asymmetric handshake). I wonder if the people who believe they need
an authentication only ciphersuite ever ran tests.

I also see a non-neglegible risk in standardizing such ciphersuites.
Some implementations will end up adding them and coupled with
implementation flaws we may end up in a situation where inadvertently
insecure ciphersuites are chosen.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Jack Visoky <[email-masked]>
Date: Tue, 26 Feb 2019 21:26:45 +0000

Hi Hanno,

We have done tests on this and it there is a difference.  For some industries (industrial automation) throughput is very sensitive so what might appear as a small difference can actually be quite significant.  On that same note, yes you are absolutely correct that the asymmetric handshake is far more computationally expensive.  However, this generally happens at the start of a connection where timing is less sensitive.  Once the application I/O is actually being sent/received is when the performance really becomes sensitive. 

Point taken that the ciphersuites could be used within an application where it isn't appropriate, however this would have to be weighed against the benefit of industries adopting TLS 1.3 and securing the many IoT applications that desire this.  This probably goes without saying but of course the best line of defense is to properly design, build, and configure the implementation.  I recognize that doesn't completely obviate your point but it does seem relevant.

Thanks,

--Jack

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Hanno Böck
Sent: Tuesday, February 26, 2019 4:04 PM
To: [email-masked]
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

[Use caution with links & attachments]

I think I have raised my concerns before, but I have serious doubts there's real need for such ciphersuites.

The reasoning seems to be that performance constrained devices are unable to do "normal" TLS. I don't have benchmarks, but it's my experience that people vastly overestimate the costs of symmetric encryption operations (by far the largest computational cost of TLS is the asymmetric handshake). I wonder if the people who believe they need an authentication only ciphersuite ever ran tests.

I also see a non-neglegible risk in standardizing such ciphersuites.
Some implementations will end up adding them and coupled with implementation flaws we may end up in a situation where inadvertently insecure ciphersuites are chosen.

--
Hanno Böck
https://hboeck.de/

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Feb 2019 22:20:26 +0000

FWIW I tend to agree with Hanno. Sending this to the ISE is
likely better if an RFC is even needed. We already opened up
the ciphersuite registration process to allow this kind of
thing without the WG having to try (and sometimes fail to)
reach rough consensus on things like this.

On 26/02/2019 21:26, Jack Visoky wrote:
> Hi Hanno,
> 
> We have done tests on this and it there is a difference.  For some 
> industries (industrial automation) throughput is very sensitive so 
> what might appear as a small difference can actually be quite 
> significant.  On that same note, yes you are absolutely correct that 
> the asymmetric handshake is far more computationally expensive. 
> However, this generally happens at the start of a connection where 
> timing is less sensitive.  Once the application I/O is actually
> being sent/received is when the performance really becomes
> sensitive.
> 
> Point taken that the ciphersuites could be used within an
> application where it isn't appropriate, however this would have to be
> weighed against the benefit of industries adopting TLS 1.3 and
> securing the many IoT applications that desire this.

That last appears to contradict the text in the draft itself
that says that these ciphersuites are for niche use cases.

For non-niche cases we really don't want to see use of these
ciphersuites.

Cheers,
S.

> This probably goes without saying but of course the best line of
> defense is to properly design, build, and configure the
> implementation.  I recognize that doesn't completely obviate your
> point but it does seem relevant.
> 
> Thanks,
> 
> --Jack
> 
> -----Original Message----- From: TLS <[email-masked]> On
> Behalf Of Hanno Böck Sent: Tuesday, February 26, 2019 4:04 PM To: 
> [email-masked] Subject: EXTERNAL: Re: [TLS] Authentication Only 
> Ciphersuites RFC
> 
> encryption operations (by far the largest computational cost of TLS 
> is the asymmetric handshake). I wonder if the people who believe
> they need an authentication only ciphersuite ever ran tests.
> 
> implementation flaws we may end up in a situation where
> inadvertently insecure ciphersuites are chosen.
> 
> -- Hanno Böck https://hboeck.de/
> 
> mail/jabber: [email-masked] GPG: 
> FE73757FA60E4E21B937579FA5880072BBB51E42
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Feb 2019 14:52:42 -0800

On Tue, Feb 26, 2019 at 12:54 PM Jack Visoky <[email-masked]>
wrote:

> TLS Colleagues,
>
> If you recall we discussed a draft for authentication only ciphersuites
> over email back in August of 2018.  We've since made some updates to that
> draft.  We also have gotten IANA assignments to the authentication only
> ciphersuites for TLS 1.3 and have updated the draft to reflect the new
> assignments.
>
> To that extent, as the IoT community is looking to adopt these
> ciphersuites, we would like to solicit review of the draft:
>
>
>
>
> and request that it be published as informational draft given that the IoT
> forums are looking to adopt its use and the draft can serve as the guide
> for use and interoperability.
>

It seems to me that there four somewhat distinct questions:

1. Code points
2. Document level (Info, Exp, PS, etc.)
3. Recommended status
4. WG status

>From my perspective, you have code points and you've asked for an
Informational document, but than can only get you Not Recommended, so
what's the value of having this be a WG document? Why can't you submit it
to the ISE or alternately just have people reference the draft?

-Ekr

---

From: David Wong <[email-masked]>
Date: Tue, 26 Feb 2019 23:53:39 +0100

Shameless plug, but have you looked at constructions like Disco
(https://eprint.iacr.org/2019/180) that target specifically this
issue?

David

---

From: Hanno Böck <[email-masked]>
Date: Wed, 27 Feb 2019 10:31:23 +0100

Hi,

On Tue, 26 Feb 2019 21:26:45 +0000
Jack Visoky <[email-masked]> wrote:

> We have done tests on this and it there is a difference.

Have these tests in any way been published? Because otherwise it's a
very weak argument.

There are some obvious questions, e.g.:
* What algorithm implementation was tested, was it optimized for the
  architecture in question and was it considered whether the
  optimization could be improved or maybe even whether already a more
  optimized implementation exists?
* Have you tried both AES and chacha20? And in both cases the most
  optimized implementation for the target plattform?
* If the bottleneck is the cipher have you considered whether a
  different cipher that provides reasonable security, but can be
  implemented better on lightweight hardware, would be an alternative?
  (Not keen having that option, I believe fewer options are better.)

> This probably goes without
> saying but of course the best line of defense is to properly design,
> build, and configure the implementation.

I'm inclined to say that this is an outdated view of how to best do
security in protocols.
We had plenty of situations in the past where the TLS spec was a
minefield of possible implementation mistakes that led to long
descriptions on how to properly design things to avoid these mistakes.
History shows it didn't work. (Let me just throw in "Padding Oracles" or
"Bleichenbacher attacks" as very obvious examples.)

My takeaway and I believe that of many people is that the protocol
should avoid implementation pitfalls whereever possible. And I believe
an authentication-only ciphersuite is a dangerous implementation
pitfall.

-- 
Hanno Böck
https://hboeck.de/

---

From: Tony Putman <[email-masked]>
Date: Wed, 27 Feb 2019 10:16:39 +0000

I take no position on whether this is a good idea or not. Regarding the draft itself, I was expecting to see a clear definition of the integrity check computation in terms of an AEAD-Encrypt computation. Something along the lines of:
  AEAD-Encrypt-HMAC(write_key, nonce, additional_data, plaintext) =
    plaintext || HMAC(write_key, nonce || additional_data || plaintext)

In particular, AIUI, nonce must be included to prevent replay attacks. Also include N_MIN = N_MAX = 8 bytes.

-- Tony

From: TLS [mailto:[email-masked]] On Behalf Of Jack Visoky
Sent: 26 February 2019 20:54
To: [email-masked]
Subject: [External Mail] [TLS] Authentication Only Ciphersuites RFC

TLS Colleagues,

Thanks and Best Regards,

--Jack (and Nancy)

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Jack Visoky <[email-masked]>
Date: Wed, 27 Feb 2019 17:03:59 +0000

Hi Hanno,

No, the tests have not been published.  I can look at trying to make this data publicly available but I cannot guarantee that.

Tests were generally done with AES and SHA hashing.  One reason for this is that many in this industry have incorporated some hardware-based crypto acceleration into products, and it's been the case that this hardware has not included ChaCha20.  Although future products can include ChaCha20, in some industries (like Industrial Automation) hardware support can easily span 20 years, so the install base of products without ChaCha20 is non-trivial.

I do take your point around implementation pitfalls, and I realize that for the use cases that most on this list have in mind (e.g. Internet-based web communications) a cipher like this does not seem useful at all.  However there are a lot of IoT devices, and especially industrial devices, that would really benefit from being able to use TLS 1.3 to secure their communications.  These devices are growing rapidly in connectivity so communications security is becoming more and more important/pressing.  I don't represent a library vendor but I'd think this being optional would lend itself well to being compiled out of a library unless needed.

Thanks,

--Jack  

-----Original Message-----
From: Hanno Böck <[email-masked]> 
Sent: Wednesday, February 27, 2019 4:31 AM
To: Jack Visoky <[email-masked]>
Cc: [email-masked]
Subject: Re: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Hi,

> We have done tests on this and it there is a difference.

Have these tests in any way been published? Because otherwise it's a very weak argument.

> build, and configure the implementation.

I'm inclined to say that this is an outdated view of how to best do security in protocols.
We had plenty of situations in the past where the TLS spec was a minefield of possible implementation mistakes that led to long descriptions on how to properly design things to avoid these mistakes.
History shows it didn't work. (Let me just throw in "Padding Oracles" or "Bleichenbacher attacks" as very obvious examples.)

My takeaway and I believe that of many people is that the protocol should avoid implementation pitfalls whereever possible. And I believe an authentication-only ciphersuite is a dangerous implementation pitfall.

--
Hanno Böck
https://hboeck.de/

---

From: Jack Visoky <[email-masked]>
Date: Wed, 27 Feb 2019 17:05:10 +0000

Hi David,

Thanks for sharing this, although the strong preference is to use standard TLS for securing the communications.

Thanks,

--Jack

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of David Wong
Sent: Tuesday, February 26, 2019 5:54 PM
To: Hanno Böck <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Shameless plug, but have you looked at constructions like Disco
(https://eprint.iacr.org/2019/180) that target specifically this issue?

David

On Tue, Feb 26, 2019 at 10:04 PM Hanno Böck <[email-masked]> wrote:
> the asymmetric handshake). I wonder if the people who believe they 
> need an authentication only ciphersuite ever ran tests.
>

---

From: Jack Visoky <[email-masked]>
Date: Wed, 27 Feb 2019 19:49:33 +0000

Hi Eric,

Our goal is to have an RFC published as Informational and with the Not Recommended status.  We felt having this approved through the IETF process vs just ISE would be beneficial to those wishing to adopt, and getting community review is also helpful to us and those we represent.

I suppose one question is whether or not we need this to be a WG item or if we can solicit independent shepherding from a chair or AD to get to the goal of an Information RFC with Not Recommended status.

Also, I apologize if I’ve misunderstood or misstated anything, I’m new to the IETF processes so certainly could have made a mistake.

Thanks,

--Jack

From: Eric Rescorla <[email-masked]>
Sent: Tuesday, February 26, 2019 5:53 PM
To: Jack Visoky <[email-masked]>
Cc: [email-masked]
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

On Tue, Feb 26, 2019 at 12:54 PM Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:

TLS Colleagues,

1. Code points

From my perspective, you have code points and you've asked for an Informational document, but than can only get you Not Recommended, so what's the value of having this be a WG document? Why can't you submit it to the ISE or alternately just have people reference the draft?

-Ekr

Thanks and Best Regards,

--Jack (and Nancy)

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2019 05:39:34 -0800

Jack,

There's a bunch here to unpack.

First, the purpose of the current registry structure was to allow code
point registration without forcing the TLS WG to spend time on documents
that don't generally meet its goals. This seems like one such document.

WRT to your points about the benefits of RFC status:

1. Having this approved through the IETF process vs, just ISE would be
beneficial to those wishing to adopt. Why would this be the case? The only
reason I can think of is that having it be an IETF document would imply
that the IETF thought it was OK. But this is the situation we are trying to
avoid with the Not Recommended label.
2. Having this go through the IETF process would get you community review.
Again, here, the idea with the new process is that we don't force the TLS
WG to do that work.

Obviously, individuals should feel free to review this document or not as
they please, but I'm not seeing any compelling reason why TLS-WG should
take it on.

-Ekr

On Wed, Feb 27, 2019 at 11:49 AM Jack Visoky <[email-masked]>
wrote:

> Hi Eric,
>
>
>
> Our goal is to have an RFC published as Informational and with the Not
> Recommended status.  We felt having this approved through the IETF process
> vs just ISE would be beneficial to those wishing to adopt, and getting
> community review is also helpful to us and those we represent.
>
>
>
> I suppose one question is whether or not we need this to be a WG item or
> if we can solicit independent shepherding from a chair or AD to get to the
> goal of an Information RFC with Not Recommended status.
>
>
>
> Also, I apologize if I’ve misunderstood or misstated anything, I’m new to
> the IETF processes so certainly could have made a mistake.
>
>
>
> Thanks,
>
>
>
> --Jack
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Tuesday, February 26, 2019 5:53 PM
> *To:* Jack Visoky <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 28 Feb 2019 13:54:18 +0000

*   Obviously, individuals should feel free to review this document or not as they please, but I'm not seeing any compelling reason why TLS-WG should take it on

+1 to all EKR said.

The meaning of TLS has gotten stronger over the years, and TLS now implies privacy.  Auth-only is not something the WG should be spending time on.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Feb 2019 13:58:10 +0000

>   *   Obviously, individuals should feel free to review this document or not as they please, but I'm not seeing any compelling reason why TLS-WG should take it on

Same here.

S

---

From: Jack Visoky <[email-masked]>
Date: Thu, 28 Feb 2019 18:09:34 +0000

Hi Eric (and others),

Thanks for the feedback on this.  I’ll need to talk with Nancy but I think it’s become pretty clear that this draft should not become a TLS-WG item.  That said, I appreciate the feedback thus far and welcome further discussion from those in this group.

Thanks,

--Jack

From: Eric Rescorla <[email-masked]>
Sent: Thursday, February 28, 2019 8:40 AM
To: Jack Visoky <[email-masked]>
Cc: [email-masked]
Subject: Re: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Jack,

First, the purpose of the current registry structure was to allow code point registration without forcing the TLS WG to spend time on documents that don't generally meet its goals. This seems like one such document.

1. Having this approved through the IETF process vs, just ISE would be beneficial to those wishing to adopt. Why would this be the case? The only reason I can think of is that having it be an IETF document would imply that the IETF thought it was OK. But this is the situation we are trying to avoid with the Not Recommended label.
2. Having this go through the IETF process would get you community review. Again, here, the idea with the new process is that we don't force the TLS WG to do that work.

Obviously, individuals should feel free to review this document or not as they please, but I'm not seeing any compelling reason why TLS-WG should take it on.

-Ekr

On Wed, Feb 27, 2019 at 11:49 AM Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Thanks,

--Jack

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 26, 2019 5:53 PM
To: Jack Visoky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

TLS Colleagues,

1. Code points

-Ekr

Thanks and Best Regards,

--Jack (and Nancy)