I fail to see how the current draft can be used to provide visibility to an IPS
system in order to detect bots that are inside the bank…
On the one hand, the bot would never opt-in for visibility if it’s trying to
exfiltrate data, so this capability would never get activated. And even if the
bo
> -Mensaje original-
> De: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
> Enviado el: jueves, 15 de marzo de 2018 18:42
> Para: Carl Mehner
> CC: Ion Larranaga Azcue ; tls@ietf.org
> Asunto: Re: [TLS] Breaking into TLS to protect customers
>
> The e
Unless I'm wrong, with the visibility draft the client side is also unable to
identify who the key material is being transferred to. Only the server-side can
know it, so I think it's a similar case.
Imagine a malicious user is able to subvert the communication between the
server and the middleb
I recognize I may lack context, because I have only seen Steve Fenter's slides,
but apart from it not reaching consensus, the scenario it presents (user
connecting to online banking service) seems to be visibility of connections
from the internet to internal servers.
I think that not even visi
For the monitoring part, I have never felt the need to monitor anything outside
the end points of the connections. If I need to decrypt packets online in order
to troubleshoot it, it’s because my application is currently not providing
enough information in the debug logs. And in order to consoli
> Note that temporarily enabling debug on a live endpoint isn't a big issue,
> everything will continue to operate as before except for the one client that
> requests debug-level alerts, and that knows what it's up for because it
> explicitly asked for it.
And for the malicious user that, knowing
Of course not. I mean an attacker who is specially interested in this server
and knows that someone has requested a debug window on it.
De: Peter Gutmann
Enviado: domingo, 1 de abril de 2018 10:14
Para: Ion Larranaga Azcue; Eric Rescorla
Cc: IETF
Anyway, I don't mean I'm against the idea of the extended errors extensions...
Only that let's not take it lightly. It can be a good debugging tool but also a
risky one.
De: TLS en nombre de Ion Larranaga Azcue
Enviado: domingo, 1 de a
Hi,
My opinion is that if we are going to have extended error codes, it's better to
use numeric ones and not text based errors. Imagine a chinese client trying to
troubleshoot a connection to a server using a TLS stack that reports its errors
in russian. That would be crazy!
I'm not saying t
ginal-
De: Peter Gutmann [mailto:pgut...@cs.auckland.ac.nz]
Enviado el: domingo, 8 de abril de 2018 2:41
Para: Ion Larranaga Azcue
CC: tls@ietf.org
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
Stan Kalisch writes:
>On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue
o do damage control and suggest limiting the amount of
information that can (will) be leaked.
-Mensaje original-
De: Peter Gutmann [mailto:pgut...@cs.auckland.ac.nz]
Enviado el: lunes, 9 de abril de 2018 11:50
Para: Ion Larranaga Azcue
CC: tls@ietf.org
Asunto: Re: [TLS] Genart last cal
I would say it's unfair to expect other people to diagnose the problem by
claiming "that information was all that was available" because you had access
to:
- traffic dumps of the failing handshakes
- traffic dumps of working handshakes
- the possibility to try any number of modifications of the
I'm a newcomer here, so I may be wrong in some aspects (I apologize in advance
for that) but at least I'd like to give my opinion...
I really don't feel confortable with the approach taken in this draft. Most of
the proponents of these kind of "tapping" limit their scope to datacenters, but
I
> I don't understand why this complicated approach is needed. Why can't the
> server provide an OOB
> interface to look up sessions keys, or maybe export them proactively? The
> proposed draft needs a
> protocol like this anyway because SSWrapDH1 keys need to be distributed, and
> periodic k
> IIUC, with the draft-rehired proposal, the client
> can in any case not be told - the TLS protocol
> extensions are mere politeness and the client does
> not get to know what snooper(s) are involved, nor
> can the client influence the snooping keys. Once,
> any infrastructure for this was deploye
> I agree.
>
> My point is that if this draft were accepted, then the
> infrastructure for the above scenario would all be in
> place (the DH value for the snooper and the code to expose
> session information to that snooper) and the above
> scenario would be more likely to happen, more often.
> I
Even if YOUR objective is to passively observe, you have to admit that this
mechanism allows OTHER PEOPLE using it to modify the encrypted data, and we
should always consider the worst-case scenario.
In fact, my opinion a couple of weeks ago was that we had to find some way to
provide visibilit
17 matches
Mail list logo
