Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

From: John Mattsson <[email-masked]>
Date: Wed, 10 Feb 2021 09:14:39 +0000

Hi,

- The draft has a lot of claims regarding benefits:

  "strong requirement for low latency."
  "minimize the cryptographic algorithms are prioritized"
  "important for latency to be very low."
  "pay more for a sensor with encryption capability"
  "come with a small runtime memory footprint and reduced processing power, the need to minimize"
   the number of cryptographic algorithms used is prioritized."

  I don't think this draft should be published as long as it gives the idea that sacrificing confidentiality has significant benefits for latency, memory, processing power, and cost. This is in general not the case.

  The two cipher suites TLS_SHA256_SHA256 and TLS_SHA384_SHA384  defined by the draft causes much more message expansion (32 and 48 bytes tags instead of 16 or 8 bytes) than the already registered cipher suites for TLS 1.3. In many IoT radio systems with small frames this will leads to significantly increased latency. I think that needs to be mentioned.

- The draft has ridiculous amount of sentences saying that confidentiality is not strictly needed.

  "do not require confidentiality"
  "privacy is not strictly needed"
  "no strong requirement for confidentiality"
  "no requirement to encrypt messages"
  "no need for confidentiality"
  "reduced need for confidentiality"
  "confidentiality requirements are relaxed"
  "do not require confidential communications"
  "does not convey private information"
  "without requiring the communication to/from the robotic arm to be encrypted"
  "doesn't grant the attacker information that can be exploited"
  "no confidentiality requirements"

  It would be more honest if the draft simply stated that "the are use cases that require visibility". If visibility is not a requirement for the use cases, I think IETF could help you to standardize SHA-2 only cipher suites offering confidentiality.

- The draft mentions that the security considerations regarding confidentiality and privacy does not hold. The draft does not mention that it breaks one of the stated security properties of TLS 1.3, namely "Protection of endpoint identities". This is actually quite problematic. EAP-TLS 1.3 relied on this stated TLS 1.3 property to be true. 

John

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Feb 2021 12:08:01 +0000

Hiya,

I realise it's not proposed as a wg document, but
fwiw, I think John is quite correct below. The only
additional point I'd add is that I've seen cases
over the years where the fact that confidentiality
really *is* required only became clear when people
actually considered how to attack systems. I'd be
happy to bet beers that will be the case with some
examples mentioned in the draft, esp the wandering
robotic arm.

This seems like a not that well done write-up of a
bad idea to me.

S.

On 10/02/2021 09:14, John Mattsson wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Jack Visoky <[email-masked]>
Date: Wed, 10 Feb 2021 22:52:24 +0000

Hi John,

> I don't think this draft should be published as long as it gives the idea that sacrificing confidentiality has significant benefits for latency, memory, processing power, and cost. This is in gener…
There definitely are cases where this is true, and cases where it is not. I don't want to speculate as to percentage of each, but I am happy to add some language saying that there performance benefits are highly dependent on hardware and software architecture, and that these cipher suites will not offer a performance benefit in all cases.

> In many IoT radio systems with small frames this will leads to significantly increased latency. I think that needs to be mentioned.
I am fine mentioning that and I think it helps broaden the reach.

>It would be more honest if the draft simply stated that "the are use cases that require visibility".
Many of these use cases were added at the request of various reviewers and contributors, so I do not want to remove them. I (and others) still believe that there are some cases where confidentiality provides little to no benefit. I think we have made efforts to note that this is not true in all cases (e.g. these ciphers suites being listed as not recommended, or adding specific language to the draft such as " The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but is presented here to enable interoperable implementation of a reduced  security mechanism that provides authentication and message integrity without supporting confidentiality."). To your point though I am happy to call out visibility as a use here.

Thanks,

--Jack

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of John Mattsson
Sent: Wednesday, February 10, 2021 4:15 AM
To: [email-masked]
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

Hi,

John

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!JhrIYaSK6lFZ!7EjueedGEojT6_EE6rVv6m7p6xV7TIVa0Jh6mtrMbM3qQbIW4M6C36Dzb4359xnpB5-_$

---

From: Jack Visoky <[email-masked]>
Date: Wed, 10 Feb 2021 22:56:18 +0000

Hi Stephen,

I believe the case of the robotic arm which paints cars would be a reasonable example of a case where confidentiality of data is not required. I fully admit that it's not generalizable to all robotic arms painting all cars, but I do believe it holds for many of these cases. At the risk of treading this ground again, could you elaborate on your thoughts around this use case?

