Hi Joe, On 06/11/17 01:57, Joseph Salowey 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.
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. > > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
