Re: [TLS] Breaking into TLS to protect customers

[Ion Larranaga Azcue]

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 
bot was nice enough as to opt-in for visibility, the party responsible for 
providing the IPS with the required information is the server, which in this 
case is under control of the attacker. There is no way the attacker’s server 
will negotiate with the IPS the required keys to decrypt the channel (most 
likely it can’t even communicate with it).

And if you decide to close that connection because of the lack of visibility, 
well… 99% of TLS servers in internet will not negotiate visibility keys with 
your specific IPS, so you could as well close all TLS traffic going outside. 
And you don’t need visibility for this, only a well-configured firewall.

So, maybe I’m wrong, but I think that this specific use case (analysis of 
either malicious or legitimate clients’ traffic going from the enterprise 
network to outside servers) is not covered by the draft under discussion 
because the remote server will never negotiate the encryption keys with the 
IPS. For me, the only way to provide visibility within this case is by actively 
proxying every connection, something that proponents of the need for visibility 
don’t seem to be comfortable with, and which in my opinion does not require 
lowering the TLS protocol security level.

Or maybe I misunderstood the use case altogether…


De: TLS [mailto:tls-boun...@ietf.org] En nombre de Yoav Nir
Enviado el: jueves, 15 de marzo de 2018 5:58
Para: Rich Salz 
CC: tls@ietf.org
Asunto: Re: [TLS] Breaking into TLS to protect customers

Hi, Rich.

You are conflating customers and users. The customer that may be protected by 
breaking TLS in a bank’s server farm is the bank itself. An IPS system with 
visibility into the traffic may detect bots that are there to steal data or 
mine cryptocurrencies or whatever.

If the customers of the bank are protected, it’s a happy side effect 
(collateral benefit?). The object is to protect the system integrity and the 
data.

Yoav


On 15 Mar 2018, at 5:29, Salz, Rich mailto:rs...@akamai.com>> 
wrote:

Some on this list have said that they need to break into TLS in order to 
protect customers.

The thing customers seem to need the most protection is having their personal 
data stolen.  It seems to happen with amazing and disappointing regularity on 
astounding scales.  Some examples include
· retailer Target, presumably subject to PCI-DSS rules
· Anthem health insurance, presumably a regulated industry
· Equifax, a financial-business organization (but apparently not 
regulated)
· Yahoo, a company created on and by and for the Internet (one would 
think they know better)
We could, of course, go on and on and on.

NONE of those organizations are using TLS 1.3.

So what kind of “protect the customer” requires breaking TLS?  And what 
benefits and increased protection will customers see?


___
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

Re: [TLS] Breaking into TLS to protect customers

[Ion Larranaga Azcue]

> -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 example I provided is not about malware, it was about lateral movement
> by threat actors within a network.  The initial compromise that led to access
> within the network may have been through malware or some other
> vulnerability, but I do think monitoring on an internal network (encrypted or
> not, through logs or on the wire) is the use case for attack detection that is
> plausible with the proposed approach.

Ok, now it's clear for me. I don't know why I thought I had seen a couple of 
times these last days people talking about the need of IPS to decrypt traffic 
going from the enterprise to internet, trying to detect exfiltration of data or 
connections to a malware C&C, which is not the scope of the draft, and I 
thought we were starting to veer off-course in the discussion.

As usually happens, I've been looking for those previous messages (not too hard 
I must admit) and I have been unable to find them, so I probably misunderstood 
what someone meant...

My bad!
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

[Ion Larranaga Azcue]

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 middlebox. If this user manages to convince the server that it 
should use its own keys instead of the ones the middlebox owns, the attacker is 
able to happily decrypt all traffic by using a mechanism we have provided him 
with, and nobody would realize it (because the client has no way to know who 
the key material is being shared with)

And yes, if the key material is shared out-of-band we have a similar problem, I 
don't deny it. I think that this comes down to a philosophycal dylemma.. We 
have two different mechanisms that amount to a similar security level:

- key material is shared out-of-band using some additional mechanism, defined 
outside of TLS
- key material is shared in-band using the TLS extension

Both mechanisms seem to provide, in theory, similar security levels. The 
difference is that if TLS extensions handle it, it's TLS the responsible for 
the security downgrade, whereas in the other case... well, we can't prevent 
anyone from doing what they want with their key material so...

I would vote for out-of-band sharing if enterprises need it, delegating this in 
a completely different protocol. TLS should be as clean and as secure as 
possible.


