On Thu, Aug 18, 2016 at 1:36 PM, Keith Winstein <kei...@cs.stanford.edu> 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 expand on some of these points so that I understand your motivation :) - An embedded device may wish to fully rotate the session keys before > going to sleep. > I imagine the argument here goes: 1) Sleep is good because it saves power. 2) To sleep we need to power down (and erase) most memory. 3) So to keep a TLS connection across sleep/wake secrets have to be saved to flash, but that's hard to erase so we don't want to expose keys that were used to encrypt traffic. For that I see why one needs KeyUpdate to be echoed: as the embedded device, you want the peer to rotate keys so that you can write only fresh keys to flash. On wake you want the other side to rotate again so that the keys in flash were only used to authenticate a new KeyUpdate. But why do you need the other side to have confirmed that it has erased your keys? I think you only care that it echos your KeyUpdate messages promptly. - A paranoid device might fully rotate the session keys before closing > the session. (If confirmation is absent, the device might use a > higher-level mechanism to forcibly log out all open sessions from that > user.) > The worry here is that a peer might be seized and subject to a cold-boot attack to lift the TLS connection keys? So if you don't hear from it every $x seconds you'll log it out? Again does the confirmation here help? What if you send a KeyUpdate and receive a change password request? The peer might well have sent it before receiving your KeyUpdate, or maybe it was seized and will just choose not to echo your KeyUpdate. (I might well be misunderstanding the details here.) On this last use case, I agree that incumbent IDS vendors may not be > eager to support it. But adoption would probably come from a different > direction. IoT devices today forbid anybody, including a middlebox > controlled by the device owner, from auditing their own traffic and > seeing what the devices are sending and receiving. (Unlike a browser, > they don't let the user add a private CA cert to be able to MITM.) In > my conversations with IoT device vendors, some expressed interest in > allowing device owners to grant read-only access to themselves. I > really do think this would be a good thing. > If they have a channel to the user where they are sending a stream of old keys, couldn't they just mirror the plaintext of the connection to keep things simple? I guess you worry about a device that's cooperative enough to put in the effort to have their audit channel but lies about the plaintext? Cheers AGL
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
