ADCS Drafting (Official Discussion Here)

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

ADCS Drafting (Official Discussion Here)

Post by darkKlor » 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.

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: ADCS Deadline

Post by Pietry » 17 Aug 2009, 13:16

If the aim is simply to encypt the connection, well, that's great, but it only prevents casual observation
I think it's a pity to implement just encryption because it doesn't help almost at all.
I think your stage 3 is the aim.
which the user must add to their certificate list.
A certificate signed by the hub? Or signed by the same CA.
In the first case ,the user needs to have multiple certificates and use another one for each hub ( each certificate could have the same key though ), in the second case the user has only one independent certificate, created by the same CA and no need for exchange.
Just someone

Toast

Re: ADCS Deadline

Post by Toast » 17 Aug 2009, 13:32

For whatever its worth since this thread is moving slow
[09-08-17][14:35:50] <arnetheduck> .
[09-08-17][14:36:43] <Toast> .
[09-08-17][14:36:57] <Toast> arne > http://www.adcportal.com/forums/viewtop ... f=10&t=558
[09-08-17][14:37:56] <darkKlor> yea.. say stuff..
[09-08-17][14:41:54] <arnetheduck> darkKlor, that was one of the wisest comments I've seen so far in the whole adcs debate
[09-08-17][14:42:24] <darkKlor> heh.. yeah i've had no idea wtf is going on lol
[09-08-17][14:42:57] <arnetheduck> it does usually make sense to know what you want to do before deciding how to do it
[09-08-17][14:43:02] <Toast> no one seems to do so thats probly a good idea to have an open discussion about it
[09-08-17][14:43:23] <Toast> what is it that adcs is supposed to be doing in the future
[09-08-17][14:43:26] <arnetheduck> heh, although the other way around can be more fun...
[09-08-17][14:45:00] <darkKlor> not if you're going for the whole community consensus thing.. we'll just end up with lots of incompatible implementations and ADCS doesn't seem to have gone anywhere since last november, that i can tell
[09-08-17][14:46:05] <Toast> it hasnt
[09-08-17][14:46:10] <Toast> Pietry had an idea
[09-08-17][14:46:15] <Toast> but it got shot down
[09-08-17][14:46:23] <Toast> since then its been dead
[09-08-17][14:46:40] <Toast> so lets hope someone takes thumbs outta asses and gets typing
[09-08-17][14:46:46] <Toast> perhaps there can be progress then
[09-08-17][14:47:19] <darkKlor> mmm.. and you keep saying it's a priority.. but i dont get why, because i dont know what it is achieving. you can't prioritise the undefined :S
[09-08-17][14:47:53] <Toast> a draft is a priority since its so wanted in the community
[09-08-17][14:48:18] <Toast> the early simple implementations thats in softs is just an start
[09-08-17][14:48:36] <Toast> still missing features like adding users to trusted users
[09-08-17][14:48:50] <darkKlor> but.. what is wanted by the community? lol. encryption, encryption with server authentication, or encryption with mutual authentication?
[09-08-17][14:48:58] <Toast> TLS could do so much more then it does now
[09-08-17][14:49:03] <Toast> thats my point
[09-08-17][14:49:36] <arnetheduck> it's wanted so that it will be possible to put a tag "offers encryption" on the homepage mainly
[09-08-17][14:49:53] <arnetheduck> it's more politics than technical need
[09-08-17][14:50:27] <darkKlor> TLS barely does ANYTHING if the certificates are self-signed. you have encrypted connections, but don't know whose on the other end of that connection. anybody can self-sign a certificate, so self-signed certs can be faked without some trusted authority
[09-08-17][14:51:08] <Toast> darkklor dont u think the CA idea has been discussed +
[09-08-17][14:51:16] <Toast> im all for using real certs
[09-08-17][14:51:28] <Toast> but i dont think that anyone is willing to pay
[09-08-17][14:51:47] <Toast> and the setting up a CA just for DC to sign cert was viewed as flawed idea
[09-08-17][14:51:53] <Toast> so that was out of the question
[09-08-17][14:51:57] <darkKlor> and there's the rub
[09-08-17][14:52:13] <Toast> basicly im saying if its just a simple way to encrypt the protcol and nothing more
[09-08-17][14:52:22] <Toast> then just post that in the draft
[09-08-17][14:52:35] <Toast> and remove all the bs with untrusted blah blah
[09-08-17][14:52:49] <Toast> honest opinion
[09-08-17][14:53:12] <Toast> but it could do more then its doing atm thats all im saying
[09-08-17][14:53:23] <Toast> what it should do in the end thats up to all of these guys in here
[09-08-17][14:53:37] <Toast> just wanting to move the extension idea to draft
[09-08-17][14:53:40] <Toast> thats all
[09-08-17][14:53:42] <darkKlor> mm.. anyway.. keep talkin, but i've gotta sleep.. gotta be up for work in 7 hours

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: ADCS Deadline

Post by Quicksilver » 17 Aug 2009, 21:55

well my 2 cents..

Don't overspecify ADCS ...

so my recommendations for spec..

TLSv1 as a must no SSL (later versions of TLS may be harder to support due to libs not available to all languages)

Prefer DH keyexchange .. but not enforece it ... also due to problems that some languages might not support them well or may not be compatible with DH of OpenSSl or whats the lib called due to not allowing large enough kley lenghts.. plain RSA is good enough... we are afterall not totally paranoid