Thanks,

--Jack

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Stephen Farrell
Sent: Wednesday, February 10, 2021 7:08 AM
To: John Mattsson <john.mattsson=[email-masked]>; [email-masked]
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

Hiya,

I realise it's not proposed as a wg document, but fwiw, I think John is quite correct below. The only additional point I'd add is that I've seen cases over the years where the fact that confidentiality really *is* required only became clear when people actually considered how to attack systems. I'd be happy to bet beers that will be the case with some examples mentioned in the draft, esp the wandering robotic arm.

This seems like a not that well done write-up of a bad idea to me.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 Feb 2021 23:36:34 +0000

I oppose this draft. Use earlier versions of TLS that do have auth-only and integrity cipher suites.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Feb 2021 23:45:42 +0000

Hiya,

On 10/02/2021 22:56, Jack Visoky wrote:
> Hi Stephen,
> 
> I believe the case of the robotic arm which paints cars would be a
> reasonable example of a case where confidentiality of data is not
> required. I fully admit that it's not generalizable to all robotic
> arms painting all cars, but I do believe it holds for many of these
> cases. At the risk of treading this ground again, could you elaborate
> on your thoughts around this use case?

Knowing the positioning of an arm from afar, via snooping on
the n/w, could allow an attacker to fine-tune an attack aimed
at e.g. reducing paint quality, forcing a recall, via changes
to a controller (i.e. not one of the TLS endpoints). That's
not very different to changing the spin-rate of a centrifuge,
an attack that we know was mounted, some time ago.

It's not hard to come up with arguments against these use
cases. I don't claim that those are winning arguments, and
I don't expect those who desire "visibility" will be won
over, but I do claim these are valid arguments for wanting
the "best" transport layer security we can get turned on
everywhere all the time, to the extent possible. I for one
believe experience so far has shown that to be the wisest
approach in general.

S.

> 
> Thanks,
> 
> --Jack
> 
> -----Original Message----- From: TLS <[email-masked]> On Behalf
> Of Stephen Farrell Sent: Wednesday, February 10, 2021 7:08 AM To:
> John Mattsson <john.mattsson=[email-masked]>;
> [email-masked] Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and
> Integrity only Cipher Suites
> 
> 
> Hiya,
> 
> I realise it's not proposed as a wg document, but fwiw, I think John
> is quite correct below. The only additional point I'd add is that
> I've seen cases over the years where the fact that confidentiality
> really *is* required only became clear when people actually
> considered how to attack systems. I'd be happy to bet beers that will
> be the case with some examples mentioned in the draft, esp the
> wandering robotic arm.
> 
>> "strong requirement for low latency." "minimize the cryptographic
>> algorithms are prioritized" "important for latency to be very
>> low." "pay more for a sensor with encryption capability" "come with
>> a small runtime memory footprint and reduced processing power, the
>> need to minimize" the number of cryptographic algorithms used is
>> prioritized."
>> 
>> I don't think this draft should be published as long as it gives
>> the idea that sacrificing confidentiality has significant benefits
>> for latency, memory, processing power, and cost. This is in general
>> not the case.
>> 
>> The two cipher suites TLS_SHA256_SHA256 and TLS_SHA384_SHA384
>> defined by the draft causes much more message expansion (32 and 48
>> bytes tags instead of 16 or 8 bytes) than the already registered
>> cipher suites for TLS 1.3. In many IoT radio systems with small
>> frames this will leads to significantly increased latency. I think
>> that needs to be mentioned.
>> 
>> 
>> "do not require confidentiality" "privacy is not strictly needed" 
>> "no strong requirement for confidentiality" "no requirement to
>> encrypt messages" "no need for confidentiality" "reduced need for
>> confidentiality" "confidentiality requirements are relaxed" "do not
>> require confidential communications" "does not convey private
>> information" "without requiring the communication to/from the
>> robotic arm to be encrypted" "doesn't grant the attacker
>> information that can be exploited" "no confidentiality
>> requirements"
>> 
>> It would be more honest if the draft simply stated that "the are
>> use cases that require visibility". If visibility is not a
>> requirement for the use cases, I think IETF could help you to
>> standardize SHA-2 only cipher suites offering confidentiality.
>> 
>> 
>> - The draft mentions that the security considerations regarding
>> confidentiality and privacy does not hold. The draft does not
>> mention that it breaks one of the stated security properties of TLS
>> 1.3, namely "Protection of endpoint identities". This is actually
>> quite problematic. EAP-TLS 1.3 relied on this stated TLS 1.3
>> property to be true.
>> 
>> John
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 10 Feb 2021 17:25:22 -0800

