Subject: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

From: Cas Cremers <[email-masked]>
Date: Fri, 3 Nov 2017 13:42:33 +0000

Dear all,
​​
​​Disclaimer: I am not a proponent of the idea behind draft
visibility/green/rhrd; I think such a mechanism should not be part of the
TLS 1.3 standard.
​​
​​I have a technical problem with the current design, whose goal is to
allow eavesdropping for inspection, i.e., selectively decreasing
confidentiality.
​​
​​However, the design in the draft also enables arbitrary traffic
modification/insertion, additionally breaking all authentication and
integrity guarantees. Once someone has the session keys, they can not only
eavesdrop but can also start to insert/modify traffic. This additional
decrease in security is entirely unmotivated by the cited use cases.
​​
​​It is possible to offer authentication and integrity, while selectively
giving up confidentiality. For example, one could replace the AEAD by (i) a
mechanism for authentication and (ii) a separate mechanism for
confidentiality, and then possibly reveal the keys used for (ii), but make
sure only the real endpoint has the keys for (i). That seems more rational
to me, and may retain the authentication/integrity guarantees. However, it
would require a much more invasive change.
​​
​​Best,
​​
​​Cas

---

From: Richard Barnes <[email-masked]>
Date: Fri, 3 Nov 2017 10:00:19 -0400

Hey Cas,

This question is a good one.  Earlier I brought up mcTLS, which some folks
have been working on to provide even more granular separations than you
suggest:

https://mctls.org/

I think the authors of draft-rhrd are trying for a more lightweight change
to TLS.  That said, there might be some intermediate points on the spectrum
here.  For example, you could define a TLS ciphersuite akin to what we
defined in PERC when we wanted to break integrity partly and
confidentiality not at all.

https://tools.ietf.org/html/draft-ietf-perc-double-07

That would be less invasive than mcTLS, while still getting the properties
you describe.

--Richard

On Nov 3, 2017 09:43, "Cas Cremers" <[email-masked]> wrote:

Dear all,
​​

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

---

From: Cas Cremers <[email-masked]>
Date: Fri, 3 Nov 2017 14:41:02 +0000

Hi Richard,

Thanks for the pointer, I had missed your earlier observation of
essentially the same thing in the large mail threads.

Personally, I think it is a substantial and unmotivated loss in security to
also give up authentication/integrity.

Note that any changes towards PERC would require some significant changes
in the security analyses; for mctls, I expect it would be a completely new
analysis. (I haven't seen any analyses of rhrd, but of the three, it is of
course closest to the current setup.)

Best,

Cas

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 5 Nov 2017 17:57:00 -0800

I'm not sure what use cases you are targeting, but this type of solution
can be dangerous for application security. Most application security models
assume that TLS will provide both confidentiality and authenticity.
Breaking confidentiality will often expose vulnerabilities that can result
in escalation of privilege or spoofing resulting in a loss of
integrity/authenticity in the application. For example, the use bearer
tokens such as passwords or session cookies is widespread. It will take
much more work to make applications resilient to loss of confidentiality.
There may be use cases where confidentiality compromise is limited to just
confidentiality, but I think these are in the minority.

Joe

On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers <[email-masked]> wrote:

> Personally, I think it is a substantial and unmotivated loss in security
> to also give up authentication/integrity.
>
>> This question is a good one.  Earlier I brought up mcTLS, which some
>> folks have been working on to provide even more granular separations than
>> you suggest:
>>
>> https://mctls.org/
>>
>> I think the authors of draft-rhrd are trying for a more lightweight
>> change to TLS.  That said, there might be some intermediate points on the
>> spectrum here.  For example, you could define a TLS ciphersuite akin to
>> what we defined in PERC when we wanted to break integrity partly and
>> That would be less invasive than mcTLS, while still getting the
>> properties you describe.
>>
>> --Richard
>>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 6 Nov 2017 02:05:14 +0000

Hi Joe,

> confidentiality, but I think these are in the minority.

I kind-of agree but not fully.

Where we agree is that any change to the basic security
services offered by TLS affect the interface between the
TLS layer and the application. Ans any changes caused by
breaking-TLS will break applications, as the existing
APIs will no longer match whatever security model was in
the application developer's mind when code was written.

We also have real-world measurements that show that TLS
APIs are frequently misused by developers in any case, so
there is little hope that some more complex API that does
reflect broken-TLS can ever be effective.

Bottom line: breaking TLS will break many applications,
regardless of how one chooses to break TLS, partly at
least because the interfaces between TLS and applications
do not envisage broken-TLS.

