Designing a simpler alternative to TLS
Adnan Maolood
me at adnano.co
Sat Nov 21 18:52:44 GMT 2020
On Sat Nov 21, 2020 at 3:30 AM EST, Sean Conner wrote:
> First off, the specification does not give enough detail to actually
> implement the protocol. There's nothing about the wire format, and I had
> to
> check the implementation to see you are using BARE message Encoding [1],
> yet
> *another* encoding scheme like JSON, BSON, CBOR, MsgPack, CapnProto,
> Protobuf, etc. etc. [2]
The specification is still a very rough draft.
> Second, TLS libraries come with the cryptographic primitives required,
> and
> yes, there is negotiation that happens, but that's because as
> cryptographic
> primitives are broken, new ones can be slotted in and used. Here, if
> (and
> it could happen) Ed25519 is "broken" then what? At least with several
> supported primitives, the protocol can still be used while the broken
> primitive is removed.
If Ed25519 is broken, then it would be considered insecure, and a new
KeyShare message could be added in a backwards-compatible way.
> Even so, anyone attempting to implement Ed25519 is a fool for the
> pitfalls
> are subtle and *will* be exploited; I'm guessing you are assuming the
> use of
> libsodium (or God help you, libnacl) with this protocol, right?
Yes, I assume that you would not implement the cryptography yourself.
> I'm no crytographic expert, but I don't see how this protocol prevents
> MITM attacks; the details in the key share (section 2.2.1) don't go into
> enough detail for my liking. How do I know I'm talking to the server in
> question, and not being invisibly proxied by Eve or Mal?
MITM protection is covered in section 2.2.4. Essentially, the server
signs the key share messages with its certificate private key, and the
client verifies this signature.
> And how does each
> side determine an insecure key share? What exactly goes over the wire?
A key share would be insecure if it is later "broken" as you said.
I don't expect anyone to use this instead of TLS, it is mostly just for
educational purposes and to gather ideas of what a simpler TLS could
look like.
More information about the Gemini
mailing list