I also do not support this draft. Don't all of these proposals come with
claims about efficiency and latency? It's getting old. Sorry if that sounds
cynical.

thanks,
Rob

On Wed, Feb 10, 2021 at 1:15 AM John Mattsson <john.mattsson=
[email-masked]> wrote:

>   I don't think this draft should be published as long as it gives the
> idea that sacrificing confidentiality has significant benefits for latency,
> memory, processing power, and cost. This is in general not the case.
>
>   The two cipher suites TLS_SHA256_SHA256 and TLS_SHA384_SHA384  defined
> by the draft causes much more message expansion (32 and 48 bytes tags
> instead of 16 or 8 bytes) than the already registered cipher suites for TLS
> 1.3. In many IoT radio systems with small frames this will leads to
> significantly increased latency. I think that needs to be mentioned.
>
>
>   It would be more honest if the draft simply stated that "the are use
> cases that require visibility". If visibility is not a requirement for the
> use cases, I think IETF could help you to standardize SHA-2 only cipher
> suites offering confidentiality.
>
>
> confidentiality and privacy does not hold. The draft does not mention that
> it breaks one of the stated security properties of TLS 1.3, namely
> "Protection of endpoint identities". This is actually quite problematic.
> EAP-TLS 1.3 relied on this stated TLS 1.3 property to be true.
>
> John
>

---

From: Jack Visoky <[email-masked]>
Date: Thu, 11 Feb 2021 01:57:34 +0000

Hi Stephen,

Thanks for elaborating.

From the general standpoint I think we can both agree an attacker can more easily cause more harm if packets can be modified than not modified, especially in the use case examples. Now of course I can't and don't claim in all cases of a robotic arm (or any other general example) an attacker can't cause damage by simply reading data. For the example you give, it sounds like "changes to the controller" involve things like packet drops. The attacker can't simply connect to the controller and reconfigure it due to the TLS authentication, and can't modify packets due to the same. I'd claim that in general the "packet dropping attack" ranges from marginally more effective to no difference by the attacker knowing the position/speed. In general I'd say it wouldn't be easy to change centrifuge spin rate if all connections have SHA-256 HMACS on their data and use mutual authentication via certificates and/or PSKs. Again a generality but usually these systems need to be designed such that network noise, unexpected power cycle, etc. can be handled without causing major harm (although conversely any downtime is usually money lost, but again you don't need exact position data to cause that). We can certainly debate the edges on this, but I'd still say that a system like this makes a giant improvement moving from no communication security to TLS without encryption, and doesn't gain anything close to that benefit by then moving to encryption. All that said I am absolutely not against encryption, and I think it should be used as much as possible even in industrial/IoT cases. I would just like to recognize that there are some situations where it isn't needed.

Thanks,

--Jack

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: Wednesday, February 10, 2021 6:46 PM
To: Jack Visoky <[email-masked]>; John Mattsson <john.mattsson=[email-masked]>; [email-masked]
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

Hiya,

> on your thoughts around this use case?

Knowing the positioning of an arm from afar, via snooping on the n/w, could allow an attacker to fine-tune an attack aimed at e.g. reducing paint quality, forcing a recall, via changes to a controller (i.e. not one of the TLS endpoints). That's not very different to changing the spin-rate of a centrifuge, an attack that we know was mounted, some time ago.

It's not hard to come up with arguments against these use cases. I don't claim that those are winning arguments, and I don't expect those who desire "visibility" will be won over, but I do claim these are valid arguments for wanting the "best" transport layer security we can get turned on everywhere all the time, to the extent possible. I for one believe experience so far has shown that to be the wisest approach in general.

S.

> is quite correct below. The only additional point I'd add is that I've 
> seen cases over the years where the fact that confidentiality really 
> *is* required only became clear when people actually considered how to 
> attack systems. I'd be happy to bet beers that will be the case with 
> some examples mentioned in the draft, esp the wandering robotic arm.
> 
>> algorithms are prioritized" "important for latency to be very low." 
>> "pay more for a sensor with encryption capability" "come with a small 
>> runtime memory footprint and reduced processing power, the need to 
>> minimize" the number of cryptographic algorithms used is 
>> prioritized."
>> 
>> idea that sacrificing confidentiality has significant benefits for 
>> latency, memory, processing power, and cost. This is in general not 
>> the case.
>> 
>> instead of 16 or 8 bytes) than the already registered cipher suites 
>> for TLS 1.3. In many IoT radio systems with small frames this will 
>> leads to significantly increased latency. I think that needs to be 
>> mentioned.
>> 
>> 
>> information" "without requiring the communication to/from the robotic 
>> arm to be encrypted" "doesn't grant the attacker information that can 
>> be exploited" "no confidentiality requirements"
>> 
>> cases that require visibility". If visibility is not a requirement 
>> for the use cases, I think IETF could help you to standardize SHA-2 
>> only cipher suites offering confidentiality.
>> 
>> 
>> confidentiality and privacy does not hold. The draft does not mention 
>> that it breaks one of the stated security properties of TLS 1.3, 
>> namely "Protection of endpoint identities". This is actually quite 
>> problematic. EAP-TLS 1.3 relied on this stated TLS 1.3 property to be 
>> true.
>> 
>> John
>>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Feb 2021 02:01:52 +0000

