darkKlor wrote:Attached is a draft of an ADCS proposal. Comments are welcome!
I have quite a few. First of all thanks for taking your time to write a draft, that being said - there are so many issues I disagree strongly on in this current spec, and that are plainly omitted from the spec. But, since I haven't written a spec myself, I'd rather comment on what is written here.
Rationale
The hub registration method is weak i.e. password-based registration involves the transmission of passwords to the server in plain-text.
The current ADC spec does not address this issue at all, so it is therefore inaccurate to claim that the registration method is weak.
The hub authentication method is weak i.e. the hub cannot verify that a connection has not been hijacked in the establishment phase, or initiated by a client impersonating the registered user.
This reflects directly back to point #2 of the bullet list which addresses MITM attacks. Yes, as a concequence of a MITM a transparent proxy can for instance hijack a session after authentication. The authentication is not to blame for that though, and it does not indicate that it is weak - rather the opposite - it is strong since an attacker must do an active injection attack instead of a simple replay attack.
Connection Approach
"Separate port" and "Upgrade negotiation" is nice, but you totally miss the obvious 3rd option. Simply redirect to an adcs:// address.
There is no technical need for having a "separate port" to run TLS on - as such I don't see a point in overspecifying this point as it boils down to
implementation details.
That being said, "Upgrade negotiation" is very much vulnerable to downgrade attacks by a proxy simply eliminating "ADCS" as a viable feature.
I agree with cologic here, either you do ADCS or you don't.
Paranoid users need to use the "adcs://" prefix to signal to the client that an encrypted connection is to be expected here, nothing less is acceptable.
Situational Considerations
mutial authentication provides a higher level of assurance as to the identity of the parties.
Yes, that
can be true.
Server authentication - only server is authenticated via certificate.
And a server can authenticate a user based on a shared secret - a password comes to mind.
Isn't that still mutual authentication?
...but also allow a hub owner to generate a self-signed certificate
Yes, I am all for self-signed certificates. But how are they verified?
Verification of Self-Signed Server Certificates
A-ha!
When a hub address is given to a user, it is appended with a cryptographic hash of the server's public key
KeyPrint as described here does not solve any issue itself, it now generates a couple of new issues:
- First of all: Can you trust the link you got?
- If the link you got contains a keyprint using an unsupported hash?
- If the link you got contains an invalid keyprint - what are the potential recovery strategies?
- If the link you got does not contain a keyprint - is it invalid, considered insecure, not secure, or dangerous?
As far as I can see, only the first issue is discussed in the Keyprint spec.
I think we can solve this problem better and simpler by aligning closer to the SSH model of the first "leap of faith" when connecting,
and then storing the public key for future sessions.
But keep in mind, we need to know what assets we are trying to protect by doing such an excersise.
Mutual authentication
This section made me jump!
the hub generates a certificate and sends it to the user via a new ADC protocol message (e.g. CRT, for certificate)
WTF - Basic crypto NO NO!
You don't own your own certificate any more. A more secure way to do it is for the client to generate a public key and a private key,
the public key (or "certificate") is transmitted to the hub (no transfer security needed), the hub signs the certificate and transmits
back the signature of the public key (no transfer security needed here either).
A new issues now is signing denial of service, since signing is a moderately heavy operation.
That's it for now.