I think we should be more open minded and look at the needs from a 360 degree deployment perspective. The real power of the IETF is in looking at all the needs and requirements and designing solutions for them.
We should flesh this out. It seems like several people on this list so far have proposed options that might work. If we spent half as much time looking for a solution as we have trying to prevent a solution, we would probably be done by now. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > On Dec 5, 2018, at 6:12 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > > On 05/12/2018 08:08, Bret Jordan wrote: >> Now this WG is finally starting to talk about a solution to a real >> problem and need. We can either address the use case and need here >> in the IETF, or we can let the solutions be done else where. I would >> personally prefer we take this work item back and solve it here in >> the IETF. > > #include <previous-discussions> > > I would hope the WG not revisit this topic and see no new > facts to justify distracting the WG again. Forum shopping > is not new - rubber-stamping by ETSI or ANSI was explicitly > proposed as a putative reason to adopt draft-green and that > did not result in consensus to work on this topic despite > the significant effort put in by proponents. I'm also happy > to say that I see no evidence that the WG would reach a > different conclusion as to lack of consensus. > > FWIW, I view this discussion as being analogous to scratching > an itchy scab - despite our knowing it is unproductive to do > so, some IETF participants apparently can't resist poking at > the wound:-( > > S. > >> >> Finally, remember, you may not like the use case or need, but that >> does not mean the use case is not valid and needed. >> >> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 >> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, >> the only thing that can not be unscrambled is an egg." >> >>> On Dec 5, 2018, at 1:18 AM, Tony Arcieri <basc...@gmail.com> >>> wrote: >>> >>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <n...@cryptonector.com >>> <mailto:n...@cryptonector.com>> wrote: >>>> I'm not a fan of systems like this, but I believe for security >>>> reasons they should be designed in such a way that only the >>>> confidentiality of traffic is impacted, and a "visibility" system >>>> isn't able to leverage the decrypted traffic to resume decrypted >>>> sessions and thereby impersonate clients. >>> >>> Any key escrow system will have this property. Given the session >>> keys (or a way to recover them) you can resume decrypted sessions. >>> >>> Wouldn't escrowing only the client/server application traffic >>> secrets (instead of keys higher in the schedule) avoid this >>> problem? These keys would permit the one capability "visibility" >>> appliance vendors allege to care about: traffic decryption, without >>> permitting others like session resumption. >>> >>> The most obvious escrow design requiring no changes to the clients >>> is to use a static eDH key on the server-side. The next most >>> obvious such design is to have the server talk to the escrow >>> agent. >>> >>> It seems like with an out-of-band escrow agent, the traffic secrets >>> could be escrowed with no changes to TLS. >>> >>> -- Tony Arcieri _______________________________________________ TLS >>> mailing list TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >> > <0x5AB2FAF17B172BEA.asc>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
