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 HTTP/1.1
, November 12, 2015 12:43 PM
To: Yoav Nir ; Adam Langley
Cc: Mike Bishop ; tls@ietf.org
Subject: Re: [TLS] Application data during renegotiation handshake
On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir
mailto:ynir.i...@gmail.com>> wrote:
> On 12 Nov 2015, at 3:32 AM, Adam Langley
&
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 to
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
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.
-Orig
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
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 h
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 draft-ietf-tls-exported-authenticator
Does anyone have any comments about the draft, criti
+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 revi
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
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, thi
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. IA
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 a
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
impleme
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 requ
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 ESN
e
A/ records.)
However, 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:
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
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 needs
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
S
ng the actual draft tomorrow
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 requ
p.com]
Sent: Thursday, July 21, 2016 5:57 PM
To: Mike Bishop
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.ietf.org/
ursday, July 21, 2016 6:42 PM
To: Mike Bishop
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 given type?
>
> O
That argument seems like it would apply to all post-handshake authentication,
unless there's something different about that.
-Original Message-
From: Martin Rex [mailto:m...@sap.com]
Sent: Thursday, July 21, 2016 7:08 PM
To: Martin Thomson
Cc: m...@sap.com; Mike Bishop ; tls@iet
implementations that want to omit it.
From: Andrei Popov
Sent: Tuesday, October 11, 2016 11:09 AM
To: Eric Rescorla ; Hannes Tschofenig
; Mike Bishop
Cc: tls@ietf.org
Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
+ Mike who has additional concerns with this.
Cheers
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 point
RFC 9460 says this:
Protocol mapping documents MAY specify additional underscore-prefixed labels to
be prepended. For schemes that specify a port (Section 3.2.3 of [URI]), one
reasonable possibility is to prepend the indicated port number if a non-default
port number is specified. This document
I support publication, but I'm slightly biased since my name is on the doc.
However, I noticed that the repo didn't have the Issue Tracker or Editor's Copy
enabled; I've enabled those, so if anyone has been holding WGLC feedback for
that reason, you can file your issues now. I created issues for
Responses to some of these in-line below. More generally, I think several of
these arise from the question of whether requirements on "publishers" apply
specifically to a tool which is automatically generating these records or
generally to the operating entity causing the records to be created.
This is just clarity, not a technical blocker.
From: Salz, Rich
Sent: Friday, March 21, 2025 8:28 PM
To: Mike Bishop ; The IESG
Cc: draft-ietf-tls-tls12-fro...@ietf.org
; tls-cha...@ietf.org
; tls@ietf.org ; s...@sn3rd.com
Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-tl
Mike Bishop has entered the following ballot position for
draft-ietf-tls-tls12-frozen-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
31 matches
Mail list logo
