Re: [TLS] TLS 1.3 - Support for compression to be removed

[Roland Zink]

Browsers are not a concern as they already have their own comp/decomp 
codes. HTTP/1 can compress content (Content-encoding and 
transfer-encoding) and HTTP2 has additional header compression.


Regards,
Roland


Am 02.10.2015 um 15:08 schrieb takamichi saito:

Do we know how many protocols currently suffer from CRIME?


Maybe a best practice could be suggested by UTA for the implementation of TLS 
in software, to disable compression if vulnerable.  And for the others, to 
implement a way to enable/disable compression in case one day a vulnerability 
is found.

I agree.

Again,

1) We know CRIME threat, but it can not be risk for everyone.
e.g., CVSS v2 Base Score: 2.6 (LOW)

2) If we need to have comp/decomp in an application layer,
  clients such like browser need their own comp/decomp codes.

3) If there is no comp in tls1.3, some people may continue to use tls1.2.
Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?

That's why we explore the way to keep compression in TLSv1.3.
How about making an option only in server-side?
The spec has the compression but default is off, and also provides the 
suggestion.



--
Julien ÉLIE

« La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »

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


;; takamixhi saito
c2xhYWlidHNvcw

___
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] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Roland Zink]

Am 21.10.2015 um 20:22 schrieb Hanno Böck:

Not sure if I'm getting anything wrong, but doesn't this open a huge
security hole?

Yes I think so. Mitm may redirect you.


Scenario right now is that if I want to be secure on a webpage I type
in its HTTPS URL (either directly or through a bookmark) and can be
pretty much sure that as long as I don't click on external links that
I'll stay on that webpage.
No the server may redirect you and even worse the parts may be retrieved 
from dozens of places and you have no clue from where. Common practice 
is that your privacy is sold to third parties through ads, analytics, 
like or pin buttons. This is not what I would expect from a secure site.

Basically this proposal would allow a man-in-the-middle to send
me to another webpage each time I click on a (supposedly https
protected) link. Given that there are many browsers these days
(mobile) that hide the URL bar thats even more severe.

This severely changes the security expectations one can have from a
browser.

Regards,
Roland



___
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] Encrypting record headers: practical for TLS 1.3 after all?

[Roland Zink]

Am 28.11.2015 um 13:05 schrieb Henrick Hellström:

On 2015-11-28 12:30, Kriss Andsten wrote:
On 27 Nov 2015, at 17:21, Henrick Hellström  
wrote:


How, exactly, would this be significantly harder? The adversary will 
still be able to tell when, and how much, TCP/IP data is sent 
between the peers. If there happens to be a revealing TLS record 
boundary in the middle of a TCP/IP packet, it would seem to me there 
is an implementation problem rather than a problem with the abstract 
protocol.


This is actually quite common. Even when it does align with packet 
boundaries, it is providing known information rather than inferred 
information ("here's a length X blob, then a length Y blob" vs 
"Here's a bunch of packets whose lengths minus TLS headers amount to 
to X+Y").


Maybe I have missed something, but this seems awfully implementation 
dependent to me. Let's take a more specific example:


Suppose a web server is serving a request for a web page, which 
typically means that the client firstly sends a single HTTP request 
for the HTML page, and then multiple requests for the css, images, etc 
in a row.


Most times, the latter row of requests could easily be encoded in a 
single TLS fragment. This means that the server will become aware of 
all of the requests at the same time, and might encode all of the HTTP 
responses before beginning to encode the TLS fragments.
Even if it could be encoded in a single TLS fragment a simple minded 
browser may encode it one by one. Also there are many more use cases 
where such optimization may not work. Can you provide data what browsers 
are actually doing for HTTP/1.1 and HTTP2?


Carefully implemented, such a solution would not necessarily require 
significantly more resources to handle pipe-lining, compared to an 
alternative solution that would serve, encode and send the responses 
on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP 
queue.


I think it is more complicated so it will use more resources. You have 
to weight what is more important, the additional "security" or the 
"overhead". Anyway I thought the decision was to hide the record length.


Regards,
Roland

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Roland Zink]

Am 28.11.2015 um 17:56 schrieb Henrick Hellström:
AFAIK, HTTP 1.1 browsers typically don't send a new request over an 
open connection, before it has received the response to the previous 
request. If that is the case, it is trivial to get the message lengths 
from the traffic, with or without encrypted TLS record headers. IOW 
you gain nothing by encrypting the length fields.


