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

Re: ADCS Drafting (Official Discussion Here)

Post by darkKlor » 03 Oct 2009, 23:37

darkKlor wrote:Another comment on using a single certificate for all hubs a user connects to (this applies to CIDs just the same): it is an information disclosure vulnerability, because you can reasonably expect that a public key only exists once. If you see a user on two hubs, with two different nicknames and IP's (e.g. they connect to one hub via a proxy, but not the other hub), but they have a common public key (or CID), then you know them to be the same user.

If, for registered users, the hub issues the user with a hub-signed certificate, specifically for that hub, and (borrowing from DJ_Offset's suggestions) the registered user's CID is a hash of that certificate (not the public key, because anyone can get that, potentially), then the hub knows who the user is, and their registered CID on that hub will not match their CID on another hub (registered or otherwise).
I should point out that I am aware of the following (http://www.adcportal.com/forums/viewtop ... f=33&t=425):
Pietry wrote:On of the NMDC flaws that is addressed by the CID / PID pair is the following: One could not identify a certain fellow user on different hubs. This way, the same user could leech from you on every hub you were both connected. Also, you could have a PM session with the same user on every hub as well.
Nobody seems to implement a PM per user feature, it's all per hub... but anyway... The purpose of using a hash of the hub-specific certificate as the CID is to protect the user's identity (in a secure hub) from being revealed in another hub (secure or otherwise; it has different ownership). There is no issue for downloading because clients use SCH to look for matching hashes on each hub. It is true that you cannot tell if you are downloading off exactly the same person (maybe you really like their stuff), unless you see both the file lists look the same of course; however, once clients finally support multiple file lists, you will be incapable of telling that it is the same person (without human interaction).

The other thread I referenced is worth taking a look at too, DJ_Offset raises many valid points about PID/CIDs.

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

Re: ADCS Drafting (Official Discussion Here)

Post by darkKlor » 04 Oct 2009, 14:02

An updated draft proposal is attached. It includes a new section entitled Issues and Models which discusses Trust Models and Hybrid Hubs. There are minor changes since the last draft, based on some of the feedback received in this forum (there's room for more alterations, I just haven't done it). Also, an incomplete section on client-to-client connections is in this draft, but you shouldn't look at that :P
Attachments
ADCS Spec Draft #03.pdf
ADCS Proposal - Update
(247.48 KiB) Downloaded 289 times

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

Re: ADCS Drafting (Official Discussion Here)

Post by cologic » 04 Oct 2009, 16:38

darkKlor wrote:An updated draft proposal is attached. It includes a new section entitled Issues and Models which discusses Trust Models and Hybrid Hubs. There are minor changes since the last draft, based on some of the feedback received in this forum (there's room for more alterations, I just haven't done it). Also, an incomplete section on client-to-client connections is in this draft, but you shouldn't look at that :P
1) According to Crypto++ benchmarks, even the slowest AES mode (which TLS doesn't specify as an option) is 61MiB/s. Other modes are 102MiB/s, on a somewhat old processor (an "Intel Core 2 1.83 GHz processor under Windows Vista in 32-bit mode"). This, granted, is an upper bound which implies 100% CPU usage and nothing remaining for other tasks (such as, say, running a hub), but suggests that for all but the largest hubs symmetric cryptography is cheap on modern machines. This doesn't directly address the specification that much, but I wouldn't necessarily take it as axiomatic that "it is therefore important to note that an ADCS-only hub will be constrained to a a smaller size than a non-ADCS hub running on the same hardware" - for many, probably most, hubs the system bottleneck would appear to be the network rather than the crypto. That whole paragraph, in fact, is an exercise in claiming either the trivial but uninteresting or the nontrivial but unsupported. The latter, especially, do not belong in a specification.

2) The prominent placement of the hybrid hub discussion in the main text is arguably inappropriate for a specification. If one views the sequence of draft specifications as a basis for discussion, it makes sense, but at some point if not only "it is proposed that" but such a model ends up "disallowed by the protocol", then the entire "Hybrid Hubs"/"Why Not Hybrid Hubs?" section should at most be an appendix, footnote, or of other such tangential concern. Indeed, such an appendix already exists and it's partly redundant with the two aforementioned sections of the main text.

3) See my and jvk's comments about "upward negotiation". They still apply, and it's strange seeing them right after the spec draft proposes disallowing the only possible use case for them aside them the very temporary-and-replaceable-by-a-standalone-redirect-hub existing hub migration issue. Your appendix I also proposes what amounts to a false dichotomy. There are other ways of handling the transition, which have been discussed, and which ameliorate the issues you seem concerned about with regard to any perceived need for upward negotiation. Other inconsistencies also exist now: the main text proposes exactly to "exclude Z from the hub" and later treats it as a strange hypothetical.

