Re: [TLS] WG Adoption for TLS Trust Expressions

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

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

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

Re: [TLS] Enforcing Protocol Invariants

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

Re: [TLS] Enforcing Protocol Invariants

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

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

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

Re: [TLS] Security review of TLS1.3 0-RTT

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

Re: [TLS] Security review of TLS1.3 0-RTT

tions/ ). From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Thursday, May 4, 2017 5:37 PM To: Kyle Nekritz <knekr...@fb.com> Cc: Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org Subject: Re: [TLS] Security review of TLS1.3 0-RTT On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <k

Re: [TLS] Security review of TLS1.3 0-RTT

> 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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

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

Re: [TLS] (no subject)

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

Re: [TLS] Deprecating alert levels

+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

Re: [TLS] Deprecating alert levels

s. -Original Message- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Sunday, October 16, 2016 5:53 AM To: Kyle Nekritz <knekr...@fb.com> Cc: tls@ietf.org Subject: Re: [TLS] Deprecating alert levels I'm sympathetic to this, but just to be clear... You are suggesting that

[TLS] Deprecating alert levels

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

Re: [TLS] ALPN with 0-RTT Data

to go away. Kyle From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Wednesday, October 12, 2016 4:03 PM To: David Benjamin <david...@chromium.org> Cc: Kyle Nekritz <knekr...@fb.com>; tls@ietf.org Subject: Re: [TLS] ALPN with 0-RTT Data On Wed, Oct 12, 2016 at 1:01 PM, David Benj

[TLS] ALPN with 0-RTT Data

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)

Re: [TLS] Asking for certificate authentication when doing 0-RTT

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

Re: [TLS] Narrowing the replay window

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

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

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

Re: [TLS] Limiting replay time frame of 0-RTT data

t, in an encrypted block. With that said, though couldn'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 <knekr...@fb.com<mailto:knekr...@fb.

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

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

[TLS] Limiting replay time frame of 0-RTT data

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