> Is this, for example, subject to playback attacks?
Yes, it is (there's no server nonce). It's designed that way because it eliminates latency. This is a low security, low cost scheme after all. It's also vulnerable to truncation attacks and, until I implement authenticators, blind corruption.
You have a fair point there, but you would be surprised how many more people will sit through the video than would read a page explaining the same.
I don't much like the video either, but I did it for the reason above. I guessed that people smart enough to get frustrated with it probably didn't need it.
It's such a good idea that I plan to do it. Enums for it etc already exist in the code, it's just a question of writing browser support.
Disadvantages are the additional RTT and, probably, more expensive cipher suites.
Another advantage is that some firewalls are more friendly to outbound 443.
> Is this, for example, subject to playback attacks?
Yes, it is (there's no server nonce). It's designed that way because it eliminates latency. This is a low security, low cost scheme after all. It's also vulnerable to truncation attacks and, until I implement authenticators, blind corruption.
It didn't escape me - I didn't write the subject line. To be clear: this has nothing to do with Google.
You have a fair point there, but you would be surprised how many more people will sit through the video than would read a page explaining the same. I don't much like the video either, but I did it for the reason above. I guessed that people smart enough to get frustrated with it probably didn't need it.
NOT Google's, just their code hosting. Title says it all.
It's such a good idea that I plan to do it. Enums for it etc already exist in the code, it's just a question of writing browser support. Disadvantages are the additional RTT and, probably, more expensive cipher suites. Another advantage is that some firewalls are more friendly to outbound 443.