Recommend to not use MD5 and RC4 algorithms as being not secure enough (but don't enforce it as some implementations might not allow so much settings in )

well thats about it...

I don't like the fingerprint extension Apex I think was it did.. with adding fingerprint to hubaddress for added security...
I just see that the security gain is not worth the trouble it might produce if your cert in the hub ever changed...
I would rather prefer in clients a well putty/ssh like behaviour... showing the finger print (the first time) when ever it has changed and let the user know about the change. (actually may be hiding it the first time would probably be better otherwise the behaviour of just clicking yes becomes to common.. same problem with SSL and browsers..)

so thats my Byte of input..

cologic
Junior Member
Posts: 41
Joined: 21 Jul 2009, 19:34

Re: ADCS Deadline

Post by cologic » 18 Aug 2009, 08:05

Quicksilver wrote:TLSv1 as a must no SSL (later versions of TLS may be harder to support due to libs not available to all languages)

Prefer DH keyexchange .. but not enforece it ... also due to problems that some languages might not support them well or may not be compatible with DH of OpenSSl or whats the lib called due to not allowing large enough kley lenghts.. plain RSA is good enough... we are afterall not totally paranoid

Recommend to not use MD5 and RC4 algorithms as being not secure enough (but don't enforce it as some implementations might not allow so much settings in )
If you want to disallow SSL (even SSLv3?) then there is no reason to allow RC4 or MD5: TLS v1.0, TLS v1.1, and TLS v1.2 require, respectively, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_RSA_WITH_AES_128_CBC_SHA. Software which claims to implement TLS of any version must implement at least either 3DES or AES with SHA1, obviating the need for RC4 or MD5. Since RC4 is less secure than either 3DES or AES; and MD5 is less secure than SHA1; then neither the older hash nor cipher needs nor should be supported by software which aims merely to implement TLS.

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: ADCS Deadline

Post by darkKlor » 18 Aug 2009, 08:22

purpose before algorithms people... define the purpose!

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: ADCS Drafting (Official Discussion Here)

Post by Quicksilver » 18 Aug 2009, 12:51

Purpose is making detection of protocol a bit harder (encryption can't prevent what protocol is being in use though some older ISPs may be fooled) and therefore make ISPs unable to throttle the protcol.

Secondary purpose is to make it harder for outside adversaries to detect what is going on in the hub.

Tertiary purpose for me is that it makes it harder to spy PMs for Hubowners if the software doesn't support it.... anyone can start wireshark.. though not anyone can snoop into the ram of an app.



@cologic.. I know that TLS will support better Algorithms by default I rather meant that simpler algorithms may be allowed because I feared that some implementations may provide MD5 and RC4 with TLS but not allow user to disable them.

About SSLv3 not allowed ... I am first against multiple protcols for unneded complexity.. and I fear with SSLv3 we might automatically get SSLv2 into the boat due to fallback mode to SSLv2 specivied in SSLv3.

cologic
Junior Member
Posts: 41
Joined: 21 Jul 2009, 19:34

Re: ADCS Drafting (Official Discussion Here)

Post by cologic » 18 Aug 2009, 14:53

Quicksilver wrote:@cologic.. I know that TLS will support better Algorithms by default I rather meant that simpler algorithms may be allowed because I feared that some implementations may provide MD5 and RC4 with TLS but not allow user to disable them.

About SSLv3 not allowed ... I am first against multiple protcols for unneded complexity.. and I fear with SSLv3 we might automatically get SSLv2 into the boat due to fallback mode to SSLv2 specivied in SSLv3.
Alright, no objections about not allowing SSLv3, and I basically agree with your reasoning. One slight concern is whether stunnel or some functionally equivalent program (socat has a TLS mode I haven't tried but it looks competent, if not as full-featured with respect to SSL/TLS configurations as stunnel) supports TLS.

Also - "TLS will support better algorithms by default" isn't strong enough. A conforming TLS implementation must support those ciphersuites, so there's no reason to use anything less secure, such as RC4 or MD5. If software only supports those two, then it's not actually implementing TLS.

Finally, certificates and suchlike are essential to avoid MITM attacks, but many useful threat models exist with only passive adversaries (Eve, not Mallory). For example, I've seen no credible allegations that national spy agencies modify traffic on a large scale, but simply monitor it. Such a threat cannot present a MITM attack and therefore even encryption without a pre-existing, out-of-band trust relationship suffices to defend against it. Indeed, one of my goals with encryption in ADC is partially political: as a general principle, as much internet traffic as feasible should be encrypted by default with secure algorithms, simply to establish it as more of a norm and less inherently suspicious.

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: ADCS Drafting (Official Discussion Here)

Post by Quicksilver » 18 Aug 2009, 23:43

I am not saying that software only supports those two algs.

I am saying that software additionally may support those older algs.. which might result in them being choosen..

Point is users should disable these algs though implementation might not allow that... also its not given that implementation will allways choose what algorithm combination is most secure i.e. not choose one of the more secure algorithm combinations TLS has implemented as a must.

en_dator
Member
Posts: 72
Joined: 01 Apr 2008, 19:24

Re: ADCS Drafting (Official Discussion Here)

Post by en_dator » 19 Aug 2009, 19:34

darkKlor wrote: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.
I agree that first thing is to decide what adcs is meant to do,
and so I give my opinion.

This really isnt three things, this is one thing with two possible additions. I.e.

The spec for adcs should define how encrytion is set up, and define a minimum level of encryption (the ssl stuff ;) )
Setup for client-hub communication as well as client-client communication (do they even need to be different?)

Thats all. (imho)

The other issue is about how certs are distributed/verified and is a completely different thing that probably should not be part of the adcs specification as it really has nothing to do with it.

However, I think its very important to also discuss a method for these things as all users will benefit if methods are similar in clients and hubs.

Locked