ADCS Drafting (Official Discussion Here)
Posted: 17 Aug 2009, 12:26
I think we need to start by stepping back and deciding exactly what ADCS is meant to achieve.
- Will it be one clear simple standard, or will there be multiple levels for it, like ZLIB has?
- There are a few stages to choose from:
1) Provide encryption over the connection, which may be any or all of: TCP client to hub; TCP client to client; UDP client to client.
2) Stage 1 plus Server authentication. The aim is to verify that the server is who they say they are, and encypt communication.
3) Stage 2 plus Client authentication i.e. mutual authentication. The aim is for both parties to know who each other is, and encrypt communication.
There may be other variations? The choice depends on what we want to achieve!
Stage 3 is the one that would bypass the need for password-logon.
If we want to defend against man-in-the-middle attacks, then we need some verification that the remote peer was the actual party providing the encryption key. I believe the only two ways to do this are a) use certificates signed by a trusted certification authority, or b) pre-share the encryption keys. For (a), you would need to sign at least the hub certificate with somebody like Verisign. For (b), the hub could do something like email a certificate to a newly registered user, which the user must add to their certificate list.
I think it would be helpful if people post both what they want to see out of ADCS, AND what other systems have done, along with the specific aims of those systems.
If the aim is simply to encypt the connection, well, that's great, but it only prevents casual observation. If the aim is to create a system of trusted communication, or even authentication, then thought must be given to how the keys should be exchanged between parties, and how the chain of trust should be secured.
I may not know what I'm on about, but somebody needs to pull this discussion back to looking at the purpose, because nobody has told me what exactly that purpose is so far! We can look more closely at feasibility and implementation studies once we have defined the purpose of the system.
- Will it be one clear simple standard, or will there be multiple levels for it, like ZLIB has?
- There are a few stages to choose from:
1) Provide encryption over the connection, which may be any or all of: TCP client to hub; TCP client to client; UDP client to client.
2) Stage 1 plus Server authentication. The aim is to verify that the server is who they say they are, and encypt communication.
3) Stage 2 plus Client authentication i.e. mutual authentication. The aim is for both parties to know who each other is, and encrypt communication.
There may be other variations? The choice depends on what we want to achieve!
Stage 3 is the one that would bypass the need for password-logon.
If we want to defend against man-in-the-middle attacks, then we need some verification that the remote peer was the actual party providing the encryption key. I believe the only two ways to do this are a) use certificates signed by a trusted certification authority, or b) pre-share the encryption keys. For (a), you would need to sign at least the hub certificate with somebody like Verisign. For (b), the hub could do something like email a certificate to a newly registered user, which the user must add to their certificate list.
I think it would be helpful if people post both what they want to see out of ADCS, AND what other systems have done, along with the specific aims of those systems.
If the aim is simply to encypt the connection, well, that's great, but it only prevents casual observation. If the aim is to create a system of trusted communication, or even authentication, then thought must be given to how the keys should be exchanged between parties, and how the chain of trust should be secured.
I may not know what I'm on about, but somebody needs to pull this discussion back to looking at the purpose, because nobody has told me what exactly that purpose is so far! We can look more closely at feasibility and implementation studies once we have defined the purpose of the system.