Re: [TLS] Simple, secure 0-RTT for the masses

2016-03-15 Thread Bill Cox
On Tue, Mar 15, 2016 at 2:45 PM, Colm MacCárthaigh wrote: > I think I agree with that; but maybe would state it as: we can preserve > forward secrecy and replay mitigation for 0RTT data, but at the cost of > read-after-write consistency from a server-side data-store. The store

Re: [TLS] Simplifying signature algorithm negotiation

2016-03-15 Thread Eric Rescorla
On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin wrote: > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > >> David, >> >> Thanks for being patient with me here. Sorry it took so long >> >> As usual, this seems like a question of whether we're going

Re: [TLS] Simple, secure 0-RTT for the masses

2016-03-15 Thread Colm MacCárthaigh
On Tue, Mar 15, 2016 at 4:59 PM, Bill Cox wrote: > I prefer your solution, but it would require getting the TLS 1.3 protocol > changed. TLS 1.3 seems to be geared towards making stateless resumption > with reusable tickets. > We keep circling that alright, and it

[TLS] PSK in TLS 1.3

2016-03-15 Thread Hannes Tschofenig
Hi Ekr, Hi all, I am not entirely sure about the PSK story in TLS 1.3. In Section 6.2.3 I read that the PSK approach has been combined with resumption. Appendix A4 lists the defined ciphersuites but there is no PSK-based ciphersuite in that list. Section 6.3.1.2 explains that the ServerHello

Re: [TLS] Simple, secure 0-RTT for the masses

2016-03-15 Thread Eric Rescorla
On Tue, Mar 15, 2016 at 12:51 PM, Bill Cox wrote: > I think it is worth documenting what we feel would be the simplest secure > 0-RTT mode that is safe for any company to use. I think we owe the users a > link to such a document in the TLS 1.3 spec. Here is my attempt

Re: [TLS] Simple, secure 0-RTT for the masses

2016-03-15 Thread Colm MacCárthaigh
On Tue, Mar 15, 2016 at 3:51 PM, Bill Cox wrote: > I think it is worth documenting what we feel would be the simplest secure > 0-RTT mode that is safe for any company to use. I think we owe the users a > link to such a document in the TLS 1.3 spec. Here is my attempt at

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-15 Thread Cullen Jennings (fluffy)
> On Mar 15, 2016, at 1:40 PM, Cullen Jennings (fluffy) > wrote: > > > I think this draft needs WGLC in all the WGs where it limits the existing > code space. Somehow hit send trying to move this from one computer to another before finishing it. But what I was going on

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-03-15 Thread Cullen Jennings (fluffy)
I think this draft needs WGLC in all the WGs where it limits the existing code space. > On Feb 7, 2016, at 10:21 PM, Joseph Salowey wrote: > > This document is relevant to the TLS working because it reserves a large > portion of the TLS content type space. The values

Re: [TLS] Simplifying signature algorithm negotiation

2016-03-15 Thread David Benjamin
On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > David, > > Thanks for being patient with me here. Sorry it took so long > > As usual, this seems like a question of whether we're going to want a lot > of flexibility > (thus motivating orthogonal negotiation) versus whether

Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

2016-03-15 Thread Ilari Liusvaara
On Mon, Mar 14, 2016 at 12:32:51PM -0700, Eric Rescorla wrote: > > As far as I can tell, there's no protocol difference between "stateful" and > "stateless" resumption. > You use the same techniques (a replay cache) and the question is merely > whether the server > actually maintains one.