> I would just like to recognize that there are some situations where it isn't needed.

Can you explain why TLS 1.2 isn't good enough for your needs?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Feb 2021 00:40:51 -0200

> On Feb 10, 2021, at 11:57 PM, Jack Visoky <jmvisoky=[email-masked]> wrote:
> 

One classic case where Postfix supports TLS 1.[0-2] NULL ciphers
is loopback TLS (process to process communication via [127.0.0.1]
or a unix-domain socket).  Here, one would generally not use TLS
at all, but it can be useful for client authentication.

The use-case is far from common, and encrypting anyway is typically
a viable alternative, but there is a sound case that encryption adds
little value, if you can capture the traffic on [127.0.0.1] you can
also capture the same content prior to encryption (just trace the
sending process reading cleartext data from disk, or the receiving
process writing it to disk).

I am not saying there is or is not a compelling case for NULL ciphers,
but just noting a use-case where encryption does not add much value.

Performance-wise, indeed on many a CPU AESGCM is cheaper than SHA2.
So turning off encryption is not always a performance win.  It rather
depends...

If client and server conditionally support NULL ciphers in a debugging
configuration, one might also be able to debug some TLS-related problems
that are otherwise difficult to debug.  This too is a rare situation, and
comes with a risk of accidental misuse.

There is merit in keeping the combinatorial complexity of TLS 1.3
as small as possible, reducing implementation attack surface, ...

The key question, that is difficult to answer is whether the right
balance is adequately accomplished with "N" in the recommended column,
with most implementations then either not supporting said ciphersuites
at all, or disabling them by default.  If so, perhaps some specialised
implementations could use them appropriately.  On the other hand the
"specialised" applications might get used outside their originally
intended use-cases, in ways the designers never anticipated.

Do we leave the choice to use TLS wisely to the developers and users,
or we judge that misuse is inevitable, and the use-case not sufficiently
compelling?  I am somewhat inclined to do the latter.  Despite the fact
that'd I'd otherwise be inclined to argue for anonDH ciphers, which have
reasonable applications in unauthenticated opportunistic TLS, where any
presented certificates are just ignored bloat that increase the attack
surface.  I would have liked to see support for these retained in TLS 1.3,
but accept their omission as a legitimate tradeoff.  If NULL ciphers are
added (which IMHO are the greater risk), then perhaps I'd have a good
case to make to have anonDH/anonECDH ciphers re-introduced...

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Feb 2021 02:47:46 +0000

Hiya,

First, a caveat - I don't know and am guessing how these
systems are built (if you have pointers, those'd be good
to see), but nonetheless...

On 11/02/2021 01:57, Jack Visoky wrote:
> Hi Stephen,
> 
> Thanks for elaborating.
> 
> From the general standpoint I think we can both agree an attacker can
> more easily cause more harm if packets can be modified than not
> modified, especially in the use case examples. 

I don't think that's the interesting question here. We're
only discussing the differences between ciphersuites that
do, or do not, provide confidentiality.

> Now of course I can't
> and don't claim in all cases of a robotic arm (or any other general
> example) an attacker can't cause damage by simply reading data. For
> the example you give, it sounds like "changes to the controller"
> involve things like packet drops. The attacker can't simply connect
> to the controller and reconfigure it due to the TLS authentication,