S.

---

From: Richard Barnes <[email-masked]>
Date: Sun, 5 Nov 2017 22:38:36 -0500

I understood Cas to be observing that you could in principle remove
confidentiality with regard to the third party to whom keys are being
exfiltrated, without also removing integrity and authenticity.  So the
third party could observe application traffic, but not modify or inject.
The solution in draft-rhrd removes all three properties with regard to the
third party (all still of course hold with regard to all other attackers).

So you would still have a risk of violating applications' assumptions with
regard to confidentiality, but only with regard to confidentiality, and
only relative to the chosen third party.   To Stephen's point, though, this
is of course a pretty subtle point for application developers to understand.

--Richard

On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey <[email-masked]> wrote:

>>> ​​It is possible to offer authentication and integrity, while
>>> selectively giving up confidentiality. For example, one could replace the
>>> AEAD by (i) a mechanism for authentication and (ii) a separate mechanism
>>> for confidentiality, and then possibly reveal the keys used for (ii), but
>>> make sure only the real endpoint has the keys for (i). That seems more
>>> rational to me, and may retain the authentication/integrity guarantees.
>>> However, it would require a much more invasive change.
>>> ​​
>>> ​​Best,
>>> ​​
>>> ​​Cas
>>>
>>>

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 5 Nov 2017 20:39:32 -0800

I'm in agreement with Stephen.  If you compromise TLS confidentiality you
are going to break application security. For most applications a loss in
confidentiality in TLS will have an impact in other aspects of security.
 The third-party will often be able to inject application traffic, although
it may need to do this over a separate connection.

On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes <[email-masked]> wrote:

>>> Note that any changes towards PERC would require some significant
>>> changes in the security analyses; for mctls, I expect it would be a
>>> completely new analysis. (I haven't seen any analyses of rhrd, but of the
>>> three, it is of course closest to the current setup.)
>>>
>>> Best,
>>>
>>> Cas
>>>
>>>

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 6 Nov 2017 07:38:48 +0100

Visibility goes both ways. The discussion so far has been primarily about making end-to-end data visible to middleboxes.
It would less concerning to do it the other way round, where middleboxes are made visible to the endpoints, and proxying/visbility decisions are made at the endpoints.
Indeed, this is one of the main ideas behind mcTLS: middleboxes don’t get to transparently inject themselves into a TLS channel, they must be authorized by *both* endpoints.

But even a careful design like mcTLS ends up losing significant authentication and integrity properties, both in the handshake and the record layer. (If someone is interested, send me email, and I can give you details.)
So, I really don’t recommend any change to the TLS 1.3 design to accomplish any of this, it is more likely that the change will break “normal” TLS connections.

If visibility is needed in some scenario, then I would prefer that it be done at the application layer, by a proxy that is visible to and authorized by at least one endpoint, if not both.

-Karthik