4) The IETF suggests how to use various words in specifications. This would be an appropriate document in which to use them and would introduce precision and consistency.

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

Re: ADCS Drafting (Official Discussion Here)

Post by darkKlor » 05 Oct 2009, 00:21

@cologic:
1) It should be noted that CPU's have been gaining hardware instructions to enhance encryption gradually over the years. AES in particular is the focus of a new set of instructions coming to x86 processors in the next couple years. Regardless, the network is still a hardware resource, and I treat it as such. Also, I think many hub owners would be unimpressed if they had to have a computer solely to run a hub, because it used 100% of their CPU :P

2) Don't look at the document as a technical specification... being a proposal, it discusses relevant issues prior to offering an implementation. The document structure does have room for improvement.

I'm not there yet, but I wanted to build up a set of issues and their implications as discussion points. The conflicting goals people have are pointing in different directions and there will be situations where the goals of one group will make approaches proposed by another impossible (or harder than you'd like).

3) I do believe I said I did not alter this section. Upward negotiation is only for migration from ADC to ADCS, and this may occur in some hubs next year, or in others in 5 or 10 years. This approach would differ from the hybrid hub approach in that a hybrid hub allows non-ADCS clients, whereras a hub using upward negotiation is an ADCS-only hub that uses ADC's feature negotiation to determine if ADCS is available on a client, and if it is no, sends the client an IMSG which may inform them why they are revoked, how to get a new client, where to contact the hub owner etc.

In regards to these 'other ways' to handle the transition, write them up properly and post them as a section on ADCS migration?

Also, note that I got this dichotomy from here: http://www.gnu.org/software/gnutls/manu ... -protocols.

4) Hahahahahahaha. I'm well aware of these words... I used them in a document here: http://www.adcportal.com/forums/viewtop ... f=55&t=557. However, people seem far more concerned about ADCS (without actually writing much down) than making the ADC protocol more like an IETF spec. As I've said previously, my aim for this ADCS document is not to be a true technical specification, because there are issues which need to be discussed before such a document is worth producing.

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

Re: ADCS Drafting (Official Discussion Here)

Post by darkKlor » 03 Nov 2009, 12:27

Since this appears to be dead (no progress in a month etc), I for one have no plans to implement it. Hello dustbin.

Toast

Re: ADCS Drafting (Official Discussion Here)

Post by Toast » 03 Nov 2009, 14:15

well my vote goes as adc0 is now push it as that since there isnt any progress at all kinda sad since we want to push ADC on people

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

Re: ADCS Drafting (Official Discussion Here)

Post by darkKlor » 03 Nov 2009, 16:20

I'm not sure there's even a proper definition of what it is now. I will take a look at that Bouncy Castle API on the weekend since there are both Java and C# modules. However, there are unresolved issues with ADCS that leave me happy to ignore it e.g. What happens to all the UDP messages we've been adding? Can you even do hole-punching with ADCS the way it works at present? I'm not sure...

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

Re: ADCS Drafting (Official Discussion Here)

Post by cologic » 09 Dec 2009, 06:11

Quick note so it doesn't get lost: any ADC extension should be secure against the recently discovered TLS renegotiation prefix-only-MITM vulnerability.
Vulnerability requirements
The preconditions for a TLS or SSLv3 connection to be vulnerable are
1. The server acknowledges and accepts full TLS renegotiations in the middle of a
connection and after the initial handshake
and
2. The server assumes that both TLS sessions were negotiated with the same client
and
3. The server treats both sessions as one and merges them at the application layer

As such this vulnerability might not been seen as a vulnerability in TLS but the as the bad choice
to merge two different requests together by the endpoint.

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

Re: ADCS Drafting (Official Discussion Here)

Post by Quicksilver » 07 Jan 2010, 21:09

as an enhancement to ADC0 I would like to propose the foillowing: (encryption for UDP)

http://pastebin.com/f7a1a4896

jucy in version 0.82 will contain a testimplementation ... (the development client I am using already supports it.. so in DevPrivate you could test against it if oyu want..)

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

Re: ADCS Drafting (Official Discussion Here)

Post by Quicksilver » 26 Jan 2010, 21:35

proposal above has too many flaws...
for ongoing discussion .. new proposal is here:
http://www.adcportal.com/forums/viewtop ... f=18&t=625

Locked