Ah. There I don't agree. Attackers don't have to play by
our rules. They may have a supply-chain or other attack on
some of the upstream controller components and/or control an
application layer at some point. If they can also see the
fine-grained effects of their changes at the downstream
arm-movement, then I'm arguing that they may be in a much
better position to effect a persistent and agile attack that
results in paint-jobs that pass QA checks, but that later
cause expensive recalls. If OTOH, the active attack code
can't benefit from "visibility" of the fine-grained effects
of its changes on the paint arms, then my assertion is that
QA and other checks should have an easier time being
effective in detecting the dodgy outcome of the borked
painting process.

> and can't modify packets due to the same. I'd claim that in general
> the "packet dropping attack" ranges from marginally more effective to
> no difference by the attacker knowing the position/speed. In general
> I'd say it wouldn't be easy to change centrifuge spin rate if all
> connections have SHA-256 HMACS on their data and use mutual
> authentication via certificates and/or PSKs. Again a generality but
> usually these systems need to be designed such that network noise,
> unexpected power cycle, etc. can be handled without causing major
> harm (although conversely any downtime is usually money lost, but
> again you don't need exact position data to cause that). We can
> certainly debate the edges on this, but I'd still say that a system
> like this makes a giant improvement moving from no communication
> security to TLS without encryption, and doesn't gain anything close
> to that benefit by then moving to encryption. 

You'll not be surprised that I'm unconvinced:-) Aside from my
almost movie-plot attack (but recalling that stuxnet really dud happen), 
I'd be very surprised if specific robot arms
were programmed to use different ciphersuites according to
the actual situational risks involved. And if they could be,
it'd still be easier to just use the recommended ciphersuites
and not bother with being such an awkward child and omitting
confidentiality. Were I procuring equipment, I'd much prefer
to buy robots that had the same transport layer security as
all the other parts of my overall manufacturing system and
not have to do the special additional analysis caused by odd
stacks that behave differently in subtle ways. In such a case
I'd really want a massive payoff for such subtle divergences,
before I'd even think about ok'ing 'em. For the draft in
question, I honestly cannot see even the possibility of such
a massive payoff.

> All that said I am
> absolutely not against encryption, and I think it should be used as
> much as possible even in industrial/IoT cases. I would just like to
> recognize that there are some situations where it isn't needed.

I consider that last assertion unproven and likely false. The
game here is defining (or not defining) ciphersuites that are
useful in many, many scenarios. My conclusion is that we all
lose if we do as this draft proposes and define ciphersuites
that can be dangerous in unexpected and hard to analyse ways,
should they get widely deployed. (And I hope we've all
learned that undeploying these things is a big pile of
painful work, to put in very nicely:-)

Cheers,
S.

