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

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 current

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

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

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

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

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

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 enc

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

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 hav

Re: [TLS] Breaking into TLS to protect customers

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 mo

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

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

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

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 t

Re: [TLS] The case for a single stream of data

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 ret

Re: [TLS] "Encrypted" SNI

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 HT

Re: [TLS] "Encrypted" SNI

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

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

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 wir

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

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, an

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

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, i

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

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 proto

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

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

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

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

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

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 d

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

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

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

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

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

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

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

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