Re: [TLS] Idempotency and the application developer

On 05/05/2017 12:04 AM, Nico Williams wrote: > On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote: >> On 05/04/2017 06:35 PM, Watson Ladd wrote: >>> If you are willing to buffer 0-RTT until completion before going to >>> the thing that makes the response, you can handle this problem

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

On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk wrote: > Trying to consolidate various things into a single mail... > > On 05/04/2017 04:37 PM, Eric Rescorla wrote: > > In the PR I just posted, I spent most of my time describing the > mechanisms and used a SHOULD-level

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

Trying to consolidate various things into a single mail... On 05/04/2017 04:37 PM, Eric Rescorla wrote: > In the PR I just posted, I spent most of my time describing the > mechanisms and used a SHOULD-level requirement to do one of the > mechanisms. > I think there's a bunch of room to wordsmith

Re: [TLS] Idempotency and the application developer

On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote: > On 05/04/2017 06:35 PM, Watson Ladd wrote: > > If you are willing to buffer 0-RTT until completion before going to > > the thing that makes the response, you can handle this problem for the > > responsemaker. This will work for most

Re: [TLS] Idempotency and the application developer

On 05/04/2017 11:52 PM, Nico Williams wrote: > On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote: >> 5/04/2017 10:36 PM, Nico Williams wrote: >>> On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote: Which server? It's possible that the backhauls from the server the

Re: [TLS] Idempotency and the application developer

On Thu, May 04, 2017 at 11:14:01PM -0500, Benjamin Kaduk wrote: > On 05/04/2017 07:18 PM, Watson Ladd wrote: > > On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote: > >> In particular there has to be a way, either in-TLS, or at the > >> application layer, to force an extra

Re: [TLS] Idempotency and the application developer

On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote: > 5/04/2017 10:36 PM, Nico Williams wrote: > > On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote: > >> > >> Which server? It's possible that the backhauls from the server the > >> TLS connection is made to to the server

Re: [TLS] Idempotency and the application developer

On 05/04/2017 06:35 PM, Watson Ladd wrote: > If you are willing to buffer 0-RTT until completion before going to > the thing that makes the response, you can handle this problem for the > responsemaker. This will work for most applications I can think of, > and you need to handle large, drawn out

Re: [TLS] Idempotency and the application developer

On 05/04/2017 07:18 PM, Watson Ladd wrote: > On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote: >> >> In particular there has to be a way, either in-TLS, or at the >> application layer, to force an extra round-trip to confirm that the >> 0-rtt data was not an unintended

Re: [TLS] Idempotency and the application developer

5/04/2017 10:36 PM, Nico Williams wrote: > On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote: >> >> Which server? It's possible that the backhauls from the server the >> TLS connection is made to to the server actually responding to the >> request do not distinguish 0-RTT from other

Re: [TLS] Idempotency and the application developer

On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote: > On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote: > > On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote: > >> 0-RTT is opt-in per protocol, and what we think of per application. > > > > Yes. > > >

Re: [TLS] Idempotency and the application developer

On May 4, 2017, at 19:35, Watson Ladd wrote: > > Dear all, > > Applications have always had to deal with the occasional replay, > whether from an impatient user or a broken connection at exactly the > wrong time. But they've generally been rare, so human-in-the-loop >

Re: [TLS] Idempotency and the application developer

On Thu, May 4, 2017 at 8:18 PM, Watson Ladd wrote: > > > > It should be up to servers whether a request is allowed with 0-rtt. > > Which server? It's possible that the backhauls from the server the > TLS connection is made to to the server actually responding to the >

Re: [TLS] Idempotency and the application developer

On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote: > On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote: >> 0-RTT is opt-in per protocol, and what we think of per application. > > Yes. > >> But it isn't opt-in for web application developers. Once browsers and >>

Re: [TLS] Idempotency and the application developer

On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote: > 0-RTT is opt-in per protocol, and what we think of per application. Yes. > But it isn't opt-in for web application developers. Once browsers and > servers start shipping, 0-RTT will turn on by accident or deliberately > at various

Re: [TLS] Idempotency and the application developer

On Thu, May 4, 2017 at 4:35 PM, Watson Ladd wrote: > Dear all, > > Applications have always had to deal with the occasional replay, > whether from an impatient user or a broken connection at exactly the > wrong time. Unfortunately this isn't the case :( Not all

Re: [TLS] Idempotency and the application developer

> On May 4, 2017, at 5:35 PM, Watson Ladd wrote: > > 0-RTT is opt-in per protocol …and at the end of the day, that’s the only reason I’d agree to this. Derrell ___ TLS mailing list TLS@ietf.org

