On Tue, Mar 13, 2018 at 1:21 PM, Melinda Shore <melinda.sh...@nomountain.net> wrote: > On 3/13/18 6:48 AM, Jim Reid wrote: >> Stephen, the opposite PoV is equally valid. There was no consensus in >> Prague NOT to work on the topic. The mood of the room was evenly >> divided. > > To clarify, this isn't voting. If there's no agreement in > either direction there's no agreement (and I hope the default > in the IETF is not that in the absence of agreement, work > goes forward). The problem is how to come to agreement, and > what that typically involves is refining the proposal to > address objections.
And then there are other options too, like another WG. Even from Stephen's list of who is in agreement with him, I've received a few messages saying their text wasn't what he thinks it was. More discussion here would be good to figure out a way forward. The chairs have not agreed to allow the work to go forward, but just the discussions to determine next steps. > >> IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to >> drop that draft and come back with a new one which would hopefully be >> more likely to get WG consensus. That draft has now arrived. It’s >> unreasonable to deny the new I-D a fair hearing and even worse to >> reject it out of hand. > > It's surprising that it got agenda time without mailing list > discussion. Aside from the changes to the key > exchange there are some clear usability problems. While > usability usually lies outside the purview of the IETF's > technical work, in this case the work is premised on the > ability of the user to consent (or not) to sharing keying > material with a third party, which in turn suggests that > they're presented with the question at the time the > session is initiated, so that the extension isn't sent in > the ClientHello. Sounds like a click-through problem, > tbh, where the user has little practical control over whether > or not their data are shared with a third party. This should have had discussion time in Singapore, as the chairs mentioned. I'm mostly responding though because their use cases are entirely server-to-server from what I understand. The client connection to the enterprise can terminate at the network edge, then anything within the enterprise is from another encrypted session (which could be TLS 1.2 or another protocol, or this proposal, or something else including methods that eliminate the architectural design for monitoring on the wire within the datacenter). If there were a way to limit this extension to server-to-server, that would eliminate the click through problem you mention and the server admin would be aware on either end of this usage. I don't know if there is a way to do this without using another protocol, but making the use case clear may help with ideas. Best, Kathleen > > Melinda > > > -- > Software longa, hardware brevis > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
