Sigh:-( IMO the WG shouldn't touch this terrible proposal with a bargepole.
And it remains outside the WG's charter I think. (It would be a good idea if the chairs would clarify that a re-charter would be needed were the WG to go bonkers and adopt a terrible idea like this.) I guess I'll need to update [1] too. I'll get back when I've had a chance to do that but will happily accept PRs as before and will keep an eye on the list. For starters, though, I'd be interested answers from the authors to two quick questions, though I suspect I can guess 'em: 1. TLS1.3 has had significant formal analysis. Did the authors or other proponents here do any such work and if so can you send a pointer to your results? If not, then I believe the onus is on the folks who want to break TLS to do that work themselves if they want to make a serious proposal and it is not ok IMO to try put that work onto the community who have been working hard for years to make TLS stronger. 2. Which of the hundreds of applications making use of TLS did you analyse before proposing this? If only a handful, then same comment wrt where the onus ought lie. S. [1] https://github.com/sftcd/tinfoil#latest On 02/10/17 21:31, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS > extension defined in this I-D takes into account what we heard from the > discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 > in Prague. Specifically, it provides an opt-in capability for both the TLS > client and server and makes it clear on the wire that visibility will be > enabled for the session. The new mechanism does not depend on static > handshake or session keys. > > - Ralph and Russ > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
