Re: [TLS] KeyUpdate and unbounded write obligations

On Thu, Aug 18, 2016 at 2:26 PM, Adam Langley wrote: > I think I was because I hadn't seen your Berlin presentation. But I'm still > going to hijack this thread and ask you to expand on some of these points so > that I understand your motivation :) Fair enough. :-) >>

Re: [TLS] KeyUpdate and unbounded write obligations

Okay, this is a different question -- whether P3 is a valuable property or not. I made the case for this in my Monday thread[1] and in my Berlin presentation[2]. [1] https://www.ietf.org/mail-archive/web/tls/current/msg20787.html [2]

Re: [TLS] KeyUpdate and unbounded write obligations

Yes, you need current_receive_generation, or something like it, to get P3. This is the subject of our PR #426/580. -Keith On Thu, Aug 18, 2016 at 12:10 PM, Adam Langley wrote: > On Thu, Aug 18, 2016 at 11:55 AM, David Benjamin > wrote: >> >> It

Re: [TLS] KeyUpdate and unbounded write obligations

> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Keith Winstein > Sent: Thursday, August 18, 2016 11:21 AM > To: David Benjamin > Cc: tls@ietf.org > Subject: Re: [TLS] KeyUpdate and unbounded write obligations > > It sounds like there

Re: [TLS] KeyUpdate and unbounded write obligations

I am also fuzzy on P2 and P3, but don't have any complaints with this strawman scheme. -Ben On 08/18/2016 01:55 PM, David Benjamin wrote: > Yeah, something of this sort should work. I'm fuzzy on P2 and > especially unconvinced by P3, so I default to preferring less > mechanism than more, but I'm

Re: [TLS] KeyUpdate and unbounded write obligations

Yeah, something of this sort should work. I'm fuzzy on P2 and especially unconvinced by P3, so I default to preferring less mechanism than more, but I'm certainly wrong a lot of the time and am not totally clear on which properties the WG cares about. As you say, it's not particularly invasive to

Re: [TLS] KeyUpdate and unbounded write obligations

It sounds like there are four properties in play here: P1: Either side can rekey its outgoing traffic whenever it wants. P2: Either side can "force an update to the entire connection," i.e. can ask the other side to rekey *its* outgoing traffic. P3: A side can learn that P1 has been read by the

[TLS] Short Authentication Strings for TLS

Daniel Kaiser and I are working on a "pairing" specification in the context of DNS SD. Short Authentication Strings are one of the preferred methods for verifying pairings. I would like to use TLS as much as possible in the pairing protocol. EKR pointed me to the expired draft by Ian Miers,

Re: [TLS] KeyUpdate and unbounded write obligations

On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk wrote: > On 08/17/2016 11:29 PM, David Benjamin wrote: > > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Depending on what > we want out of

Re: [TLS] KeyUpdate and unbounded write obligations

On 08/17/2016 11:29 PM, David Benjamin wrote: > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Depending on > what we want out of KeyUpdate, I can imagine a few options: > My recollection is that the only reason we

Re: [TLS] Pre_shared_key Extension Question

On Thu, Aug 18, 2016 at 11:54 AM Eric Rescorla wrote: > On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk wrote: > >> On 08/18/2016 10:29 AM, Eric Rescorla wrote: >> >> >> >> On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk >> wrote: >> >>> On

Re: [TLS] Pre_shared_key Extension Question

On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk wrote: > On 08/18/2016 10:29 AM, Eric Rescorla wrote: > > > > On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk wrote: > >> On 08/17/2016 05:17 PM, Eric Rescorla wrote: >> >> It would be a fairly significant

Re: [TLS] Pre_shared_key Extension Question

On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk wrote: > On 08/17/2016 05:17 PM, Eric Rescorla wrote: > > It would be a fairly significant simplification to say you could only have > one PSK, because then we could easily require the client to prove knowledge > of the key, for

Re: [TLS] Pre_shared_key Extension Question

On 08/17/2016 05:17 PM, Eric Rescorla wrote: > It would be a fairly significant simplification to say you could only > have one PSK, because then we could easily require the client to prove > knowledge of the key, for instance by stuffing a MAC at the end of the > ClientHello as we discussed in

Re: [TLS] draft-ietf-tls-tls13-15

On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara wrote: > > > David Bejamin already posted a PR about that. Doesn't clearly say > > > that unknown reason handling. > > > > > > > Yeah, I read the list before the PRs. I'll take a look but if you want to > > comment that

Re: [TLS] draft-ietf-tls-tls13-15

On Thu, Aug 18, 2016 at 05:29:34AM -0700, Eric Rescorla wrote: > Thanks for the quick review. > > On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara > wrote: > > - I note that accepting PSK and selecting the auth mode seem to be > > in separate messages, which seems

Re: [TLS] draft-ietf-tls-tls13-15

Thanks for the quick review. On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara wrote: > On Wed, Aug 17, 2016 at 02:49:52PM -0700, Eric Rescorla wrote: > > Folks, > > > > I've just submitted draft-ietf-tls-tls13-15. > > Doing brief review: > > - Section 4.2.2 talks

Re: [TLS] KeyUpdate and unbounded write obligations

I think it's probably possible to make everybody happy here. I appreciate the need to avoid allowing the other side to create an unbounded deferred write/compute obligation. I also think it's valuable to preserve the ability for "either side to force an update to the entire connection," and