You seem to be raising a complaint with my option #1, the "1-bit" option.
You're correct -- in that scheme, a node can only assume that the
other side has read as many KeyUpdates as it has gotten in response.
If the client decides to send KeyUpdates every 5 minutes, but the
other side is only writ
On Thu, Sep 01, 2016 at 02:11:13PM -0700, Keith Winstein wrote:
> I think we have to oppose a change to KeyUpdate that adds P4 (bounded
> write obligations) but not P3 (ability to learn that a KeyUpdate was
> read by other side). These are orthogonal and easily achievable with a
> pretty small twea
On Thu, Sep 01, 2016 at 02:32:41PM -0700, Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 2:29 PM, Ilari Liusvaara
> wrote:
>
> > On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> > > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <
> > ilariliusva...@welho.com>
> > > wrote:
> >
> >
On Thu, Sep 1, 2016 at 5:29 PM Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > I tried to implement this, and discovered an issue:
> > >
> > > The client
On Thu, Sep 1, 2016 at 2:29 PM, Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > I tried to implement this, and discovered an issue:
> > >
> > > The client
On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara
> wrote:
>
> > I tried to implement this, and discovered an issue:
> >
> > The client handshake traffic secret is needed for deriving client
> > Finished, and client application traffi
On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 12:55:29PM -0700, Eric Rescorla wrote:
> > I have created a PR for this at:
> > https://github.com/tlswg/tls13-spec/pull/611
> >
> > As it seems there was rough consensus for this change, I will merge this
> > weeken
I think we have to oppose a change to KeyUpdate that adds P4 (bounded
write obligations) but not P3 (ability to learn that a KeyUpdate was
read by other side). These are orthogonal and easily achievable with a
pretty small tweak. Here are four options that would work for us:
1. No change to messag
On Thu, Sep 01, 2016 at 12:55:29PM -0700, Eric Rescorla wrote:
> I have created a PR for this at:
> https://github.com/tlswg/tls13-spec/pull/611
>
> As it seems there was rough consensus for this change, I will merge this
> weekend
> absent some violent objections or direction to the contrary from
I have created a PR for this at:
https://github.com/tlswg/tls13-spec/pull/611
As it seems there was rough consensus for this change, I will merge this
weekend
absent some violent objections or direction to the contrary from the chairs.
-Ekr
On Mon, Aug 29, 2016 at 3:06 PM, Russ Housley wrote:
Eric:
> Yes, I agree separate ladders would fix this. I don't necessarily object to
> this
> change, but I'm not sure it's that big a deal either, because you really only
> get
> into this case when there's a big asymmetry in sending rate, so much that
> one side wants to send multiple updates b
On Mon, Aug 29, 2016 at 11:11 AM, Adam Langley
wrote:
> On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla wrote:
> > Yes, I agree separate ladders would fix this. I don't necessarily object
> to
> > this
> > change, but I'm not sure it's that big a deal either, because you really
> > only get
> >
On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla wrote:
> Yes, I agree separate ladders would fix this. I don't necessarily object to
> this
> change, but I'm not sure it's that big a deal either, because you really
> only get
> into this case when there's a big asymmetry in sending rate, so much t
On Mon, Aug 29, 2016 at 10:30 AM, Ilari Liusvaara
wrote:
> On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote:
> > On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote:
> > > >
On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote:
> On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara
> wrote:
>
> > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote:
> > >
> > > I'd prefer to keep things as simple as possible here and from that
> > > perspective, I thin
On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara
wrote:
> On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote:
> >
> > I'd prefer to keep things as simple as possible here and from that
> > perspective, I think any indicator from side A to side B that it wants a
> > key change over and
On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote:
>
> I'd prefer to keep things as simple as possible here and from that
> perspective, I think any indicator from side A to side B that it wants a
> key change over and above the KeyUpdate is extra complexity. I do, however,
> want to r
I'd like to close this discussion if we can.
I'd prefer to keep things as simple as possible here and from that
perspective, I think any indicator from side A to side B that it wants a
key change over and above the KeyUpdate is extra complexity. I do, however,
want to retain the property that one
On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara
wrote:
> The generations are not specified as integers. It is just some abstract
> sequence (nowhere in protocol is that generations are integers used).
The current draft requires that upon receipt of a KeyUpdate, "the
receiver MUST update their re
On Wed, Aug 24, 2016 at 04:01:45PM -0700, Keith Winstein wrote:
> Hi Subodh,
>
> Interesting points.
>
> On the form of the generation identifier: The draft does already
> specify the generations as integers (traffic_secret_N, N+1, etc.), and
> the semantics of a KeyUpdate are that when you recei
t; From: TLS [tls-boun...@ietf.org] on behalf of Keith Winstein
> [kei...@cs.stanford.edu]
> Sent: Friday, August 19, 2016 8:40 PM
> To: Stephen Farrell
> Cc: Adam Langley; tls@ietf.org
> Subject: Re: [TLS] KeyUpdate and unbounded write obligations
>
> On Fri, Aug 19, 2016 at 2:2
kei...@cs.stanford.edu]
> Sent: Friday, August 19, 2016 8:40 PM
> To: Stephen Farrell
> Cc: Adam Langley; tls@ietf.org
> Subject: Re: [TLS] KeyUpdate and unbounded write obligations
>
> On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell
> wrote:
> >
> > And for me, the
e the API simpler.
Subodh
From: TLS [tls-boun...@ietf.org] on behalf of Keith Winstein
[kei...@cs.stanford.edu]
Sent: Friday, August 19, 2016 8:40 PM
To: Stephen Farrell
Cc: Adam Langley; tls@ietf.org
Subject: Re: [TLS] KeyUpdate and unbounded write obligation
On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell
wrote:
>
> And for me, the dodgiest, by far. The scope for an "auditor"
> (what is that?) actually being an attacker is IMO way too
> high to consider standardising that kind of feature and any
> idea that it'd involve informed consent of someone se
On Fri, Aug 19, 2016 at 11:05 AM, Adam Langley wrote:
> I don't think that a device can ensure that the other side doesn't get
> compromised. Even if it rotates keys, there are plenty of ways that a well
> meaning implementation could fail to erase them: copying GCs, swap,
> hibernation, coldboot
On 19/08/16 19:05, Adam Langley wrote:
>> > Right, exactly. (Ideally, the device doesn't even know it's being
>> > audited until the user logs in to the Web UI and says, "okay, now,
>> > ratchet the session and then share the old keys with this auditor that
>> > I am going to introduce you to, so
On Thu, Aug 18, 2016 at 5:18 PM, Keith Winstein
wrote:
> Yeah, our reasoning follows yours and goes a little further:
>
> 4) I don't know when I'm going to wake up again.
> 5) I don't want a subsequent compromise of me *or* the other side to
> reveal prior plaintext from the session.
> 6) Because
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. :-)
>> - An embedded device may w
On Thu, Aug 18, 2016 at 1:36 PM, Keith Winstein
wrote:
> On the value of P3, I think you're giving us a crimped reading. We
> gave three use cases in Berlin and in my email:
>
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 e
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] https://www.ietf.org/proceedings/96/slides/slides-96-tls-3.pdf
On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein
wrote:
> Yes, you need current_receive_generation, or something like it, to get
> P3. This is the subject of our PR #426/580.
>
The KeyUpdate messages are encrypted and thus sequenced with all the
application data. Apart from the Heartbeat message
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 seems desired_minimum_receive_generation can only
> -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 ther
On Thu, Aug 18, 2016 at 11:55 AM, David Benjamin
wrote:
> It seems desired_minimum_receive_generation can only be
> current_receive_generation or current_receive_generation + 1. In that
> case, a boolean should be sufficient and saves 7 bytes.
>
Given that simplification, is there a purpose for
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
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
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
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 KeyUpdate, I can imagine a f
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 ha
On Thu, Aug 18, 2016 at 12:30:03AM -0700, Keith Winstein wrote:
> 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
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 obviou
Amusingly, Keith and I appear to have crossed mid-air in our respective
requests to change KeyUpdate, so this will be a fun collision. Mine is a
tad larger of a change I'm afraid.
We've currently implemented KeyUpdate in our in-progress TLS 1.3 code, but
we've for now ignored the requirement for t
42 matches
Mail list logo