[TLS] Idempotency and the application developer

Dear all, Applications have always had to deal with the occasional replay, whether from an impatient user or a broken connection at exactly the wrong time. But they've generally been rare, so human-in-the-loop responses work. Order the same book twice? Just return one of them, and if you get an

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

Sure, those are fine weasel words. But do we really want to allow into this protocol something that can be misused with security implications in a protocol that’s attempting to solve a security problem? I really don’t know. I’m inclined to say, ‘no’ though. For all those same reasons that

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

Yep, I think your PR is in the right direction. > I have been basically assuming that you can't really do TLS without a > real-time clock, but maybe that's wrong? Well, it’s possible, although I do not know if anyone actually does (and of course certificate validation would be a little

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

On Thu, May 4, 2017 at 3:00 PM, Erik Nygren wrote: > On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote: > >> >> >> >> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: >> >>> > 1. A SHOULD-level requirement for server-side 0-RTT

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

On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote: > > > > On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: > >> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >> both session-cache and strike register styles and the merits of

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

Nits: RFC 4279 reference is missing. "TLS 1.3 and above version, " should probably be "TLS 1.3 and above" or "TLS 1.3 and higher versions" On 04/05/17 18:41, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following

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

On Thu, May 04, 2017 at 02:37:20PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: > > [...] > > I think this is basically right. In the PR I just posted, I spent most of > my time describing the > mechanisms and used a SHOULD-level requirement

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

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote: > > 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

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] Security review of TLS1.3 0-RTT

As promised: https://github.com/tlswg/tls13-spec/pull/1005 Note: I may have to do a little post-landing cleanup, but I wanted to get people's senses of the text ASAP. Comments welcome. -Ekr On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla wrote: > > > On Wed, May 3, 2017 at 8:20

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

On Thu, May 04, 2017 at 01:21:43PM -0700, Colm MacCárthaigh wrote: > On Thu, May 4, 2017 at 12:39 PM, Nico Williams > wrote: > > The SHOULD should say that the server-side needs to apply a replay cache > > OR fallback onto a full exchange when the 0-rtt data payload

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

On Thu, May 4, 2017 at 12:12 PM, Erik Nygren wrote: > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > >> >> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >> both session-cache and strike register styles and the merits of

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

On Thu, May 4, 2017 at 12:39 PM, Nico Williams wrote: > The SHOULD should say that the server-side needs to apply a replay cache > OR fallback onto a full exchange when the 0-rtt data payload involves a > non-idempotent operation. > I don't mean to be dismissive with this

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

On Thu, May 04, 2017 at 02:49:20PM -0500, Nico Williams wrote: > On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote: > > On 05/04/2017 02:39 PM, Nico Williams wrote: > > > The SHOULD should say that the server-side needs to apply a replay cache > > > OR fallback onto a full exchange

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

On Thu, May 04, 2017 at 11:01:02PM +0300, Ilari Liusvaara wrote: > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > > > both

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Yoav, On Thu, May 4, 2017 at 1:59 PM, Yoav Nir wrote: > > On 4 May 2017, at 16:09, Kathleen Moriarty > wrote: > > I haven't approved it yet as I noticed there was no response (that I saw) to > Alexey's comment and no change in the draft as

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

On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote: > On 05/04/2017 02:39 PM, Nico Williams wrote: > > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > >>> 1. A SHOULD-level requirement for

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

On 05/04/2017 02:39 PM, Nico Williams wrote: > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: >>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >>> both session-cache and strike

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

On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > > both session-cache and strike register styles and the merits of each. The SHOULD

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

On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote: > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > both session-cache and strike register styles and the merits of each. > I don't believe this is technically viable for the large-scale server

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

Indeed, as long as the scope of the ticket <= scope of the nonce database, it appears that rerouting wont’ help the attacker. From: Colm MacCárthaigh [mailto:c...@allcosts.net] Sent: Thursday, May 4, 2017 11:33 AM To: Andrei Popov Cc: Ilari Liusvaara

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

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov wrote: > >- Providers already work hard to maximize user affinity to a data >center for other operational reasons; re-routing is relatively rare and >quickly repaired by issuing a new ticket. > > Understood,

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

* Providers already work hard to maximize user affinity to a data center for other operational reasons; re-routing is relatively rare and quickly repaired by issuing a new ticket. Understood, but isn’t an attacker going to be able to re-route at will?

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

On Thu, May 4, 2017 at 11:22 AM, Andrei Popov wrote: > >- I don't think we'll have a problem implementing a single use cache, >strike register, we have similar systems for other services, at higher >volumes. > > … and these things work across

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