I think this is what browsers do by default. For HTTP2 this should be 
different.


Regards,
Roland

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

Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11

[Roland Zink]

TCP keep alives are handled by the TCP stack and not given to TLS or as 
Watson said invisible to TLS.


Roland

Am 04.01.2016 um 16:59 schrieb nalini.elk...@insidethestack.com:


On Mon, Jan 4, 2016 at 7:45 AM,   wrote:

Hello All,

Please excuse if this topic has been previously discussed.  I have a question 
about TCP Keep Alives.

Section 5 of draft-ietf-tls-tls13-11 reads:

"Three protocols that use the TLS Record Protocol are described in this document: 
the TLS Handshake Protocol, the Alert Protocol, and the application data protocol."

Then continues with:

"Implementations MUST NOT send record types not defined in this document unless 
negotiated by some extension.  If a TLS implementation receives an unexpected record 
type, it MUST send an
"unexpected_message" alert."

In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS 
Heartbeat).   I take it that this will not work going forth?

TCP Keep Alive is invisible to the TLS connection.

I see. Then, is it that PACKETS without the TLS record protocol may be sent on 
the TLS connection, but IF the TLS Record protocol IS used, then the record 
types must be one of those described?

Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to 
TLS?




  Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

___
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

[Roland Zink]

Am 15.03.2018 um 17:58 schrieb Carl Mehner:



On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty 
> wrote:

> I think what Yoav is referring to by detecting BOTS within the
> network, is really so called advance persistent threat (APT) actors
> that are moving around the internal network leveraging existing access
> rights of compromised accounts and privilege escalation
> vulnerabilities.  These might be detectable with 'visibility'.
> Patterns and behavior might be used to detect the APT use case whether
> or not encryption protects the stream, but it is more difficult.

Yes, they might, however, the best place for malware detection is on 
the edge (which is out of scope for "in the Datacenter" type 
connections) and the endpoint, where an agent is able to run that does 
not need to 'break in' to the TLS session. Yes, the Fenter draft talks 
about how malware endpoints can be anywhere in the network, and that 
they can delete logs as a reason to require out of band network 
decryption. However, if "breaking TLS" becomes an effective malware 
mitigation means, more malware makers may move to using app-level 
encryption (as some already have). Therefore, the conclusion we can 
draw is that malware is not a reasonable reason requiring this 
enhanced "visibility".


I don't think you can make this conclusion when the fact that app-level 
encryption is used can be detected and blocked. However there might be 
ways to hide like steganography.




-carl


___
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)

[Roland Zink]

Am 04.04.2018 um 14:43 schrieb Hubert Kario:

On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote:

Hi Martin


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex
Sent: Thursday, March 29, 2018 4:47 AM
To: Steve Fenter 
Cc: tls@ietf.org
Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do
it)>
Steve Fenter  wrote:

To clarify for anyone who has confusion on the enterprise TLS
visibility use case, I think enterprises need to be able to do
out-of-band decryption anywhere in the network that they own.

This is argument is so lame.

In Germany, monitoring communications between individuals or between
individuals and legal entities, including communications over corporate
networks, was made a serious crime in 2004 (TKG 2004) with a penalty of up
to 5 years in prison for listening into such communication.

The world didn't end.  Really, consider it proven that there is no need.

Could monitoring could be legally done if user provided his consent at the
time of login into enterprise managed terminal?
I guess that's the case in enterprise managed networks.

No, even then the employer needs to establish a concrete case for inspection
of the communications of an employee.
Employer also must not continue inspection of an email as soon as it has
noticed that it is part of a private message.

https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-3846b1c7536d

and this is true, to a large degree, for the whole of EU:
https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by-employer-had-privacy-breached-court-rules

 From the ECHR ruling:
"An employer[...] cannot reduce private social life in the workplace to zero.
Respect for private life and for the privacy of correspondence continues to
exist, even if these may be restricted in so far as necessary."


This is true, but at the same time the employer is required in many 
countries including Germany to archive many emails and other relevant 
messages. See for example https://en.wikipedia.org/wiki/Email_archiving 
or https://www.intradyn.com/email-retention-laws/. This is often in 
conflict with the above mentioned laws, for an example see 
https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emissions-documents-investigations.