De: TLS  en nombre de Yoav Nir 
Enviado: jueves, 15 de marzo de 2018 23:49
Para: Rich Salz
Cc: tls@ietf.org
Asunto: Re: [TLS] TLS interception technologies that can be used with TLS 1..3

Yeah, as log as we know who we're shipping it to and the user intends for us to 
send it to this entity.

For the debugging case that we were talking about in Prague, sending the keys 
out-of-band should work fine.

For some middlebox that needs to decrypt the traffic online, it needs the keys 
before the first data record goes out. I don't see how we can do that without 
interleaving it with the handshake.



On 16 Mar 2018, at 0:42, Salz, Rich mailto:rs...@akamai.com>> 
wrote:

I think if we ship the keys over some kind of secure socket layer we should be 
okay, right?


From: Yoav Nir mailto:ynir.i...@gmail.com>>
Date: Thursday, March 15, 2018 at 6:41 PM
To: Richard Barnes mailto:r...@ipv.sx>>
Cc: Rich Salz mailto:rs...@akamai.com>>, Hubert Kario 
mailto:hka...@redhat.com>>, 
"tls@ietf.org" mailto:tls@ietf.org>>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

IIUC not quite. There is an API, so the application that uses the library can 
get the keys. The application can then save it to a file, send it to a central 
repository, send it to the government, or whatever else it might want to do.

There is no built-in setting where OpenSSL writes the keys to a file, nor do 
applications such as web servers do this AFAIK.

It should not be difficult to write, but is not provided in off-the-shelf 
software.

Making the library send this in-band in some protocol extension is a far bigger 
endeavor. It's also a dangerous switch to leave lying around.


On 16 Mar 2018, at 0:16, Richard Barnes mailto:r...@ipv.sx>> wrote:

Just to confirm that I understand the scope of the discussion here:

