On 05/12/2018 10:22, Bret Jordan wrote: > I think we should be more open minded and look at the needs from a > 360 degree deployment perspective.
I think we should avoid marketing speak. > The real power of the IETF is in > looking at all the needs and requirements and designing solutions for > them. The IETF is sometimes at it's best when it says "no." This is one of those cases. > 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. All of the above was done, at length, and we got a result. The TLS WG had no consensus to work on this topic. S. > > 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> > >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
