Re: [TLS] KeyUpdate and unbounded write obligations

[Judson Wilson <[e-mail]>]

>
>
> For the use cases you mentioned Keith, they seem to be specific to
> application triggered key updates, i.e. key updates do not mean anything to
> the TLS layer apart from I got a key update and I must change keys. The
> fact that other side has thrown away it's key is only meaningful to the
> higher layer protocol. I imagine protocols like HTTP would not add these
> semantics, and these semantics would be added to very specific IoT
> protocols? Would the scope of the auditor be defined as a part of that
> protocol, or does it need to be defined as a part of TLS?
>
>
It makes more sense to have the TLS layer disseminate information about
which keys are in use, rather than have the higher layer try to infer it.
Conceivably, either endpoint can cooperate with a user to by giving the
user the keys that are no longer in use on the channel. (Endpoints can
already do this, but without any guarantee that the keys are not in use.)
With the very small piggyback that Keith proposed, a client application
could get an assurance which keys are no longer in use, without any changes
on the server side. TLS termination devices, load balancers, reverse
proxies, and HTTP servers would all be compatible without any further
changes - the format on the wire would be unchanged.

I also believe that we all agree that adding a full auditing spec is far
beyond the scope of TLS. However, with this small change to KeyUpdate,
there might be opportunities to add such a feature to IoT devices without
having to re-engineer the front end of a cloud application - the wire
compatibility is a really nice feature in this regard. An IoT device could
possibly be compliant with some future auditing spec while using plain-old
HTTP and TLS 1.3 in the cloud.

If key update is an application triggered mechanism, does the generation
> identifier need to be an integer to be understood by the TLS layer or could
> it also be an opaque identifier sent by the application. It would be much
> simpler not to have to deal with the requirements of consistency at the TLS
> layer and would make the API simpler.


I don't think this introduces any kind of consistency issues at the TLS
layer.  The receiver simply needs to keep count of the receive key
generation, and put this number (or even a numerically smaller one) in any
subsequent outgoing KeyUpdate.

It would also be sufficient to transmit a boolean indicating whether the
KeyUpdate message is an initiating message, or a response message (I am
omitting some details), but that would not work well with mitigating this
multiple KeyUpdate backlog issue which is the original topic of this thread.


On Tue, Aug 23, 2016 at 11:47 AM, Subodh Iyengar <[e-mail]> wrote:

> For people that currently use keyupdates or who are planning to use key
> updates, which layer are you planning to trigger a key update? Would the
> TLS implementation itself trigger the update or would the application
> trigger it? For renegotation, I believe it was mostly triggered by the
> application.
>
> For the use cases you mentioned Keith, they seem to be specific to
> application triggered key updates, i.e. key updates do not mean anything to
> the TLS layer apart from I got a key update and I must change keys. The
> fact that other side has thrown away it's key is only meaningful to the
> higher layer protocol. I imagine protocols like HTTP would not add these
> semantics, and these semantics would be added to very specific IoT
> protocols? Would the scope of the auditor be defined as a part of that
> protocol, or does it need to be defined as a part of TLS?
>
> If key update is an application triggered mechanism, does the generation
> identifier need to be an integer to be understood by the TLS layer or could
> it also be an opaque identifier sent by the application. It would be much
> simpler not to have to deal with the requirements of consistency at the TLS
> layer and would make the API simpler.
>
> Subodh
> ________________________________________
> From: TLS [[e-mail]] on behalf of Keith Winstein [
> [e-mail]]
> Sent: Friday, August 19, 2016 8:40 PM
> To: Stephen Farrell
> Cc: Adam Langley; [e-mail]
> Subject: Re: [TLS] KeyUpdate and unbounded write obligations
>
> On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell
> <[e-mail]> 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 seems to
> > me fictional.
>
> I appreciate the sensitivity of this issue to the WG. My read of your
> email is that there's a concern that by standardizing a protocol
> mechanism that allows a node to learn when its own KeyUpdate has
> happened, the WG would imply approval of features that permit
> the bad kind of eavesdropping. Here's why I don't think that's the case:
>
> Our PR is for a piggyback integer field to provide security property
> P3: "An implementation can learn that its request to rekey its
> outgoing traffic has been read by the other side."
>
> KeyUpdate is an *instruction* to the other side: "please update my key
> in a forward-secure manner." We think some implementations will want
> to know that the instruction has been carried out. And there's an easy
> opportunity to do that here as a piggyback, without any extra protocol
> messages.
>
> A node will naturally care more about forward secrecy, and
> confirmation of a forward-secure ratcheting event, the more it has
> reason to suspect the keys might later be exposed to a third party. In
> Berlin, I described three escalating cases: the (1) node going to
> sleep, (2) node closing a connection without a mechanism for secure
> bidi close, and (3) node that itself intends to release keys to a
> read-only auditor after a ratchet is complete.
>
> By "read-only auditor," we mean a curious person or security
> researcher who owns an IoT device and wants to know what the heck it
> is sending out of their house, where the device doesn't want to allow
> its owner to add trusted certificates for an MITM. (This describes
> most such devices today.)
>
> Obviously I think it's valuable to make this mechanism available for
> IoT device manufacturers. Having talked to several manufacturers, I'm
> cautiously optimistic that some would use this. But the WG doesn't
> have to take a position on this. These use cases are up to
> implementers. There's nothing stopping an implementer today from
> releasing session keys, or allowing complete MITM, as is the case in
> the browser context with user- or admin-installed root CA
> certificates. The TLS WG hasn't opined on these either.
>
> To restate: Property P3 allows a node to learn that its KeyUpdate
> instruction has actually happened, which in our view is useful and a
> strict benefit over the status quo. It's also orthogonal to the issue
> of unbounded write obligations raised in this thread.
>
> -Keith
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_tls&d=DQICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=
> h3Ju9EBS7mHtwg-wAyN7fQ&m=dPWRCHpTfdtxfXYBMZF__UyOa7wszKFnA6criwmMDHI&s=
> E7sRstn6vNQHPiX3CXAa6BbWSWtMW7VKtN4f3yblZ5U&e=
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>