> 
> Thanks,
> 
> --Jack
> 
> -----Original Message----- From: Stephen Farrell
> <[email-masked]> Sent: Wednesday, February 10, 2021 6:46
> PM To: Jack Visoky <[email-masked]>; John Mattsson
> <john.mattsson=[email-masked]>; [email-masked] Subject:
> Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
> Suites
> 
> 
> Hiya,
> 
>> arms painting all cars, but I do believe it holds for many of
>> these cases. At the risk of treading this ground again, could you
>> elaborate on your thoughts around this use case?
> 
> Knowing the positioning of an arm from afar, via snooping on the n/w,
> could allow an attacker to fine-tune an attack aimed at e.g. reducing
> paint quality, forcing a recall, via changes to a controller (i.e.
> not one of the TLS endpoints). That's not very different to changing
> the spin-rate of a centrifuge, an attack that we know was mounted,
> some time ago.
> 
> It's not hard to come up with arguments against these use cases. I
> don't claim that those are winning arguments, and I don't expect
> those who desire "visibility" will be won over, but I do claim these
> are valid arguments for wanting the "best" transport layer security
> we can get turned on everywhere all the time, to the extent possible.
> I for one believe experience so far has shown that to be the wisest
> approach in general.
> 
> S.
> 
>> 
>> Thanks,
>> 
>> --Jack
>> 
>> -----Original Message----- From: TLS <[email-masked]> On
>> Behalf Of Stephen Farrell Sent: Wednesday, February 10, 2021 7:08
>> AM To: John Mattsson
>> <john.mattsson=[email-masked]>; [email-masked]
>> I realise it's not proposed as a wg document, but fwiw, I think
>> John is quite correct below. The only additional point I'd add is
>> that I've seen cases over the years where the fact that
>> confidentiality really *is* required only became clear when people
>> actually considered how to attack systems. I'd be happy to bet
>> beers that will be the case with some examples mentioned in the
>> draft, esp the wandering robotic arm.
>> 
>>> "strong requirement for low latency." "minimize the
>>> cryptographic algorithms are prioritized" "important for latency
>>> to be very low." "pay more for a sensor with encryption
>>> capability" "come with a small runtime memory footprint and
>>> reduced processing power, the need to minimize" the number of
>>> cryptographic algorithms used is prioritized."
>>> 
>>> the idea that sacrificing confidentiality has significant
>>> benefits for latency, memory, processing power, and cost. This is
>>> in general not the case.
>>> 
>>> defined by the draft causes much more message expansion (32 and
>>> 48 bytes tags instead of 16 or 8 bytes) than the already
>>> registered cipher suites for TLS 1.3. In many IoT radio systems
>>> with small frames this will leads to significantly increased
>>> latency. I think that needs to be mentioned.
>>> 
>>> 
>>> "do not require confidentiality" "privacy is not strictly
>>> needed" "no strong requirement for confidentiality" "no
>>> requirement to encrypt messages" "no need for confidentiality"
>>> "reduced need for confidentiality" "confidentiality requirements
>>> are relaxed" "do not require confidential communications" "does
>>> not convey private information" "without requiring the
>>> communication to/from the robotic arm to be encrypted" "doesn't
>>> grant the attacker information that can be exploited" "no
>>> confidentiality requirements"
>>> 
>>> mention that it breaks one of the stated security properties of
>>> TLS 1.3, namely "Protection of endpoint identities". This is
>>> actually quite problematic. EAP-TLS 1.3 relied on this stated TLS
>>> 1.3 property to be true.
>>> 
>>> John
>>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Feb 2021 19:23:57 -0800

> case to make to have anonDH/anonECDH ciphers re-introduced...

The WG has delegated this decision to the Designated Experts that serve
for the relevant IANA registry.  In point of fact, the experts have already
approved ciphersuite codepoints for these ciphers (a couple years ago, IIRC),
so in some sense the decisions (or "a decision"?) has already been made.

The WG could, of course, decide to provide additional input to the Experts
in the form of a new RFC (or a number of other ways), including
clarifying how the requirement in Appendix D.5 that "ciphers with a strength
less than 112 bits MUST NOT be offered or negotiated for any version of TLS for
any reason" is to be interpreted, whether NULL encryption is compatible with
an AEAD requirement, etc.

On the other hand, I suspect that attempts to make the registration policy
too strict would just lead to codepoint squatting, a phenomenon with which
we have some real-world experience...

-Ben

---

From: Jack Visoky <[email-masked]>
Date: Thu, 11 Feb 2021 19:08:27 +0000

Hi Stephen,

I don't have quick and simple guide for how the systems are built sadly. I will say in this context I am representing a group that defines industrial comms called ODVA (https://www.odva.org/), although am drawing on my experience in Industrial Communications beyond just ODVA. Perhaps our website might provide some basic info.

>>Ah. There I don't agree. Attackers don't have to play by our rules...
Well if they can change downstream arm-movement then we have already lost. The relevant variable here is whether or not the can affect operation of the arm's movement, either through MitM packet modification, reconfiguration of equipment, or otherwise. Seeing effects of the movement is likely not done with packet inspection, especially if you are controlling one end of the communication (in which case you already know what packets are sent). In other words I am having trouble discerning the causal chain that gets us from packet inspection to material damage without allowing untrusted comms or packet modification (at least in a general case).

>>You'll not be surprised that I'm unconvinced:-) ...
Alas you are right I'm not surprised :-) First I'd say I don't at all consider this far-fetched, and you rightly point out that Stuxnet was a real thing. That said I do know of at least one product which allows different cipher suites to be used for what is termed "I/O" (think robot arm position control) versus "messaging" (think configuration). At least in this product it is pretty straightforward via a drop down menu. Also to your point about the same transport layer security, yes I 100% agree, and that is a (strong) reason that we want to have these cipher suites in support of the industrial use case. I'll admit the Industrial comms community is not large but I have not yet met someone saying that they want encryption everywhere, in my experience there is a strong desire for these integrity-only cipher suites.

