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

[Cas Cremers <[e-mail]>]

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 <
[e-mail]> 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
>
>
>
> On 6 Nov 2017, at 05:39, Joseph Salowey <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]> 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/
>>>>>
>>>>> 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" <[e-mail]> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>
>>>
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>