The concept does indeed solve an important problem, but also introduces a new
dependency in an environment that uses explicit proxies (mostly enterprise
networks). In that environment this proposal, alongside ECH, introduces DNS
queries at the TLS client endpoint where previously the DNS control
As co-author I am not a proponent of passive TLS inspection - not least because
of the ossification implications. It cannot be labeled as ineffective though
(see further comments below), even if the document strongly hints at not using
passive TLS inspection in a post-TLS-1.2 world.
> On Aug 1
RFC 8446, section 9.3 states:
Note that TLS's protocol requirements and security analysis only
apply to the two connections separately. Safely deploying a TLS
terminator requires additional security considerations which are
beyond the scope of this document.
The context of that paragraph is "A mi
Thank you Andrei.
> The document does not describe alternatives to MITM proxies.
The [SECURITY_IMPACT] paper mentions alternatives, and we could certainly
include a high-level summary of some of those even though our intention was to
document the BCP for TLS proxies where the reader is consider
As co-author I support adoption of the draft and appreciate the feedback.
The authors agreed at the time that the OPSEC WG charter would better match our
intention of documenting the BCP for TLS proxies given that the TLS WG charter
places more of an emphasis on the TLS protocol. Having said th
On Thu, 14 Feb 2019 15:13:11 -0500 David Benjamin
wrote
On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit <mailto:r@nerd.ninja> wrote:
On Thu, 14 Feb 2019 13:00:16 -0500 David Benjamin
<mailto:david...@chromium.org> wrote
On Wed, Feb 13, 201
On Thu, 14 Feb 2019 13:00:16 -0500 David Benjamin
wrote
On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit <mailto:r@nerd.ninja> wrote:
Questions for PR [1]:
* Regarding this text:
The client MUST NOT use the server-provided retry keys until the handshake
completes succes
Questions for PR [1]:
* Regarding this text:
The client MUST NOT use the server-provided retry keys until the handshake
completes successfully. On success, it MUST NOT overwrite the DNS-provided keys
with the retry keys. It MUST use the retry keys at most once and continue
offering DNS-provi
You could use the existing Certificate padding mechanism. Which mechanism?!
The one in this paragraph:
For maximum compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-ent
In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning alert
before a TLS 1.3 (draft 26) ServerHello. Alert level is supposed to be
implicit in TLS 1.3, but in this case it is ambiguous. Should it even be
considered a “TLS 1.3 alert” given that it arrives before the protocol
can break things that depend on end-to-end integrity of the connection.
> On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote:
>
>> If the use of the mechanism is not negotiated on the TLS level then I
> would appreciate it if the “Security Considerations” section of the draft
>
failure indicators.
> On May 8, 2018, at 8:13 PM, Martin Thomson wrote:
>
> On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote:
>
>> I understand that there is not really anything to negotiate per se, but
> would it not be prudent to add a TLS extension to negotiate s
I understand that there is not really anything to negotiate per se, but would
it not be prudent to add a TLS extension to negotiate support for
exported-authenticator in the TLS layer prior to using it in the application
layer?
—Roelof
> On May 7, 2018, at 12:16 PM, Roelof duToit wr
so per S 9.3, non-supporting middleboxes need to strip out the
> extension
>
> -Ekr
>
>
> On Mon, May 7, 2018 at 8:06 AM, Roelof duToit <mailto:r@nerd.ninja>> wrote:
>
> > On May 4, 2018, at 5:48 PM, Benjamin Kaduk > <mailto:bka...@akamai.com>> wrote:
> On May 4, 2018, at 5:48 PM, Benjamin Kaduk wrote:
>
> On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote:
>> How will this (and any mechanism built on top of RFC 5705 exported key
>> material) interoperate with middleboxes? This use of the mechanism is not
How will this (and any mechanism built on top of RFC 5705 exported key
material) interoperate with middleboxes? This use of the mechanism is not
negotiated on the TLS level, so there is no extension for the middlebox to
strip that would warn the endpoints not to use exported authenticators. Ar
16 matches
Mail list logo