* I don't think we'll have a problem implementing a single use cache, strike register, we have similar systems for other services, at higher volumes. … and these things work across geographically distributed datacenters, without negating the latency benefits of 0-RTT? Cheers, Andrei

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

On Thu, May 4, 2017 at 10:07 AM, Andrei Popov wrote: > IMHO what we have is a facility in TLS 1.3 that: > 1. Requires extraordinary effort on the server side to mitigate replay > (for all but the smallest deployments); > 2. Offers no way for the client to determine

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

> On 4 May 2017, at 16:09, Kathleen Moriarty > wrote: > > I haven't approved it yet as I noticed there was no response (that I saw) to > Alexey's comment and no change in the draft as a result of his comments. You mean these comments?

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

IMHO what we have is a facility in TLS 1.3 that: 1. Requires extraordinary effort on the server side to mitigate replay (for all but the smallest deployments); 2. Offers no way for the client to determine whether the server is mitigating replay (before replay becomes possible); 3. Is trivial to

[TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits

Re: [TLS] trusted_ca_keys

Feel better Jason! -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich Sent: Thursday, May 4, 2017 10:58 AM To: m...@sap.com Cc: Natasha Rooney ; tls@ietf.org Subject: Re: [TLS] trusted_ca_keys > There is some wording in PKIX and X.509

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: [ Charset UTF-8 unsupported, converting... ] > > The organization info (O, L, ST, C, etc...) is supposed to differ in that > > case (CN > > is just one field of DN), rendering the full DNs distinct. > > But where and how is that enforced, or enforceable? Again, any links to

Re: [TLS] trusted_ca_keys

> On May 4, 2017, at 10:58 AM, Salz, Rich wrote: > > I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally prevent > CA2 from issuing a sub-ca with the exact same DN. Can you explain what I am > missing? You forgot that all the CA certificates are of course

Re: [TLS] trusted_ca_keys

> The organization info (O, L, ST, C, etc...) is supposed to differ in that > case (CN > is just one field of DN), rendering the full DNs distinct. But where and how is that enforced, or enforceable? Again, any links to show I'm wrong? ___ TLS

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: [ Charset windows-1252 unsupported, converting... ] > > There is some wording in PKIX and X.509 which creates the impression that a > > CA could be re-using the same Subject DName with different keys, but such > > an interpretation is a formally provable defect of the PKIX

Re: [TLS] trusted_ca_keys

On Thu, May 04, 2017 at 02:58:07PM +, Salz, Rich wrote: > > There is some wording in PKIX and X.509 which creates the impression > > that a CA could be re-using the same Subject DName with different keys, > > but such an interpretation is a formally provable defect of the PKIX > >

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

> On May 4, 2017, at 08:41, Hubert Kario wrote: > > On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote: >> All, >> >> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree >> with Yoav’s statement at the mic in Chicago that the WG should review

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: > >> The certificate should have its own DN, use that. > > She's saying that it *doesn't.* > > SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use > that. SubjectDN of a *Certificate Authority* **MUST** be unique. There is some wording in PKIX and

[TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Authors : John

Re: [TLS] trusted_ca_keys

> The certificate should have its own DN, use that. She's saying that it *doesn't.* SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] trusted_ca_keys

On Thu, May 04, 2017 at 01:26:02PM +, Natasha Rooney wrote: > > GSMA are working on future SIM specifications which use TLS and > previously included the trusted_ca_keys to allow a client to > inform a server which particular key(s) from a CA it is > supporting. In TLS 1.3 the

[TLS] trusted_ca_keys

Hi all! Apologies for the odd and potentially silly question. GSMA are working on future SIM specifications which use TLS and previously included the trusted_ca_keys to allow a client to inform a server which particular key(s) from a CA it is supporting. In TLS 1.3 the ‘trusted_ca_keys’

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

I haven't approved it yet as I noticed there was no response (that I saw) to Alexey's comment and no change in the draft as a result of his comments. I'll wait in responses for these 2 items. Thank you, Kathleen Sent from my iPhone > On May 4, 2017, at 8:41 AM, Hubert Kario

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote: > All, > > draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree > with Yoav’s statement at the mic in Chicago that the WG should review the > changes before we ask Kathleen (our newly appointed AD) to continue >

Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02

Hi, Oops, I missed your email. the version 03 has been submitted. For some reason my email address is not in the database, so it has to be confirmed by someone else or the secretariat. Yours, Daniel From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] Sent: Tuesday, May 02, 2017

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

On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. > Thanks to feedback in the room I've now tightened up the findings from the >