> On 6 Nov 2017, at 05:39, Joseph Salowey <[email-masked]> wrote:
> 
> I'm in agreement with Stephen.  If you compromise TLS confidentiality you are going to break application security. For most applications a loss in confidentiality in TLS will have an impact in other aspects of security.   The third-party will often be able to inject application traffic, although it may need to do this over a separate connection.
> 
> On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> I understood Cas to be observing that you could in principle remove confidentiality with regard to the third party to whom keys are being exfiltrated, without also removing integrity and authenticity.  So the third party could observe application traffic, but not modify or inject.  The solution in draft-rhrd removes all three properties with regard to the third party (all still of course hold with regard to all other attackers).
> 
> So you would still have a risk of violating applications' assumptions with regard to confidentiality, but only with regard to confidentiality, and only relative to the chosen third party.   To Stephen's point, though, this is of course a pretty subtle point for application developers to understand.
> 
> --Richard
> 
> 
> On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> I'm not sure what use cases you are targeting, but this type of solution can be dangerous for application security. Most application security models assume that TLS will provide both confidentiality and authenticity. Breaking confidentiality will often expose vulnerabilities that can result in escalation of privilege or spoofing resulting in a loss of integrity/authenticity in the application. For example, the use bearer tokens such as passwords or session cookies is widespread. It will take much more work to make applications resilient to loss of confidentiality. There may be use cases where confidentiality compromise is limited to just confidentiality, but I think these are in the minority.
> 
> Joe
> 
> On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Richard,
> 
> Thanks for the pointer, I had missed your earlier observation of essentially the same thing in the large mail threads.
> 
> Personally, I think it is a substantial and unmotivated loss in security to also give up authentication/integrity.
> 
> Note that any changes towards PERC would require some significant changes in the security analyses; for mctls, I expect it would be a completely new analysis. (I haven't seen any analyses of rhrd, but of the three, it is of course closest to the current setup.)
> 
> Best,
> 
> Cas
> 
> 
> On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> Hey Cas,
> 
> This question is a good one.  Earlier I brought up mcTLS, which some folks have been working on to provide even more granular separations than you suggest:
> 
> https://mctls.org/ <https://mctls.org/>
> 
> I think the authors of draft-rhrd are trying for a more lightweight change to TLS.  That said, there might be some intermediate points on the spectrum here.  For example, you could define a TLS ciphersuite akin to what we defined in PERC when we wanted to break integrity partly and confidentiality not at all.
> 
> https://tools.ietf.org/html/draft-ietf-perc-double-07 <https://tools.ietf.org/html/draft-ietf-perc-double-07>
> 
> That would be less invasive than mcTLS, while still getting the properties you describe.
> 
> --Richard
> 
> 
> On Nov 3, 2017 09:43, "Cas Cremers" <[email-masked] <mailto:[email-masked]>> wrote:
> Dear all,
> ​​
> ​​Disclaimer: I am not a proponent of the idea behind draft visibility/green/rhrd; I think such a mechanism should not be part of the TLS 1.3 standard.
> ​​
> ​​I have a technical problem with the current design, whose goal is to allow eavesdropping for inspection, i.e., selectively decreasing confidentiality.
> ​​
> ​​However, the design in the draft also enables arbitrary traffic modification/insertion, additionally breaking all authentication and integrity guarantees. Once someone has the session keys, they can not only eavesdrop but can also start to insert/modify traffic. This additional decrease in security is entirely unmotivated by the cited use cases.
> ​​
> ​​It is possible to offer authentication and integrity, while selectively giving up confidentiality. For example, one could replace the AEAD by (i) a mechanism for authentication and (ii) a separate mechanism for confidentiality, and then possibly reveal the keys used for (ii), but make sure only the real endpoint has the keys for (i). That seems more rational to me, and may retain the authentication/integrity guarantees. However, it would require a much more invasive change.
> ​​
> ​​Best,
> ​​
> ​​Cas
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> 
>

---

From: Cas Cremers <[email-masked]>
Date: Mon, 6 Nov 2017 12:17:48 +0000

I agree with most of the above; my point was not to propose another
mechanism, but just to make explicit (as Richard had indicated earlier)
that the current design gives up much more security than it strictly seems
to need for its claimed use cases.

I'm not recommending any changes to the TLS 1.3 design, and agree that it
is very likely that many more things would be broken in the process.

Indeed, giving up confidentiality of the channel but retaining channel
authentication does not ensure authentication at the application layer,
because most application-level security guarantees rely on the
confidentiality of the channel. However, I don't find that a great argument
to immediately give up on authentication/integrity of the channel.

Best,

Cas

On Mon, Nov 6, 2017 at 6:38 AM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> Visibility goes both ways. The discussion so far has been primarily about
> making end-to-end data visible to middleboxes.
> It would less concerning to do it the other way round, where middleboxes
> are made visible to the endpoints, and proxying/visbility decisions are
> made at the endpoints.
> Indeed, this is one of the main ideas behind mcTLS: middleboxes don’t get
> to transparently inject themselves into a TLS channel, they must be
> authorized by *both* endpoints.
>
> But even a careful design like mcTLS ends up losing significant
> authentication and integrity properties, both in the handshake and the
> record layer. (If someone is interested, send me email, and I can give you
> details.)
> So, I really don’t recommend any change to the TLS 1.3 design to
> accomplish any of this, it is more likely that the change will break
> “normal” TLS connections.
>
> If visibility is needed in some scenario, then I would prefer that it be
> done at the application layer, by a proxy that is visible to and authorized
> by at least one endpoint, if not both.
>
> -Karthik
>
>
>
>> So you would still have a risk of violating applications' assumptions
>> with regard to confidentiality, but only with regard to confidentiality,
>> and only relative to the chosen third party.   To Stephen's point, though,
>> this is of course a pretty subtle point for application developers to
>> understand.
>>
>> --Richard
>>
>>
>>>> Personally, I think it is a substantial and unmotivated loss in
>>>> security to also give up authentication/integrity.
>>>>