>> I consider that last assertion unproven and likely false...
I'm not surprised that there is a strong bias towards confidentiality but I am a little surprised that there seems to be at least a strong feeling that non-confidentiality cipher suites have no use whatsoever. I would certainly defer and even agree that in the web use case they are of no use, but the machine-to-machine case is different. Further, it looks like there are already several other ciphers registered for use in TLS 1.3. I can't comment on their viability but I would imagine that diverse cipher suites might provide some different information assurance properties, strengths, weaknesses, etc. In other words just because there are trade-offs doesn't mean they shouldn't be registered.

Regardless, I really do appreciate your perspective even if I have some disagreements. At least for me it helps my learning and understanding to hear from experts such as yourself and others on this list.

Thanks,

--Jack

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: Wednesday, February 10, 2021 9:48 PM
To: Jack Visoky <[email-masked]>; [email-masked]
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

Hiya,

First, a caveat - I don't know and am guessing how these systems are built (if you have pointers, those'd be good to see), but nonetheless...

> modified, especially in the use case examples.

I don't think that's the interesting question here. We're only discussing the differences between ciphersuites that do, or do not, provide confidentiality.

> involve things like packet drops. The attacker can't simply connect to 
> the controller and reconfigure it due to the TLS authentication,

Ah. There I don't agree. Attackers don't have to play by our rules. They may have a supply-chain or other attack on some of the upstream controller components and/or control an application layer at some point. If they can also see the fine-grained effects of their changes at the downstream arm-movement, then I'm arguing that they may be in a much better position to effect a persistent and agile attack that results in paint-jobs that pass QA checks, but that later cause expensive recalls. If OTOH, the active attack code can't benefit from "visibility" of the fine-grained effects of its changes on the paint arms, then my assertion is that QA and other checks should have an easier time being effective in detecting the dodgy outcome of the borked painting process.

> unexpected power cycle, etc. can be handled without causing major harm 
> (although conversely any downtime is usually money lost, but again you 
> don't need exact position data to cause that). We can certainly debate 
> the edges on this, but I'd still say that a system like this makes a 
> giant improvement moving from no communication security to TLS without 
> encryption, and doesn't gain anything close to that benefit by then 
> moving to encryption.

You'll not be surprised that I'm unconvinced:-) Aside from my almost movie-plot attack (but recalling that stuxnet really dud happen), I'd be very surprised if specific robot arms were programmed to use different ciphersuites according to the actual situational risks involved. And if they could be, it'd still be easier to just use the recommended ciphersuites and not bother with being such an awkward child and omitting confidentiality. Were I procuring equipment, I'd much prefer to buy robots that had the same transport layer security as all the other parts of my overall manufacturing system and not have to do the special additional analysis caused by odd stacks that behave differently in subtle ways. In such a case I'd really want a massive payoff for such subtle divergences, before I'd even think about ok'ing 'em. For the draft in question, I honestly cannot see even the possibility of such a massive payoff.

> recognize that there are some situations where it isn't needed.

I consider that last assertion unproven and likely false. The game here is defining (or not defining) ciphersuites that are useful in many, many scenarios. My conclusion is that we all lose if we do as this draft proposes and define ciphersuites that can be dangerous in unexpected and hard to analyse ways, should they get widely deployed. (And I hope we've all learned that undeploying these things is a big pile of painful work, to put in very nicely:-)

Cheers,
S.

> <[email-masked]> Sent: Wednesday, February 10, 2021 6:46 PM 
> To: Jack Visoky <[email-masked]>; John Mattsson 
> don't claim that those are winning arguments, and I don't expect those 
> who desire "visibility" will be won over, but I do claim these are 
> valid arguments for wanting the "best" transport layer security we can 
> get turned on everywhere all the time, to the extent possible.
>>> "pay more for a sensor with encryption capability" "come with a 
>>> small runtime memory footprint and reduced processing power, the 
>>> 48 bytes tags instead of 16 or 8 bytes) than the already registered 
>>> encrypt messages" "no need for confidentiality"
>>> "reduced need for confidentiality" "confidentiality requirements are 
>>> relaxed" "do not require confidential communications" "does not 
>>> convey private information" "without requiring the communication 
>>> to/from the robotic arm to be encrypted" "doesn't grant the attacker 
>>> information that can be exploited" "no confidentiality requirements"
>>> 
>>> quite problematic. EAP-TLS 1.3 relied on this stated TLS
>>> 1.3 property to be true.
>>> 
>>> John
>>>