Commenting purely on the straw-man proposal:
How would passive tools get to the new message if it is sent before the TLS 1.3
server Finished, given that the handshake is already encrypted by that point?
You could send it as plaintext before client Finished, but that changes the
properties of re
(We have many related discussions currently.. this seemed like the most
appropriate thread for my response)
Enterprises are asking for out-of-band TLS decryption, per use-cases outlined
in draft-fenter-tls-decryption-00 (and others before that). The current
proposal for said out-of-band TLS
f
From: Christian Huitema
Date: Thursday, February 22, 2018 at 1:12 PM
To: R du Toit , "tls@ietf.org"
Subject: Re: Comments on draft-ietf-tls-sni-encryption-01.txt
On 2/21/2018 3:31 PM, R du Toit wrote:
I have analyzed the two mechanisms proposed in the draft, with specific focus
o
I have analyzed the two mechanisms proposed in the draft, with specific focus
on the impact of middleboxes.
Assumptions:
The middlebox is deployed inline, between the client and the fronting server,
and is allowed to intercept TLS sessions. The middlebox is policy-driven, and
uses SNI as
> What implementation are you working on?
Proprietary, closed-source TLS stack.
> Section 5.1 says that, in TLSPlaintext, the legacy_record_version "MUST be
>ignored for all purposes".
Agree. The interop issue was definitely on my side, and I was just using it as
background for my quest
In the process of testing my TLS 1.3 draft-23 implementation against OpenSSL
(openssl.git:50ea9d2b3521467a11559be41dcf05ee05feabd6) I ran into an
interoperability issue: the retry ClientHello record header version is set at
0x0301, while the ServerHello (HRR) and fake CCS records arriving from t
https://github.com/tlswg/tls13-spec/pull/1143
From: Eric Rescorla
Date: Thursday, January 18, 2018 at 1:25 PM
To: R du Toit
Cc: "tls@ietf.org"
Subject: Re: [TLS] ServerHello extensions
Thanks. These are good points. I would welcome a PR.
On Thu, Jan 18, 2018 at 10:2
Issue#1: Section "4.1.3 Server Hello" currently states:
extensions A list of extensions. The ServerHello MUST only include extensions
which are required to establish the cryptographic context. Currently the only
such extensions are “key_share” and “pre_shared_key”. All current TLS 1.3
ServerH
Thank you for the thoughtful responses so far. I have been working in the
middlebox arena for more than 20 years, and I am also concerned about the state
of certain implementations. I would like to think that the TLS stack that my
team and I maintain have no serious security flaws, but vulnera
I want to provide some feedback that might be useful to the TLS WG: Firefox
Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org is triggering
an interesting failure in at least one middlebox.
The middlebox in question supports TLS 1.3, but only drafts 18 through 21. The
FF Nigh
10 matches
Mail list logo
