asd2r23dasd

Hey, this is largely off-topic but worth a punt: do you have any info on when AWS IoT (maybe other AWS services as well?) will move off the dependency on the Verisign RSA/SHA-1 CA? I'd love to get a certificate chain that was ECDSA or RSA sigs only (and would also love to be able to turn off SHA-1 for the obvious reason).

Ah cheers for the link. Yeah a proof at the level of abstraction up from a single pattern would be lovely. I don't really have 'concerns' as such: it's just if your risk profile is the thing that has kicked you away from TLS towards Noise then you need a good justification (notwithstanding, a proof of security for a new AKE should really be par for the course).

IMO the interesting aspect with the development of Noise will be if it can avoid bloat. From the mailing list I can see that there's solid awareness of that risk (would assume Trevor is aware anyway), but it will be interesting to see how the simplicity of pattern API will handle things like signatures, when they're inevitably added. I see at least one Noise-using project has already made the leap on that front.

I would definitely agree, yeah. Notwithstanding the legacy protocol core, Noise has great potential to allow people to step away from the asn1, X509 etc TLS cruft.

Comparing between those two options is a question of appetite for risk, your threat model, and the level of competency you have available. On the latter note, _at the moment_, I think the subset of people who are capable of taking advantage of Noise would be largely similar to the same subset you could safely task with designing and implementing a custom AKE+messaging protocol from scratch anyway. I think the level of competency you need available is on the very far end of the spectrum. Edit: and on the risk point, even if the library has been eyeballed less, at least you know with mbedTLS that if a bug drops you'll get a patch pretty quickly. If you goof up your Noise impl you're on your tod.

I don't think you can deem mbedTLS too risky on one hand, and then on the other recommend Noise, with it's slew of unfinished and largely unverified libraries. Outside of the WireGuard RHUL effort for a specific 'pattern' AFAIK the Noise core hasn't really seen any formal analysis either. Commoditizing the DH operation means you can build an enormous amount of AKEs, and even people like Trevor Perrin can make mistakes there.

Noise is potentially very interesting, particularly for the embedded space, but it'll be a while before it's safe to use.

When you're that small it really requires more context. What are you trying to do?

I've deployed TLS in 50 KiB flash and 6 Kb RAM. But I could rely on hardware support for some public key operations and could pick a single ciphersuite, and controlled the server end as well.

The boring answer is that you'll need to identify the set of primitives you need and then find a library that matches. I can't think of any single primitive that would break that budget, so it'll depend on how many you need!

Ha yeah, composition was a bad choice of word.

Maybe an quick example off the top of my head would be: you know you need to authenticate and perhaps additionally 'encrypt' something --- for say a software update, fancy over-Bluetooth authentication scheme etc.

You need to pick: symmetric or asymmetric schemes? Auth then encrypt? What does replay of an old signature or MAC mean for your system? Key usage limitations? Key re-use? Quite a few ways you can err where the choice of e.g Ed25519 over P-256 ECDSA pales in comparison.

Or in other words: most people are trying to build a secure system, and where security is only achieved by the combination of the protocols, primitives used.

W.r.t TLS, yeah, bake in default configs as part of an environment where you can, although there'll always be plenty of people developing directly against the software API, and compatibility issues will typically play a part.

I think the most useful parts of the document are the 'really try hard to use TLS for any comms problem' or 'try to use Amazon's key management for encryption' answers, and pointers to good libraries.

Beyond that: developers aren't normally tasked with building systems out of cryptographic primitives. Those that do are typically (hopefully!) experienced enough to pick a solid primitive.

Those who need to look-up which primitive to use need to know that the security of the final system is primarily going to pass or fail on the _composition_ of those primitives rather than the particular choices.

What would be really cool would be a document that takes common use cases and describes how best to build in the cryptographic aspects of the security. Edit: e.g. a good list of OpenSSL ciphersuites and SSL_CTX_config() blah calls for server auth and mutual auth is probably the biggest bang for buck you can get.

I don't want to come across as critical of the effort or correctness --- but I do I think people really need to hear the danger klaxon when they're doing more than just editing a TLS configuration file. Composition of primitives is really hard.

Advice for that kind of problem typically requires a lot more context, e.g.: * You need to do symmetric crypto between two MCUs, where only one has an RNG; * You need to do symmetric crypto with no RNG; * You can't rely on your MCU safely storing state / unreliable transports.

Cryptography and libraries/standards are gradually building towards a world in which higher-and-higher level abstractions let inexperienced web/high-level application developers build safe systems. The same isn't really true for the lower-end of the embedded space, and consequently you can't really produce an equivalent set of (reasonable) guidelines like the ones linked.

I agree that OpenSSL is likely the most robust library out there, and if you're talking about provisioning your web server / doing some https from a high-level language then it's definitely the sane choice. (fwiw, I had some work looking at a BouncyCastle TLS server and...eek)

The one counter-example is the embedded space, particularly where code addition/modification for hardware integration is required. Here OpenSSL's footprint and APIs are a tad unwieldy compared to some alternatives.

Basically I just wanted to give mbedTLS a shout-out as, IMO, the clear winner in that particular space.