- TLS libraries have facilities to export keys from the library
- Obviously, it's possible to ship these exported keys elsewhere (`tail -f 
$SSLKEYLOGFILE | nc $LOGBOX`)

So all we're really talking about is whether to define a way to do the shipment 
of the exported keys in-band to the TLS session.


On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich 
mailto:rs...@akamai.com>> wrote:
This is what OpenSSL provides:

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback..html


___
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

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Ion Larranaga Azcue]

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 visibility proponents agree between them, as sometimes 
they seem to require "server-to-server" visibility within the data center while 
periodically use cases appear (such as the one you mention) where traffic to be 
decrypted goes from internet to the internal network (or even viceversa). I'm 
starting to understand someone who some months ago said this looked like 
playing "whack-a-mole".

Besides, from what I understand from Steve Fenter's proposal (I may be wrong 
because I have seen only the slides) , they seem to go for non-visible TLS 1.3 
connections from the client to the external layers of the network, and visible 
TLS 1.3 connections within their internal network. This would match the idea of 
"visibility only within the datacenter" but in my opinion it requires a 
finalization of the external tunnel and creation of a new internal one. At that 
point you obviously have the clear text and you could move your monitor tasks 
to that point.

So maybe it's because the presentation is obsolete or because I lack context 
but... no, I don't think those specific slides are a valid example today.


De: TLS  en nombre de Jim Reid 
Enviado: sábado, 24 de marzo de 2018 16:56
Para: Dan Brown
Cc: tls@ietf.org
Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

> On 19 Mar 2018, at 15:18, Dan Brown  wrote:
>
> PS: I never directly worked on enterprise security (usually, I just think 
> about the math of basic crypto primitives), but I don't recall hearing about 
> such a "visibility" feature in the enterprise security work of colleagues 
> (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to 
> establish a connection between smartphones and the enterprise network.

Hearsay anecdote is not evidence. :-)

There are use cases in enterprise networks, notably in banking and finance. 
Some of these were presented to the TLS WG. [See Steve Fenter’s presentation at 
IETF97.] However the WG did not reach consensus on adopting the relevant drafts 
as work items.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Ion Larranaga Azcue]

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 consolidate similar logs 
generating at different servers, many of our customers (including several 
national banks) used our SIEM tool to collect all information generated by 
their applications and query it in a centralized way. For me, TLS connections 
should always be opaque pipes. If I want to look at what’s within, I have to 
look from one end.

Regarding IPS/IDS appliances, maybe it’s the time to change the current idea 
and say that IPS services should not be the “big brother” thet are today. I 
would go for “global” IPS/IDS appliances working on traffic content for 
unencrypted connections and traffic trends for encrypted ones. For protection 
of each server, IPS/IDS agents installed within the machine could monitor and 
defend each specific service in it. As server plugins or if necessary, TLS 
termination at the agent, cleartext analysis and passing it to the server in 
cleartext. Client authentication can still be used in this case. For example, 
using Apache+Tomcat, the AJP protocol has allowed for many years ago the 
passing of TLS client credentials from the TLS terminating frontend (Apache) to 
the backend (Tomcat).

If you still feel that you need TLS visibility, for me the mechanisms already 
in place to export the necessary key material to the out-of-band scanners are 
enough for this. You talk about the need for out-of-band scanners to have the 
key available as soon as they start receiving packets, as they can’t possibly 
cache so many packets for so many connections. In that case you can put the TLS 
handshake on hold until you are sure that the out-of-band scanner has received 
the key material, and only then go on with the handshake.

In fact, I guess (I may be wrong, as I have not gone into it yet) that when 
using the method SSL_CTX_set_keylog_callback included in OpenSSL, handshake 
will not go on until the callback has returned (and if it does continue or the 
callback is performed at the end of the handshake, I think it could be an 
improvement to modify the callback this way). If this callback includes the 
transfer of the material to the out-of-band scanner, then by the time the 
callback ends and the handshake is allowed to continue, any out-of-band scanner 
has been provided with the key material and they can decrypt the TLS data 
without having to queue any packet. If this data cannot be sent to out-of-band 
scanners due to the scanners being down, the server has the option to 
automatically abort the connection or allowing it to continue without the 
visibility (your choice).

Summarizing, I think that there are many ways to overcome the visibility 
problem without having to weaken TLS itself. Probably we won’t be able to find 
a one-size-fits-all solution to magically convert what enterprise have today to 
what is required for TLS 1.3, but I think that for most cases, all that is 
needed is a change of mind and some ideas about how to implement those changes.


De: TLS [mailto:tls-boun...@ietf.org] En nombre de Steve Fenter
Enviado el: lunes, 26 de marzo de 2018 13:49
Para: Tony Arcieri 
CC: tls@ietf.org
Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

MITM as a solution doesn't scale for the needs of the enterprise.  Packet 
decryption and inspection is needed at many locations within the data center: 
at many tiers of an application, within the virtual environment, and within the 
cloud environment, all of which may be TLS encrypted.  Speaking as a 
troubleshooter, a problem can happen anywhere in the enterprise network, and 
there are thousands of locations where I need to be able to take a packet trace 
and decrypt it in order to find a slow or failing transaction.

The biggest problem I see with the key escrow solutions being suggested is that 
decryption is in some cases taking place in real time, even though it's out of 
band. This is being done, for example, for security inspection, for fraud 
monitoring, and for application performance monitoring.  TLS decryption 
appliances are going to be getting packets off of 100 gig links, and when the 
packet arrives the keys have to be there.  At this speed there's not a lot of 
time for queuing packets and waiting for keys. If we are going to use exported 
ephemeral keys, I think placing them in the packet as in draft-rhrd is the only 
scalable way to accomplish this.

In response to unwillingness to change, enterprises are doing things today that 
work and that solve our business problems. The alternative suggestions being 
made, like MITM and endpoint monitoring, don't solve our business problems.

In response to how much time we have, it was recently stated on the list that 
NIST has published a draft 

Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

[Ion Larranaga Azcue]

> 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 the server is currently in debug mode 
and returning extended errors, can more easily perform attacks on it...


De: TLS  en nombre de Peter Gutmann 

Enviado: domingo, 1 de abril de 2018 7:29
Para: Eric Rescorla
Cc: IETF discussion list; General Area Review Team; 
draft-ietf-tls-tls13@ietf.org; Dale R. Worley; 
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of 
draft-ietf-tls-tls13-24]

Eric Rescorla  writes:

>In my experience, there are four major scenarios for diagnosing this kind of
>failure. Under the assumption that you control one end, the other end can be:
>
>1. A live endpoint.
>2. A testing endpoint someone has put up.
>3. An endpoint that someone is actively working on with you.
>4. An endpoint you control (e.g., you're running it on your own machine).
>
>If this is a debug-only feature, then it won't be available in case #1,

I have the feeling the people who have commented on this were talking from
real-world experience, and in the example I gave it was exactly case #1.  This
was a live, large-scale production environment by a major ecommerce
organisation (details fudged somewhat to avoid identifying anyone, but
everyone here would know the name), and the only way to get things working was
to spend several weeks randomly tweaking every conceivable option on the
client until things started working, because the only thing the server would
say was "Handshake failure".  The client-side organisation still has no idea
what made things work, they've narrowed it down by trial and error to about
half a dozen things they had to change, but that's it.

If they'd been able to get the server operators to turn on extended-alert for
even just a single handshake it would have avoided several weeks' effort and a
fix that even now is pure guesswork.

>For the same reason, it's not really that helpful in case #3, because you can
>just ask the person you're working with to read the logs,

Except that these people are EDI companies, not TLS experts.  They have
neither the expertise nor the inclination to help debug TLS issues.  What they
will do is enable debug on the server so the client can sort things out, but
they're not going to devote any effort to sorting out the problem at their
end.

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.

>so this leaves case #2,

Actually it leaves 1, 2, and 3.  4 is kinda pathological, so really the
problem is "all of the cases".

Peter.

___
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

Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

[Ion Larranaga Azcue]

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 discussion list; General Area Review Team; 
draft-ietf-tls-tls13@ietf.org; Dale R. Worley; 
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of 
draft-ietf-tls-tls13-24]

Ion Larranaga Azcue  writes:

>And for the malicious user that, knowing the server is currently in debug
>mode and returning extended errors, can more easily perform attacks on it...

If there's someone on the Internet who can scan every TLS server on the planet
once a minute to see a brief debug window open up, and then perform something
like a million-message-attack using a single debug message, then they're kinda
wasting their abilities in attacking TLS servers...

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

[Ion Larranaga Azcue]

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 abril de 2018 11:55
Para: Peter Gutmann; Eric Rescorla
Cc: General Area Review Team; Dale R. Worley; IETF discussion list; 
draft-ietf-tls-tls13@ietf.org; 
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of 
draft-ietf-tls-tls13-24]

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 discussion list; General Area Review Team; 
draft-ietf-tls-tls13@ietf.org; Dale R. Worley; 
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of 
draft-ietf-tls-tls13-24]

Ion Larranaga Azcue  writes:

>And for the malicious user that, knowing the server is currently in debug
>mode and returning extended errors, can more easily perform attacks on it...

If there's someone on the Internet who can scan every TLS server on the planet
once a minute to see a brief debug window open up, and then perform something
like a million-message-attack using a single debug message, then they're kinda
wasting their abilities in attacking TLS servers...

Peter.


___
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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ion Larranaga Azcue]

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 that forcing English is better. There are many people out there 
who have problems with english as well, and I'm sure that they would rather 
look a numeric code in a table with localized error messages than having to use 
google translate.


That being said...


If in the end a decission is made to have text based error messages, I think 
that the messages should be (at least) UTF-8. If a developer wants to generate 
an error message including information from the certificate (I can't imagine a 
valid scenario but... why not?), there are many places where UTF-8 is allowed. 
Additionally, a server name can also contain non-ASCII characters and so on...



De: TLS  en nombre de Stan Kalisch 

Enviado: viernes, 6 de abril de 2018 16:39
Para: tls@ietf.org
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Hi,

On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote:
The table stakes have increased,

Exactly.

and I don't think it is reasonable any more for any IETF protocol to have "just 
use ASCII" for text messages.  It could be UTF8, or it could be codeset/tagged. 
 Why two developers in, say, Russia need to speak English to debug their TLS 
implementations.

Viktor rightly points out that in this situation the developer is the consumer. 
 As the Internet exponentially expands-often in ways we're not always able to 
posit ahead of time-the base of developers exponentially expands.  The IETF 
shouldn't be sanguine about the possibility that at some point the number of 
those developers who do not speak English will reach a critical mass that is 
able to start eschewing protocols that it finds too mired in US-ASCII.

I would ask anybody who would say it could never happen how sure they are of 
that assertion.


Thanks,
Stan

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ion Larranaga Azcue]

I don't think it's necessary going to that degree of detail. For your specific 
first example, alert the alert "bad_certificate" is enough, or at the most a 
"certificate_chain_length_error". Your second example is, for me, more real, 
because it can be an extended error for a "decode_error" alert. As 
"decode_error" is too broad, we could have a "length_mismatch" extended error. 
But not give the specific values, because once the user knows that there is an 
error with the length of a packet, it can revise length fields in that specific 
packet in order to identify the error. An additional intermediate option is 
allowing specific parameters for each extended error, for instance in this 
example it could be the location within the packet of the offending field. 

Summarizing, including a text error message is going from black to white 
without passing through the greys. The problem I see with it is that it's hard 
for applications to automatically parse it, should it become necessary. I would 
first start trying to define an extended error reporting protocol using only 
numeric codes, and after the first few attempts, if we see that the list is not 
manageable, we could start exploring other options.

My preferences are (in descending order of preference):

- leave it as it is now, no extended error codes
- numeric extended error codes
- numeric extended error codes with specific sub-parameters for each extended 
error code (e.g. location within the packet of offending length field in a 
"length_mismatch" extended error code)
- numeric extended error codes with an arbitrary list of opaque parameters 
each, to be filled by developer (implementations can't rely on the content but 
can show them, on screen, so if you want it can be a text message)
- a single opaque extended error code. It can be numeric, UTF8 string or what 
the developer wants, but in my opinion this should be the last resort. I have 
never liked "let me put whatever I want" solutions


-Mensaje original-
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 wrote:
>>
>> 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.
>
>That was my own gut feeling on the least painful way to go, but I'm 
>open to the possibility that gut feeling was woefully naive.

To see why this won't work, you just need to think one step further: Try 
sitting down and defining the numeric error codes you're proposing.

If it's still not obvious: The reason why we need free-form strings is because 
the numeric codes we already have provide insufficient detail.  To provide the 
required detail, you'd need to define numeric codes for every error condition 
and failed check that every TLS and PKI library (because lots of handshake 
failures are due to problems with certs) could wish to communicate.  To take a 
PKI example, there's "Certificate chain with length %d has a path constraint of 
length %d", which for reasonable values of the two %d leads to, say, around a 
hundred error codes just for that one condition.  Then take every single type 
of error that would need to be communicated and you're into at least 16- bit 
values, or 32- or 64-bit if you take cases like "Packet length of %d indicated 
but only %d bytes were sent".

Even if someone came up with the massive codebook of thousands or tens of 
thousands of error codes, which TLS author would want to spend hours paging 
through them to find the right code for each situation?

Conversely, if you limit the number of error codes to, say, 5,000, how are you 
going to convince TLS library authors to check for and report only those 
errors?  What happens if new error types are defined?

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ion Larranaga Azcue]

I think you don't really get my position in this issue... No, I'm not going to 
start a list of numeric codes because I don't believe in this functionality. 
Not even numeric extended alert codes have any appeal to me, it's just the 
least offending idea.

In my opinion, someone wants this functionality because he doesn't want to ask 
the server administrators to analyze or even send the debug logs in the peer 
side, which already have the information he needs. He is trying to substitute a 
person-to-person interaction he doesn't want to perform for a 
computer-to-computer interaction he sees as more convenient. Maybe without 
realizing he still needs to ask peer administrators to enable this debug 
functionality on a (most likely) production server.

So, I'm totally against this whole idea but if everybody else supports it, I'm 
going to try to 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 call review of draft-ietf-tls-tls13-24

Ion Larranaga Azcue  writes:

>I don't think it's necessary going to that degree of detail. For your 
>specific first example, alert the alert "bad_certificate" is enough

We already have error codes at about that level.  They're not enough to debug 
any problems (I mean, "bad certificate" is only marginally better than the 
canonical Ken Thompson Unix error message in which a giant "?" lights up in 
front of you, "the experienced TLS developer will usually know what's wrong"), 
thus the need for free-form text messages that tell you what the actual problem 
is.

>The problem I see with it is that it's hard for applications to 
>automatically parse it,

Applications don't need to parse it, it's an optional, opt-in 
debugging/diagnostic facility to help developers sort out why a handshake is 
failing, not something that an application is meant to process.

>I would first start trying to define an extended error reporting 
>protocol using only numeric codes

Please, go ahead and do so.  For that we'll probably need to start a new list 
to allow everyone to debate at length which error codes are needed and what 
they should represent.  tls-error-bikeshedd...@ietf.org seems to be a good 
candidate name.

Either that or say it's a UTF-8 string with free-form text, and we'll assume 
developers can somehow manage to figure the rest out themselves, as they have 
for pretty much every other situation in which free-form text error messages 
are used.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Expanded alert codes

[Ion Larranaga Azcue]

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 client hello to go 
from a working handshake to a failing handshake in order to identify the 
offending option or parameter
- as you are going to have to ask the server side to activate extended alerts, 
you can ask them for server logs, as well as traffic dumps of (at least) the 
failed connections on their side (if they receive any, which is additional 
information)

Besides, I also think it's not fair to claim that when someone disagrees, you 
are being "shouted down". From what I remember, both sides expressed their 
opinion, and if you manage to gather consensus your draft will get published. 
So, I think accusing others of shouting you down is an unfortunate phrase on 
your side...

That being said... I encourage you to write your draft and look for consensus 
within the group.

Regards,

   Ion

-Mensaje original-
De: TLS [mailto:tls-boun...@ietf.org] En nombre de Peter Gutmann
Enviado el: lunes, 21 de mayo de 2018 14:09
Para: Eric Rescorla 
CC: Dale R. Worley ;  
Asunto: Re: [TLS] Expanded alert codes

Reviving this discussion, if I write up a draft for this what's going to happen 
to it?  Will it get published, or shouted down?  The reason I'm asking is that 
I've just spent the past three days debugging a TLS issue that's pretty much a 
poster child for why extended alerts are needed, it was something that would 
have been resolved in a single handshake exchange with extended alerts, but 
took three days to sort out without them.  The sequence was as follows:

  Client sends standard client hello.
  Server responds with handshake failed alert.

The same client has been running for years, and connects fine to any number of 
servers, and openssl and some web browsers connect fine to the server.  The 
only message exchanged was the hello, so there's zero security issues in 
providing extended alerts.

Since some people have argued that extended alerts aren't necessary or useful, 
I'll wait awhile for them to diagnose what was wrong using the information 
above, which was all that was available.

Peter.

___
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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ion Larranaga Azcue]

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 agree with others in that it should be treated as if it will be used on the 
internet as a whole (as the specification does not prevent this kind of use, 
and we can't know how users and hosting companies will react to this 
functionality being available).


It's true that with this approach the client has to opt-in but once it has 
opted-in, the client has no control over which third party the encryption keys 
are passed to. Imagine a client opts-in because he knows there is an IPS within 
the network and the company hosting the server asks him to (I know at least one 
of our clients would certainly consider this). But some time later a malicious 
third party manages to coerce the hosting company to provide the keys to them 
instead (or in addition to) the IPS. From the point of view of the client, he 
wouldn't notice anything different (only a change in the key identifier but 
could be due to key renewal)...


I think a way to solve this would be involving the client more in the 
visibility negotiation. For me, the client not only has to opt-in to the 
tapping, but should also have the possibility to unambiguosly identify the 
tapping third-party and accept or reject the connection accordingly. I had some 
naive idea for this but I was unable to accomodate it in the handshake as it is 
currently defined (in fact, I don't think this kind of control for the client 
can be provided without major changes to the handhsake protocol).


I also don't like the way security so greatly depends on SSWrapDH1 (as 
addressed in point 6 of Security Considerations). I expect many administrators 
will create long-lived keys in order to avoid the work to have to redistribute 
them, leaving connections open to attack during months after they take place 
(until SSWrapDH1 key renewal)...


Anyway, I think key life length could be addressed in later drafts, but the 
inability of the client to identify (and possibly reject) the tapping third 
party is a "no go" for me...


   Ion



De: TLS  en nombre de Nick Sullivan 

Enviado: lunes, 9 de octubre de 2017 22:49
Para: Ralph Droms; tls@ietf.org
Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ralph and Russ,

This draft addresses the two main concerns I had with draft-green:
1) Client opt-in
2) On-the wire visibility

There are clearly some details missing from this draft (such as how Ke is used 
as a symmetric key), but generally I think this approach is more explicit and 
therefore less likely to unintentionally impact the broader internet if used in 
the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms 
mailto:rdroms.i...@gmail.com>> wrote:
We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension 
defined in this I-D takes into account what we heard from the discussion 
regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. 
Specifically, it provides an opt-in capability for both the TLS client and 
server and makes it clear on the wire that visibility will be enabled for the 
session.  The new mechanism does not depend on static handshake or session keys.

- Ralph and Russ


___
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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ion Larranaga Azcue]

> 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 key 
> regeneration is needed because it is the only way to implement revocation of 
> access privileges 
> without revealing the existence of other authorized parties.

In my opinion, the proposed draft does not define a protocol because it expects 
that SSWrapDH1 keys will be distributed manually (I may be wrong with this, but 
that's what I understood as the draft does not specify any key exchange 
protocol between server and third-party). That's why I think that SSWrapDH1 
keys will be very long-lived (administrators will hate having to manually 
distribute the new key in an hourly or even daily schedule), jeopardizing 
perfect forward secrecy for a long time.

The problem I see with a "server to third party" OOB look up or export of the 
keys is that the client will not be notified of this export taking place and so 
will lose the chance to reject surveillance...




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ion Larranaga Azcue]

> 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 deployed, I think
> it'd be used without telling clients for sure. (And
> we would be fully complicit in helping that happen,
> if the WG adopted this stuff, because we know that
> such abuses would be inevitable.)

Not really. The draft relies on the server sending a non-encrypted extension 
containing critical information (the session keys encrypted using a shared key 
between server and third party). The third party is expected to intercept this 
non-encrypted extension and decrypt it using Ke in order to obtain the session 
keys. Without this information the third party is unable to fully decrypt the 
TLS connection. 

If the extension is not sent, the client does not realize there is a third 
party, but the third party does not have the session keys either, and the 
server has to provide them in a different way (for instance, using an OOB 
lookup as Florian suggested). In any case, it's not the same scenario as the 
draft proposes (the keys are shared in a different way) and can happen with or 
without this draft being accepted.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ion Larranaga Azcue]

> 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.
> IOW, by standardising draft-rehired, we'd *also* be
> putting in place standard building blocks for an OOB,
> client is never told mechanism.

I don't see it that way... For me, using the capabilities provided by this 
draft in order to get an OOB-only  "no client involved" mechanism is more 
difficult and probably less efficient than creating one from scratch...

That being said... One thing that bothers me from my last emails is that I seem 
to find myself on the draft-defending side of the discussion while I don't 
really like the draft itself due to the concerns I pointed out in my first 
email... I'm not fully against adding monitoring capabilities to the protocol, 
but I would prefer a "no-monitoring-allowed" TLS if the alternative was going 
with an insecure tapping mechanism.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ion Larranaga Azcue]

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 visibility for TLS 1.3, but after reading other people's comments on 
this thread, I think there are lots of solutions to provide visibility of the 
encrypted data within internal networks. And if the transition requires work 
and money... Well, security always does.

I side with the people that think we should close this topic and move on (I am 
even wondering if it was a good idea to send this mail and thus fuel the 
discussion). I'm eager to see a final specification of TLS 1.3 and I'm 
currently frustrated with being unable to see the light at the end of the 
tunnel while we are just going round and round the same discussion...

> -Mensaje original-
> De: TLS [mailto:tls-boun...@ietf.org] En nombre de Ackermann, Michael
> Enviado el: martes, 24 de octubre de 2017 1:31
> Para: Benjamin Kaduk ; Tony Arcieri
> ; Adam Caudill 
> CC: tls@ietf.org
> Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> 
> NO
> The objective is to be passively observe, out of band and not to be a MitM or
> modify/inject text.Just as we all do today.
> 
> -Original Message-
> From: Benjamin Kaduk [mailto:bka...@akamai.com]
> Sent: Monday, October 23, 2017 6:33 PM
> To: Ackermann, Michael ; Tony Arcieri
> ; Adam Caudill 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> 
> On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
> > No one I am aware of is pushing for a MitM capability to address this.
> > In fact it was one of the alternative solutions for which many
> > implementation issues were cited at the Prague meeting and on this
> > list.    But I would like to ask,  what is the solution that your
> > company and others that you reference,  have solved this problem by
> > implementing?
> 
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
> SSWrapDH1 private key has the cryptographic capability to inject traffic and
> modify plaintext for the affected connections?
> 
> -Ben
> 
> 
> The information contained in this communication is highly confidential and is
> intended solely for the use of the individual(s) to whom this communication
> is directed. If you are not the intended recipient, you are hereby notified
> that any viewing, copying, disclosure or distribution of this information is
> prohibited. Please notify the sender, by electronic mail or telephone, of any
> unintended receipt and delete the original message without making any
> copies.
> 
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
> ___
> 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