I don't think breaking TLS is the way to fulfill such requirements but I 
also think TLS connection to a company shouldn't end up at a third party 
providing hosting or CDN services.



Regards,
Roland






There may be _desires_.  For me, those desires are no less unethical as
data collections by apple, camebridge analytica, facebook, google,
microsoft, whathaveyou...

 and fortunately, for corporations in germany, such data gathering is
not just unethical, but truely criminal by law.


-Martin

___
TLS mailing list
TLS@ietf.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cvakul.garg%40n
xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9
2cd99c5c301635%7C0%7C0%7C636578758559728633&sdata=sa3hcM4C94
%2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D&reserved=0

___
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

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Roland Zink]

This is of cause true. The MTA will not be arrested the question is if 
somebody will arrest the administrator or the owner. This will become 
part of the "push" the right people.



Regards,

Roland


Am 26.04.2019 um 17:24 schrieb Salz, Rich:


If they haven’t already moved off TLS 1 then maybe this document will 
give the right people a push to do so.


Nobody is going to arrest an MTA for non compliance.


___
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] The case for a single stream of data

[Roland Zink]

Am 09.05.2017 um 18:41 schrieb Salz, Rich:

The second problem is that middle-boxes can break any signaling. For example a 
CDN or TLS accelerator may enable 0-RTT towards the back-end origin without 
enabling it to the original client. In this model, the client has *no* way to 
reason about retries or replay.
A CDN is not a middlebox.  As far as the client is concerned a CDN *is* the 
origin.  The agreement in-place between the CDN and the origin is out of scope 
here.  A TLS accelerator, which is a tool to help an origin with its *local* 
performance, or other lower-layer (in the L3 L5 etc sense) assist is within 
scope.  Does that make sense?


Depends on how you look on this. For TLS the CDN is the origin. For an 
end user the CDN is often a third party which means some unknown 
entities get access to potential private data. When this is on another 
country this may include foreign official entities in addition to the 
3rd party company itself. Really bad is when the user is not informed at 
all, e.g. the page URL doesn't show the CDN (or ad or tracking) company. 
For a mass surveillance just monitor a few tracking, advertising or CDN 
companies and you will get most of the URLs (refer header) and more from 
most users without breaking the TLS security. So why do TLS at all?



That's really very broken and a serious violation of the transport layer 
contract.

Only if you believe CDN is a middlebox.  The transport layer contract is 
overridden by legal contracts or EULA :)

/r$

I would prefer if TLS wouldn't allow 3rd parties without user notification.

Roland

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

Re: [TLS] "Encrypted" SNI

[Roland Zink]

The SNI extension is optional, so you don't have to send the literal 
value. Indeed quite some number of apps do not send it. Browsers 
currently can't know if the SNI is required by the origin servers and 
usually send this, but there could be some signal to not send it. One 
example could be a HTTP header to tell the browser that SNI should be 
send and if it isn't present then no SNI is send. Unfortunately this 
would break current sites but still it can be done the other way around 
e.g. send a header to not send SNI.


Regards,

Roland


Am 10.05.2017 um 19:28 schrieb Hubert Kario:

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make
sure that the client and server agree on the host that the client wants to
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
the salt and the resulting hash, making the server calculate the same hash
with each of the virtual host names it supports and comparing with the client
provided value?

(apologies if that was already proposed and rejected)


___
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] "Encrypted" SNI

[Roland Zink]

Not necessarily as you may for example use the path part of a URL to 
distinguish between services.



Roland




Am 10.05.2017 um 23:50 schrieb Christian Huitema:


On 5/10/2017 2:40 PM, Roland Zink wrote:

The SNI extension is optional, so you don't have to send the literal
value. Indeed quite some number of apps do not send it. Browsers
currently can't know if the SNI is required by the origin servers and
usually send this, but there could be some signal to not send it. One
example could be a HTTP header to tell the browser that SNI should be
send and if it isn't present then no SNI is send. Unfortunately this
would break current sites but still it can be done the other way
around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

