Adam Langley

Few sources that claim that TSL is almost free today.

https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

https://istlsfastyet.com/

http://blog.codinghorror.com/should-all-web-traffic-be-encrypted/

Although you may argue that if you are a CDN, encryption can be a significant portion of your costs.

Also, Jeff Atwood writes following:

> Of course, there's no reason to encrypt traffic for anonymous, not-logged-in users, and Twitter doesn't. You get a plain old HTTP connection until you log in, at which point they automatically switch to HTTPS encryption. Makes sense.

Today we know that it is no longer a valid point. TOR users can be deanonimized by injecting traffic into plain HTTP connections. Upgrade to HTTPS seems to be fixing that. So we really should use HTTPS by default and HTTP only in very well articulated cases.

> I think it's missing a verb?

Gervase may have meant to write "Currently, it is not permitted by the CAB Forum Baseline Requirements to [remove] revocation pointers out of a cert, ever."

For more details, see Appendix B (2) b of the CAB Forum's Baseline Requirements [0]. Per the document, a CRL distribution point MUST always be provided.

Currently, certificate revocation is ineffective, prone to failure and a potential privacy risk. Adam Langley has described the issues comprehensibly and at length in a series [1, 2, 3] of insightful posts on ImperialViolet.

[0] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_9.pdf

[1] https://www.imperialviolet.org/2011/03/18/revocation.html

[2] https://www.imperialviolet.org/2014/04/19/revchecking.html

[3] https://www.imperialviolet.org/2014/04/29/revocationagain.html

> Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone.

Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.

Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:

https://www.imperialviolet.org/2019/01/01/zkattestation.html

Why to use security keys: http://fc16.ifca.ai/preproceedings/25_Lang.pdf
(updated from my earlier link to the yubico article about that paper: https://www.yubico.com/2016/02/use-of-fido-u2f-security-keys-focus-of-2-year-google-study/ )

Review of security keys by Adam Langley:

https://www.imperialviolet.org/2017/08/13/securitykeys.html

and testing security keys:

https://www.imperialviolet.org/2017/10/08/securitykeytest.html

tl;dr: Yubikeys are $$ but really solid for USB and NFC; the Feitian is probably the best option for Bluetooth but YMMV there. Those are what I personally use.

(Note that Yubico recently announced a problem with their RSA key generation, which they're fixing, but that bug does not affect the security of the device when used as a FIDO authenticator as it is for Google/Github/Dropbox/Vanguard/etc.)

What I would really like is a straightforward migration guide for those of us already using the FIDO U2F JS API, to help people migrate in a backwards-compatible way from the old, poorly-documented stuff to the new, currently poorly-documented but very soon better-supported stuff.

So far, https://www.imperialviolet.org/2018/03/27/webauthn.html is the closest; it’s good, but I’d love to have something with more straightforward instructions—“so you currently use U2F? Change this to this, that to that, do this to maintain compatibility and you’re roughly done”. We’ll figure it out for FastMail, but if the migration is straightforward and well-documented it’ll help all the web services out there to move sooner rather than later, which as a user I would very much like.

This might be a bit off topic but I wonder why the vulnerability has been patched this way:

if (!access_ok(VERIFY_WRITE, infop, sizeof(*infop)))
goto Efault;

Why doesn’t the if use curly brackets? I thought it has been established that it is best practices to always use curly brackets even if they are explicit, especially after Apple's infamous goto bug[1].

Secondly, why does it use goto at all? I thought it has also been established not to use goto unless it is the only performant solution (and performance is important in that case). Sure Efault with probably kill the program but wouldn’t it still be better to use a function call considering that the desired resolution should be the same?

[1]: https://www.imperialviolet.org/2014/02/22/applebug.html