Since the Certificate message is sent in an encrypted record, the normal record
padding mechanism (section 5.4) can be used, rather than sending the padding as
actual handshake data.
-Original Message-
From: TLS On Behalf Of Christopher Wood
Sent: Tuesday, June 12, 2018 1:41 PM
To:
Su
I think there may be lower overhead ways (that don’t require frequent TLS
library code changes) to prevent ossification of the ServerHello using a
mechanism similar to the cleartext cipher in quic. For example, a client could
offer an “anti-ossification” extension containing an identifier that
key from a previous connection completely avoids that issue
(for example the server sends an encrypted extension with identifier X and key
Y, which the client remembers for future connections).
From: Steven Valdez
Sent: Thursday, June 14, 2018 10:35 AM
To: Kyle Nekritz
Cc: David Benjamin
No.
FWIW, we (at my day job) run TLS 1.3 at large scale for server-to-server RPC
communication, and have seen no appreciable performance overhead from ticket
refresh on resumption.
I also have no objection to Martin's proposal.
Kyle
-Original Message-
From: TLS On Behalf Of Sean Turn
Similar to the earlier discussion on 0.5-RTT data, I'm concerned with the long
term ability to replay captured 0-RTT early data, and the attack vectors that
it opens up. For example, take a GET request for an image to a CDN. This is a
request that seems completely idempotent, and that applicatio
I think that idempotency is a relatively straightforward idea, it seems
reasonable to trust that the application layer will only send 0-RTT data that
is idempotent in terms of server-side state. I also don't think it's that much
different than the current state of TLS. Providing strict replay pr
ouldn't you
also just include the information in the HTTP header for HTTP? Do you think
this is a sufficiently
general issue that it merits a change to TLS.
-Ekr
On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz
mailto:knekr...@fb.com>> wrote:
Similar to the earlier discussion on 0.5-RTT dat
If a client nonce cache is used then the threat is essentially the same as with
ordinary retries.
As far as forward secrecy, yes, the 0-RTT data loses some forward secrecy. I
think this is a reasonable trade off for a lot of use cases. Currently, TLS 1.2
implementations commonly use session tic
I think this will better account for the round trip delay if the elapsed_time
is defined on the client as the time since the request for the session ticket
(in other words, the time since the client hello was sent). That way both the
server computed time and the client reported time will include
On 30 March 2016 at 04:45, Kyle Nekritz wrote:
> I think this will better account for the round trip delay if the elapsed_time
> is defined on the client as the time since the request for the session ticket
> (in other words, the time since the client hello was sent).
Unfortunately,
What is the rationale for restricting a change in certificate? If the server
has a new certificate that the client would accept with a full handshake, what
threat is added by also accepting that certificate with a PSK handshake?
Requiring the certificate to remain the same will make rollout of a
Currently the draft specifies that the ALPN must be "the same" as in the
connection that established the PSK used with 0-RTT, and that the server must
check that the selected ALPN matches what was previously used. I find this
unclear if
1) the client should select and offer one (and only one) ap
go away.
Kyle
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Wednesday, October 12, 2016 4:03 PM
To: David Benjamin
Cc: Kyle Nekritz ; tls@ietf.org
Subject: Re: [TLS] ALPN with 0-RTT Data
On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin
mailto:david...@chromium.org>> wro
After PR #625 all alerts are required to be sent with fatal AlertLevel except
for close_notify, end_of_early_data, and user_canceled. Since those three
alerts all have separate specified behavior, the AlertLevel field is not
serving much purpose, other than providing potential for misuse. We (Fa
ewhat
dangerous.
-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com]
Sent: Sunday, October 16, 2016 5:53 AM
To: Kyle Nekritz
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating alert levels
I'm sympathetic to this, but just to be clear...
You are suggesting that e
I do think this should be allowed if the client is satisfied with the previous
identities presented. We currently allow resumption across domains supported by
our wildcard certificate (I believe this is fairly common practice), and our
clients take advantage of this to improve their resumption r
+1 to both Martin and ekr, I think simplifying these alerts with clearly
defined behavior for each alert description is the best way forward.
Kyle
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Wednesday, October 19, 2016 10:18 PM
To: Eric R
I have a small preference for option 1. I think in a way #2 and #3 require a
special case as well for the PSK binder transcript. Unless we consider the
truncated ClientHello and the rest of the ClientHello separate messages, the
handshake hash will have to move backwards after computation of the
I raised this before in PR #693
(https://www.ietf.org/mail-archive/web/tls/current/msg21600.html).
I'm not sure it makes sense to rename this to legacy while other parts of the
document still refer to it. But I'm definitely in favor of deprecating it.
From: TLS on behalf of Dave Garrett
Sent
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both
> session-cache and strike register styles and the merits of each.
First, a point of clarification, I think two issues have been conflated in this
long thread:
1) Servers rejecting replayed 0-RTT data (using a single
ile-connections/
).
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Thursday, May 4, 2017 5:37 PM
To: Kyle Nekritz
Cc: Colm MacCárthaigh ; tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz
mailto:knekr...@fb.com>> wrote:
> 1. A S
The stateless technique certainly doesn’t solve all issues with replay. Neither
do the other techniques, unless a fairly unrealistic (imo, in most use cases)
retry strategy is used. But the stateless technique is definitely an
improvement over no anti-replay mechanism at all (for instance it red
Timestamps outside the expected window can happen due to variances in RTT,
client clock skew, etc. (we see around .1% of clients outside of a 30s window
for example). Not likely to happen on a given connection, but it certainly
happens enough that you don’t want to abort the connection (rather t
may only be
feasible for large operators, and will harm the TLS ecosystem), and that we
will be adding roadblocks to deployment of more modern trust stores.
There’s still details to work out, but I support adoption of the draft as a
good starting point.
Kyle Nekritz
From: TLS On Behalf Of
I object to 1343 because I don't think it can be implemented without risking
interop problems. There is nothing tying a KeyUpdate response to the KeyUpdate
that requested it, or distinguishing it from an unrelated KeyUpdate. As an
example of how this can cause practical problems, say we have two
ould make the requirement more clear, and avoid enforcement of a
requirement that can’t be strictly followed.
From: David Benjamin
Sent: Thursday, June 6, 2024 5:48 PM
To: Kyle Nekritz
Cc: Sean Turner ; TLS List
Subject: Re: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Regarding
On the surveillance risks, what differentiates trust negotiations from other
existing negotiation mechanisms? Any negotiation mechanism comes with risks
that it will be used to negotiate something problematic. It's not clear to me
why trust negotiation is significantly different in this regard t
> This demonstrates a very common misconception about TCP. I know that some
> implementation choke if the TLS ClientHello spans multiple TCP segments such
> that it requires multiple reads. David Benjamin has written about this
> several times. It's rare though and a bad basis to make decisio
I support adoption. SSLKEYLOG is a useful debugging tool, and there's no good
reason negotiating ECH should break it.
-Original Message-
From: Sean Turner
Sent: Thursday, July 25, 2024 12:16 PM
To: TLS List
Subject: [TLS]Adoption call for SSLKEYLOG Extension file for ECH
At the IETF 1
I support adoption. As our PKIs change, we need mechanisms to allow servers to
move forward, while maintaining widespread compatibility. While currently
available mechanisms (eg cross signing) can help in some circumstances, they
are not sufficient.
Trust negotiation has unique challenges, and
30 matches
Mail list logo