Nice requirements. Will those be applied to all protocols around TLS? 
For example HTML/HTTP/QUIC tend to send data to third parties through 
additional connections and the HTTP referer header tells all those 3rd 
parties the URL used. This is a breach of the users privacy. For 
surveillance no wiretapping is necessary. A secret service just needs to 
infiltrate a few big companies and will get a pretty good overview who 
browse what. The user didn't explicitly opt-in into this although you 
may argue the client software (browser) does. A third party can't tell 
if this feature is enabled or not by observing the stream. So should the 
usage of HTTP/HTTP2/QUIC over (D)TLS in the current form be forbidden? 
The referer header not allowed when TLS is used?


As a server (and client) can always silently forward the unencrypted 
data neither 1) nor 2) can be enforced so I guess those are only should 
requirements.


Roland


Am 08.07.2017 um 23:16 schrieb Nick Sullivan:
Putting questions of whether or not this belongs as a working group 
document, I think there are some necessary requirements for 
intra-datacenter passive decryption schemes that are not met by this 
draft.


Specifically, any passive decryption scheme should the following two 
properties:

1) Both server and client must explicitly opt-in
2) A third party should be able to tell whether or not this feature is 
enabled by observing the stream


These two requirements protect services on the wider Internet from 
being accidentally (or surreptitiously forced to be) subject to 
unauthorized decryption. The static DH proposal satisfies neither of 
the above requirements.


What you likely want is something similar to TLS 1.2 session tickets 
with centrally managed session ticket keys. The client would advertise 
support for "passive session decryption" in an extension and the 
server would return an unencrypted extension containing the session 
keys encrypted by a server "passive decryption key". The passive 
decryption key would be managed in the same way as the static DH key 
in this draft: rotated frequently and synchronized centrally.


