4 ms·
The issues with bad guys dropping the sig or delaying it also equally applies equally to ssl during the handshake. But waiting for the sig and the whole page to
by joshAg 14y ago
The issues with bad guys dropping the sig or delaying it also equally applies equally to ssl during the handshake. But waiting for the sig and the whole page to arrive combined wit the size of modern webpages is a problem I hadn't fully considered. I suppose per packet signatures might work to fix the delay issue, but then you'd have to violate abstraction layers and the added cpu time would be completely untenable. At that point you might as well just copy ssl's dh handshake followed by a block cypher but only provide integrity and not privacy, which is stupid. yeah, ok I'm convinced, stupid idea due to practical reasons. just use https with the extra rtt's.
- marshray 14y agoIt's not a stupid idea, it's a problem that smart folks have been banging their head against for a long time now. Take a look at the "TLS Snap Start" proposal to see the lengths to which one must be willing to go to avoid that round trip. But some low-hanging fruit remains. Improvements to clients and servers that increase TLS session resumption rates would help too.