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 I'm happy to make the case for P3 here again but didn't want to hijack David's thread. My claim here was that there are some simple designs that satisfy everybody and grant P1+P2+P3+P4, and that David's concern's and my concerns are "basically orthogonal issues." === 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: - An embedded device may wish to fully rotate the session keys before going to sleep. - 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.) - An endpoint that wishes to permit a read-only virus scanner or IDS will want to fully rotate the session before sharing the directional keys with the middlebox. 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. Unlike Heartbeat, we are not talking about an ack that would be generated by something, and we're not really talking about altering TLS's design. We're talking about piggybacking one field in a protocol message that is going to be sent anyway, where the message (KeyUpdate) is new in TLS 1.3 anyway. As I said, it is orthogonal to David's issues here. Yes, it is possible to get P1+P2+P4 by themselves -- P3 has to live or die on its own merit. But it is really just one piggyback field to get it. -Keith On Thu, Aug 18, 2016 at 12:42 PM, Adam Langley <[email protected]> wrote: > On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein <[email protected]> > 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 (TLS 6520), which has not > been significantly used in TLS (I think), we've never worried about a > TLS-level ack before. > > PR 426 wants a way to retrospectively disclose keys to middleware and wants > to make sure that the receive side is no longer going to trust those keys > before doing so. Having spoken to several vendors of these products in the > past and tried to persuade them to accept read-only access I don't think we > should alter TLS's design for that unless there's a novel argument about why > they would ever accept it. (Because they won't. Their competitive interest > is to have as many "features" as possible, many of which would require > modifying traffic.) > > > Cheers > > AGL _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