A TLS 1.2 session ticket-like scheme provides the same semantics as 
this static DH but provides more safeguards against accidental use 
outside the datacenter. Both client and server need to opt in, it's 
visible from the network, and limits the data visible to the 
inspection service to the session (rather than exposing the master 
secret which can be used to compute exporters and other things outside 
of the scope of session inspection). Furthermore, in the session 
ticket-like scheme, a */public key /*could be used to encrypt the 
session keys, removing the need for a secure distribution scheme for 
the endpoints. The passive decryption private key could me managed in 
a secure location and only the public key distributed to the endpoints.


Session ticket-like scheme advantages vs this static DH proposal:
1) Mandatory client opt-in
2) Passive indication that scheme is being used
3) Decryption service only gets session keys, not master secret
4) No need for private distribution system for static keys to endpoints

In summary, even if this was to be considered as a working group 
document, I think this is the wrong solution to problem.


Nick

On Fri, Jul 7, 2017 at 8:03 AM Matthew Green > wrote:


The need for enterprise datacenters to access TLS 1.3 plaintext
for security and operational requirements has been under
discussion since shortly before the Seoul IETF meeting. This draft
provides current thinking about the way to facilitate plain text
access based on the use of static (EC)DH keys on the servers.
These keys have a lifetime; they get replaced on a regular
schedule. A key manager in the datacenter generates and
distributes these keys.  The Asymmetric Key Package [RFC5958]
format is used to transfer and load the keys wherever they are
authorized for use.

We have asked for a few minutes to talk about this draft in the
TLS WG session at the upcoming Prague IETF. Please take a look so
we can have a productive discussion.  Of course, we're eager to
start that discussion on the mail list in advance of the meeting.

The draft can be found here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, 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


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

Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

see inline

Roland


Am 15.07.2017 um 03:40 schrieb Watson Ladd:

On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins  wrote:

On 15 Jul 2017, at 1:01, Melinda Shore wrote:


It might make sense to kick it over to ops for a discussion with people whose 
meat and potatoes is monitoring, management, and
measurement.


As someone who is ops-focused, I think this is an excellent suggestion!

There have been several assertions posted to the list recently regarding 
various aspects of security and their intersection with encryption.  It may be 
useful to take a moment and clarify a few of them.

With regards to DDoS mitigation as it relates to encrypted attack traffic, only 
a subset of attacks in a subset of situations can actually be adequately 
mitigated without full visibility into (and often the ability to interact with) 
the traffic within the cryptostream.  There are various ways to approach this 
issue, including full session termination and 'transparent' 
detection/classification, the latter of which isn't of course feasible in a PFS 
scenario.  Each of these general approaches has its advantages and drawbacks.


DDoS mitigation can be done at endpoints, and indeed has to be given
that other tools do not know which endpoints need to be rate-limited
or are expensive.  A lot of distinct things are being crammed together
into DDoS, and the fact is endpoints can deal with application layer
attacks via rate-limits, CAPTCHAs, and other techniques, while
not-application layer attacks don't require visibility to defeat. What
can a middlebox do that an endpoint cannot? Globbing a bunch of
distinct things together is not helping the debate.
One thing which can be done is identifying the sources and notifying the 
owner of the devices so they can be cleaned.



In many scenarios, one form or another of network-based visibility into 
encrypted traffic streams within the span of administrative control of a single 
organization is legitimate, vital and necessary.  It is not 'wiretapping', any 
more than tools such as tcpdump or telemetry formats such as IPFIX and PSAMP 
can be categorized as 'wiretapping'.  The fact is, the availability, 
confidentiality, and integrity of systems, applications, and networks that 
everyone on this list relies upon is highly dependent upon the ability of 
organizations to have visibility into encrypted traffic streams within their 
own networks, for purposes of security as well as testing and troubleshooting.


How this can be accomplished is a matter for further discussion.  But it's 
important that everyone focused on this topic understands that it is simply not 
possible to successfully defend against many forms of DDoS attacks nor to 
detect and classify hostile network traffic in the context of encrypted 
communications without visibility into the traffic in question, via some 
mechanism.  The same goes for troubleshooting complex problems.

Which DDoS attacks specifically? And if the traffic isn't hitting
endpoints, does it matter?

Yes, DDoS cause damage to dumb networks in between as well.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

A cache may be hired by a user, origin or even a network operator to act 
as a "front" to the origin. Is it not a middlebox because of this? It is 
a question of definition if a CDN is in the middle or the endpoint :)


Roland



Am 15.07.2017 um 21:12 schrieb Salz, Rich:

On the public internet, it's increasingly common for traffic to be MITMd in the 
form of a CDN.

A CDN is not a middlebox, it is not a MITM.  It is a site that the origin has hired to 
act as a "front" to it.


___
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] draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

TLS is a two endpoint protocol. It looks like many of the use cases 
describe problems with more than two endpoints but are using TLS because 
it is commonly available. So should TLS be extended to be an n-party 
protocol (or is this always considered wiretapping?) or should be there 
another protocol or something else?



Regards,

Roland



Am 15.07.2017 um 19:34 schrieb Colm MacCárthaigh:



On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor 
mailto:d...@fifthhorseman.net>> wrote:


 * This proposed TLS variant is *never* acceptable for use on the
public
   Internet.  At most it's acceptable only between two endpoints
within
   a datacenter under a single zone of administrative control.


 * Forward secrecy is in general a valuable property for encrypted
   communications in transit.


If there's anyone on the list who disagrees with the above two
statements, please speak up!


I agree with the second statement, but I don't really follow the logic 
of the first. On the public internet, it's increasingly common for 
traffic to be MITMd in the form of a CDN. Many commenters here have 
also responded "Just use proxies". I don't get how that's better.


A proxy sees all of the plaintext, not just selected amounts. All of 
the same coercion and compromise risks apply to a proxy too, but since 
it undetectably sees everything,  that would seem objectively worse 
from a security/privacy risk POV.
Or put another way: if these organizations need to occasionally 
inspect plaintext, would I prefer that it's the kind of system where 
they have to go pull a key from a store, and decrypt specific 
ciphertexts on demand offline, or do I want them recording plaintext 
*all* of the time inline? It seems utterly bizarre that we would 
collectively favor the latter. We end up recommending the kinds of 
systems that are an attacker's dream.


Here's what I'd prefer:

 * Don't allow static DH. In fact, forbid it, and recommend that 
clients check for changing DH params.
 * For the pcap-folks, define an extension that exports the session 
key or PMS, encrypted under another key. Make this part of the 
post-handshake transcript.
 * pcap-folks can do what they want, but clients will know and can 
issue security warnings if they desire. Forbiding static DH enforces 
this mechanism, and we can collectively land in a better place than we 
are today.


--
Colm


___
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] draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

I think reverse proxies are middleboxes regardless if they have official 
origin TLS certificates. From the TLS viewpoint they may be the endpoint 
although from the HTTP viewpoint they are not.



Roland



Am 15.07.2017 um 22:23 schrieb Salz, Rich:

A cache may be hired by a user, origin or even a network operator to act as a
"front" to the origin. Is it not a middlebox because of this? It is a question 
of
definition if a CDN is in the middle or the endpoint :)

Yes.  And I am saying that the definition doesn't include a CDN as a 
middlepoint.

Do user-provided reverse proxies have official TLS certificates with a SAN 
field claiming to be the origin?


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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

RFC 3234 "Middleboxes: Taxonomy and Issues" says:

1.1. Terminology

   The phrase "middlebox" was coined by Lixia Zhang as a graphic
   description of a recent phenomenon in the Internet.  A middlebox is
   defined as any intermediary device performing functions other than
   the normal, standard functions of an IP router on the datagram path
   between a source host and destination host.

Even a load balancer may considered "middlebox", see section 2.8 of RFC 
3234.



Anyway it just depends on what you call middlebox and doesn't matter 
much regarding draft-green-tls-static-dh-in-tls13-01.



Roland



Am 15.07.2017 um 22:47 schrieb Salz, Rich:

I think reverse proxies are middleboxes regardless if they have official origin
TLS certificates. From the TLS viewpoint they may be the endpoint although
from the HTTP viewpoint they are not.

This is wrong.

 From the HTTP viewpoint  -- of the origin! -- they are not middleboxes., not 
intermediaries.

It is no different from a load balancer sending you to a different data center.


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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

Am 15.07.2017 um 23:14 schrieb Salz, Rich:

The terminology in RFC 3234 has evolved; language has a way of doing that.


Anyway it just depends on what you call middlebox and doesn't matter
much regarding draft-green-tls-static-dh-in-tls13-01.

I believe it does.  Words matter.

So what is the definition of "middlebox"?

Roland

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

Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13-01

[Roland Zink]

Am 16.07.2017 um 00:07 schrieb Watson Ladd:



On Jul 15, 2017 12:33 PM, "Roland Zink" <mailto:rol...@zinks.de>> wrote:


see inline

Roland


Am 15.07.2017 um 03:40 schrieb Watson Ladd:

On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins
mailto:rdobb...@arbor.net>> wrote:

On 15 Jul 2017, at 1:01, Melinda Shore wrote:

It might make sense to kick it over to ops for a
discussion with people whose meat and potatoes is
monitoring, management, and
measurement.


As someone who is ops-focused, I think this is an
excellent suggestion!

There have been several assertions posted to the list
recently regarding various aspects of security and their
intersection with encryption.  It may be useful to take a
moment and clarify a few of them.

With regards to DDoS mitigation as it relates to encrypted
attack traffic, only a subset of attacks in a subset of
situations can actually be adequately mitigated without
full visibility into (and often the ability to interact
with) the traffic within the cryptostream.  There are
various ways to approach this issue, including full
session termination and 'transparent'
detection/classification, the latter of which isn't of
course feasible in a PFS scenario.  Each of these general
approaches has its advantages and drawbacks.


DDoS mitigation can be done at endpoints, and indeed has to be
given
that other tools do not know which endpoints need to be
rate-limited
or are expensive.  A lot of distinct things are being crammed
together
into DDoS, and the fact is endpoints can deal with application
layer
attacks via rate-limits, CAPTCHAs, and other techniques, while
not-application layer attacks don't require visibility to
defeat. What
can a middlebox do that an endpoint cannot? Globbing a bunch of
distinct things together is not helping the debate.

One thing which can be done is identifying the sources and
notifying the owner of the devices so they can be cleaned.


How does an endpoint not know the source?


An endpoint has information about the source IP address. It may not have 
an IP adress before NAT, email adress, postal adress or information 
about building / desk number. A middle box having more exact information 
about the source may notify the source owners which often are victims 
themselves.





In many scenarios, one form or another of network-based
visibility into encrypted traffic streams within the span
of administrative control of a single organization is
legitimate, vital and necessary.  It is not 'wiretapping',
any more than tools such as tcpdump or telemetry formats
such as IPFIX and PSAMP can be categorized as
'wiretapping'.  The fact is, the availability,
confidentiality, and integrity of systems, applications,
and networks that everyone on this list relies upon is
highly dependent upon the ability of organizations to have
visibility into encrypted traffic streams within their own
networks, for purposes of security as well as testing and
troubleshooting.


How this can be accomplished is a matter for further
discussion.  But it's important that everyone focused on
this topic understands that it is simply not possible to
successfully defend against many forms of DDoS attacks nor
to detect and classify hostile network traffic in the
context of encrypted communications without visibility
into the traffic in question, via some mechanism.  The
same goes for troubleshooting complex problems.

Which DDoS attacks specifically? And if the traffic isn't hitting
endpoints, does it matter?

Yes, DDoS cause damage to dumb networks in between as well.


I'm not talking DDoS. I'm talking attack traffic. You need to talk 
about specifics you cannot solve other ways. DDOS isn't specific enough.
I was not talking about how it could be detected or prevented only that 
it matters before it is hitting the endpoint and if there is a way to 
avoid it then it should be avoided.





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




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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Roland Zink]

Am 19.07.2017 um 15:51 schrieb Kyle Rose:
On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon > wrote:


This is exactly right.   We have a /real/ problem here.   We
should /really/ solve it. We should do the math.   :)


Is there appetite to do this work? If we restrict this to two paths, 
one of which is spending years designing and implementing a new 
multi-party security protocol, the other of which is silently and 
undetectably (at least on private networks) modifying the standardized 
protocol for which lots of well-tested code already exists... my money 
is on the latter happening.


There is a good chance that this "cheaper" solution is what will happen. 
However the multi-party protocol may be a safer and better approach and 
may even forced in by some regulators when it exists as an implemented 
alternative.


In every decision we make with respect to the static DH approach, we 
have to keep in mind that this change can be implemented unilaterally, 
i.e., without any modifications for interop. Consequently, I think the 
work we really need to do is to design and implement a FS-breakage 
detector so we can at least tell when this is happening on the public 
internet. Beyond that, the best we can really do is ask implementors 
to be polite and intentionally make their implementations not 
interoperate silently with TLS 1.3.


Kyle



___
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] datacenter TLS decryption as a three-party protocol

[Roland Zink]

Am 19.07.2017 um 22:32 schrieb Martin Rex:

Martin Rex wrote:

There were a few issues with F5 loadbalancers (that were just forwarding
traffic, _not_ acting as reverse proxy) related to a borked F5 option called
"FastL4forward", which occasionally caused the F5 box to truncate TCP streams
(the box received&ACKed 5 MByte of TCP data towards the TLS Server, but
forwarded only 74 KBytes to the client before closing the connection with
a TCP FIN towards the TLS client.

And once I saw another strange TCP-level data corruption caused by
some Riverbed WAN accellerator.

I forgot to mention how I analyzed the breakage created by the middleboxes:

network capture (tcpdump) with a IP-address capture filter for a dedicated
client machine was *perfectly* sufficient to determine the TCP-level breakage.

For the F5 cockup, we used a concurrent tcpdump capture on the box in both
directions, again with IP-address capture filter, in order to prove to the
vendor that his box is corrupting/truncating the TCP stream between
TLS client and TLS server.

In many companies the app is from one vendor and the loadbalancer from 
another one. Both vendors are telling you the other is causing the 
problem. Then you will have some fun to turn on undocumented app level 
tracing. However the proposed solution will have the same problem when 
the app doesn't support it.


One question to the company proponents, would you allow the end / home 
users the same capabilities? E.g. some equipment at home/cellular  is 
phoning back to the vendor. The owner of the equipment can't see what is 
transferred and need to trust the vendor, so should end users get the 
keys? It can be a similar problem, e.g. the app doesn't work as expected 
and the vendor says this must be the home / cellular network. How to 
proof that it is the app fault and not the home network?


Regards,
Roland

P.S. Be careful as I think preparing for wiretapping and having tools 
for it may already bring you behind bars in Germany, although I think 
this law wasn't used so far.




-Martin

___
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

[Roland Zink]

It could but RFC 7469 section 2.6 
(https://tools.ietf.org/html/rfc7469#section-2.6) says:



"  It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform)."


and most browsers seem to follow this mitm exception.

Regards,
Roland


Am 25.10.2017 um 18:06 schrieb Salz, Rich:

since those other means would be easier and more effective. You

 have done nothing to suggest otherwise.
   
Public-key pinning and CT seem like they would prevent those other mechanisms.  No?


___
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