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,
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
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 d
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 confidentialit
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 esca
➢ At any rate, the discussion of the proposal, if there is to be one,
belongs on the mailing list. Having the discussion and coming to
a conclusion 1) during a meeting 2) where none of the proponents
is present seems like an abuse of process to me
I asked for time so that we could dis
On 11/5/17 7:14 AM, Ted Lemon wrote:
> My point here is that that's not the reason to reject the document.
> The reason in this case is that there already exist better ways to solve
> the problem, and the proposal would clearly make TLS 1.3 worse, even
> though there is disagreement about how /mu
On Nov 5, 2017, at 5:09 PM, Salz, Rich wrote:
> I didn’t say votes.
Sure, but you did say "only the authors are interested" which to me seems to
imply a comparison of numbers. Sometimes everybody who's interested in an
idea is an author; that doesn't mean it's a bad idea. There have been ca
* Consensus isn't about number of votes. However, I think we can say that
although there seems to be some interest in making sure this use case is
addressed, there are known ways of addressing it, and little interest in
inventing a new way that weakens a new feature of tls 1.3
I didn’t say
* Nancy Cam-Winget:
> @IETF99, awareness was raised to some of the security WGs (thanks
> Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in
> TLS 1.2 and asked what the implications would be for the security
> solutions today.
> https://tools.ietf.org/html/draft-camwinget-tls-
Hiya,
On 05/11/17 13:09, Ted Lemon wrote:
> Consensus isn't about number of votes. However, I think we can say that
> although there seems to be some interest in making sure this use case is
> addressed, there are known ways of addressing it, and little interest in
> inventing a new way that weak
Consensus isn't about number of votes. However, I think we can say that
although there seems to be some interest in making sure this use case is
addressed, there are known ways of addressing it, and little interest in
inventing a new way that weakens a new feature of tls 1.3
On Nov 5, 2017 14:03,
So if the only people in favor of it are the draft authors, then we have
consensus, right?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
13 matches
Mail list logo
