On Fri, Jun 6, 2014 at 8:38 PM, Dan Wing <dw...@cisco.com> wrote: > > On Jun 3, 2014, at 10:26 AM, Phillip Hallam-Baker <i...@hallambaker.com> > wrote:
>> One of the biggest mistakes in TLS and DTLS is that they are built >> around the assumption that there is a public key handshake at the >> start of each connection and efficient restart is an afterthought. We >> have managed to add in Kerberos ticket like options to TLS over the >> years but they are extensions rather than the core. > > If we required those extensions to be implemented, what's the problem? > > -d Well first off only IETF folk think that we are in charge of the Internet. The first law of the Internet is "you are so not in charge (for all values of you)" We have tried requiring many things like IPV6 and DNSSEC and it didn't work. And even when it works, it is sloooooooooow. But the second problem is that the ticket approach in TLS is only there as an extension that provides a small performance gain. Which isn't very interesting or valuable. The value of the ticket approach isn't efficiency, its simplicity. Build on the ticket approach from the ground up and build it into everything and I can cut out 80% of the TLS spec AND 90% of IPSEC and support the same functionality. It is possible to buy a turntable for vinyl records with a USB plug on the end to connect to a computer. That provides digital output but the result is nothing like CD which is all digital end to end. Adding tickets to TLS is like sticking a USB plug on an analog device: it provides impedance matching but nothing more. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
