Re: [TLS] Adoption call for TLS Flag - Request mTLS

Ekr, can I ask you to clarify this a little? I fully agree that extensions to TLS which support a particular application-layer protocol should be done in that protocol’s working group unless and until it’s demonstrated that many unrelated applications will need something similar. (At which

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

I don't know that the assumption that it starts as a re-ordering is going to be valid. Certainly we have at least one instance (the erratum you reported, Rory!) where we've found something in a static table that's simply invalid; I'd expect we drop that line in any versioned update, even if we

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

, the encoder could use the entries of which it was aware, but a decoder could only advertise support for the first contiguous portion of the table. From: TLS on behalf of Lucas Pardue Sent: Tuesday, September 26, 2023 9:48 PM To: Martin Thomson Cc: Mike Bishop ; HTTP

Re: [TLS] potential security concern regarding the exchange of client certificates during the TLS handshake process

This concern is also why many implementations of client certificates in TLS 1.2 and earlier would perform a handshake without requesting a client certificate, then immediately begin renegotiation to exchange the client certificate under encryption. TLS 1.3 removes the need to do this.

Re: [TLS] TLS ECH, how much can the hint stick out?

all subsequent packets go to that back-end. From: Eric Rescorla Sent: Thursday, September 10, 2020 3:58 PM To: Mike Bishop Cc: Christopher Patton ; Christian Huitema ; tls@ietf.org Subject: Re: [TLS] TLS ECH, how much can the hint stick out? On Thu, Sep 10, 2020 at 11:52 AM Mike

Re: [TLS] TLS ECH, how much can the hint stick out?

This is primarily an active attack, but not purely so. Clearly the MITM is an active attacker, but there are situations in QUIC (and DTLS, I presume) where a ClientHello gets retransmitted. Depending on server infrastructure, the client might get two different responses. This isn’t limited

Re: [TLS] Clarification on Delegated Credential validation

I would have assumed the second interpretation as the intent, but you’re correct that value doesn’t exist. Perhaps we should say that the credential’s “remaining” time to live is no more than the maximum validity period? And fix the assertion, of course. From: TLS On Behalf Of Kevin Jacobs

Re: [TLS] On the difficulty of technical Mandarin (SM3 related)

The actual requirement in RFC 8126 doesn’t say the public specification needs to be in English, but it does say that “the designated expert will review the public specification.” This suggests that whatever language the authoritative specification might be posted in, the designated expert

Re: [TLS] Two Multi-CDN proposals

;> wrote: On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood mailto:christopherwoo...@gmail.com>> wrote: On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop mailto:mbis...@evequefou.be>> wrote: > > Stephen, there are a couple complicating factors here where I think we all > have varying

Re: [TLS] Two Multi-CDN proposals

ver, the more common deployment scenario for multi-CDN would be a single record (per version, eventually) from each CDN; each client would receive only one. -Original Message- From: Stephen Farrell Sent: Friday, March 1, 2019 3:53 PM To: Mike Bishop ; Eric Rescorla Cc: Subject: Re: [TLS] Two

Re: [TLS] Two Multi-CDN proposals

Stephen, there are a couple complicating factors here where I think we all have varying knowledge gaps. * There are two major ways of pointing to a CDN: Direct A/ records and CNAMEs. The easiest way to handle key update complexities on the part of the CDN(s) is simply to CNAME the

Re: [TLS] Two Multi-CDN proposals

Despite the additional complexity of #137, I think it's probably the better approach (and I would be fine with the simplification, if that makes it more palatable). Particularly when multi-CDN is used, there's a lot of logic involved in generating the "right" A/ record in response to a

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Perhaps a better way to phrase it is that a server which successfully authenticates as the public_name but does not support ESNI has securely disabled ESNI for that origin, subject to the same rules as if it had supplied a new ESNI key (i.e. use for now, but don't persist). Leave as an

[TLS] Multi-CDN and ESNI

As we discussed in Montreal, the ESNI draft doesn't seem to interact well with origins which use multiple unrelated CDNs. While Section 7.2.2 says that the scope of key sharing is between all hosts which can respond to a single IP address, but the DNS lookup method described actually makes it

Re: [TLS] Request to register value in TLS extension registry

Actually, I submitted a request to IANA while this RFC was in process which got sent to the tls-reg-review alias for approval. There was apparently a hiccup, where the alias members did not receive the request from IANA, but did receive my follow-up e-mail asking if anyone had looked at it.

Re: [TLS] integrity only ciphersuites

I tend to think the strongest scenario for integrity-only ciphersuites is in an application where the data being transferred is already encrypted sufficiently. For example, when running IPsec over an IP-HTTPS tunnel, Microsoft used a null cipher on the outer TLS layer. However, as you say,

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

I support adoption, and I'm fine with -diediedie.  -Original Message- From: TLS On Behalf Of Sean Turner Sent: Friday, August 17, 2018 10:33 AM To: tls@ietf.org Subject: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie At the TLS@IETF102 session, there seemed to be

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

+1 – there are certainly kinks to work out, but this is a worthwhile direction. From: TLS On Behalf Of Patrick McManus Sent: Wednesday, July 25, 2018 8:23 AM To: Joseph Salowey Cc: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni I support adoption of this document and I will

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Belatedly, as I’ve been offline for the past week, but I support this draft moving forward. From: Nick Sullivan Sent: Thursday, May 3, 2018 1:16 PM To: Sean Turner Cc: TLS WG Subject: Re: [TLS] WGLC for

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

for the implementations that want to omit it. From: Andrei Popov Sent: Tuesday, October 11, 2016 11:09 AM To: Eric Rescorla <e...@rtfm.com>; Hannes Tschofenig <hannes.tschofe...@gmx.net>; Mike Bishop <michael.bis...@microsoft.com> Cc: tls@ietf.org Subject: RE: [TLS] Making post-handshake

Re: [TLS] HTTP, Certificates, and TLS

ap.com; Mike Bishop <michael.bis...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Martin Thomson wrote: > On 21 July 2016 at 18:41, Martin Rex <m...@sap.com> wrote: >>A server that implements this extension MUST NOT accept the request

Re: [TLS] HTTP, Certificates, and TLS

y, July 21, 2016 6:42 PM To: Mike Bishop <michael.bis...@microsoft.com> Cc: m...@sap.com; tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Mike Bishop wrote: > > I assume you're referring to Section 3, SNI's ServerNameList MUST NOT > contain more than one name of a giv

Re: [TLS] HTTP, Certificates, and TLS

, 2016 5:57 PM To: Mike Bishop <michael.bis...@microsoft.com> Cc: tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Mike Bishop wrote: > > That means we now have a proposal for carrying both client and server > certificates above TLS, found at > https://tools.i

[TLS] HTTP, Certificates, and TLS

w morning in HTTP; I'd be happy to have some TLS folks there to discuss the draft, and I'd like to get a sense from the TLS WG whether there's a preference for us to do this at the application layer or pass additional requirements to post-handshake auth. Thanks! -M

Re: [TLS] Application data during renegotiation handshake

, November 12, 2015 12:43 PM To: Yoav Nir <ynir.i...@gmail.com>; Adam Langley <a...@imperialviolet.org> Cc: Mike Bishop <michael.bis...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] Application data during renegotiation handshake On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir &l

[TLS] Application data during renegotiation handshake

A question for TLS implementation owners: During the discussion of the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http2-client-certs-00, it was pointed out that HTTP/2 breaks a simplification of the HTTP-TLS interface that some implementations may have assumed. Since