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 <r...@ipv.sx> 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 <j...@salowey.net> 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 <cas.crem...@cs.ox.ac.uk> >> 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 <r...@ipv.sx> 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" <cas.crem...@cs.ox.ac.uk> 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 >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
