On Tue, Sep 17, 2013, at 09:15 AM, Ben Laurie wrote: > On 17 September 2013 13:17, Mark Handley <[email protected]> wrote: > > QUIC could, of course, take the same approach as tcpcrypt. Do encryption by > > default using ephemeral public keys, even with no configuration, but provide > > the hooks to enable various forms of authentication. From what I've read, > > it doesn't seem to do that. Please correct me if I misunderstood though. > > You are right, but there's no reason not to extend QUIC to do > ephemeral encryption. That wasn't the use case we were thinking about > when we designed it. > > Seems like a useful thing for the IETF to consider.
Agreed - seems like a very useful thing to work on, and would probably help QUIC reach applications and scenarios it otherwise wouldn't be used for. I think that shouldn't stop us trying to fix TCP as well though - indeed the QUIC design docs talk about retrofitting QUIC mechanisms to TCP in the long run. Not sure if that's still the intent. But getting deployment of ephemeral encryption in QUIC is certainly likely to be faster :-) - Mark _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
