API tools faq
paste
Advertisement
Guest User

Untitled

a guest
Feb 10th, 2019
166
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 15.42 KB | None | 0 0
raw download clone embed print report
  1. [sön:16:30:49] <Dexo> Hi Pretorian!
  2.  
  3. As you meantion, it's not quire clear what the process is for proposing items for the meeting.
  4.  
  5. I'd like to include a discussion about ALPN proposal:
  6. https://github.com/direct-connect/protocol/blob/proposal-alpn/001-alpn.md
  7. [sön:16:31:51] <Pretorian> Hey
  8. [sön:16:32:00] <Pretorian> So, first of all, those items are Crise's, not mine.
  9. [sön:16:32:10] <Pretorian> Well, the bylaws change is mine
  10. [sön:16:32:31] <Pretorian> Second of all, I think it's great that you are interested in ADC and want to do stuff!
  11. [sön:16:32:45] <Pretorian> I have not read ALPN, but will do so shortly.
  12. [sön:16:33:02] <Dexo> Thanks :)
  13. [sön:16:33:30] <Pretorian> Regarding the meeting items, it is typically that you either submit through e-mail or you just state things at the meeting.
  14. [sön:16:33:59] <Pretorian> The meeting isn't for specifically whether to include ADC features or proposals, that's done separately.
  15. [sön:16:34:16] <Pretorian> Do you have a working implementation of ALPN?
  16. [sön:16:34:55] <Pretorian> Do you want to have a discussion on the protocol description (i.e. is it subject to change) or do you just want it included in the main extensions list?
  17. [sön:16:35:25] <Pretorian> Given the lack of participation on my part, I guess I could just include it (after reading it) in the main extensions list.
  18. [sön:16:35:58] <Pretorian> But yeah, there (also) isn't really a clear process on how to get things added to the extensions list etc, beyond, well, poking me
  19. [sön:16:36:07] <Dexo> Yes, we have a hub prototype that implements it, and a client library that supports it.
  20. [sön:16:37:37] <Dexo> And yes, ideally I'd like to open a discussion about it to eventually make a standard feature for hubs/clients.
  21. Because it's not really an extension in the sense of ADC entensions.
  22. [sön:16:38:25] <Pretorian> "NMDC protocol defines no standard URI scheme for signalling a TLS support on the connection, and has no support for negotiating TLS for client-hub connection during $Support handshake."
  23. [sön:16:38:33] <Pretorian> People are usign dchubs:// now?
  24. [sön:16:38:37] <Pretorian> no*?
  25. [sön:16:39:44] <Dexo> Not sure - haven't seen those in the wild.
  26. [sön:16:39:56] <Pretorian> Hm, ok.
  27. [sön:16:40:13] <Pretorian> Or maybe they were using nmdcs:// but that's not the standard NMDC URI
  28. [sön:16:40:25] <Pretorian> (dchub: is)
  29. [sön:16:41:08] <Kcchouette> hello Pretorian
  30. [sön:16:41:14] <Pretorian> Hey
  31. [sön:16:41:22] <Dexo> Yes, at least I haven't found any references nor in the spec, nor in the addresses in hublists.
  32. [sön:16:42:08] <Pretorian> Hm, <http://nmdc.sourceforge.net/NMDC.html> does not explicitly state the hub URI
  33. [sön:16:42:20] <Pretorian> However, <http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.5.txt>
  34. [sön:16:42:33] <Pretorian> (Still not submitted to IETF fully)
  35. [sön:16:43:02] <Kcchouette> (hasn't sourceforge been migrated previous year to gitlab?)
  36. [sön:16:43:16] <Kcchouette> (your sourceforge website *)
  37. [sön:16:43:27] <Pretorian> Not all pages, no.
  38. [sön:16:43:31] <Pretorian> Just ADC at the moment I think
  39. [sön:16:43:49] <Kcchouette> ok
  40. [sön:16:43:57] <Pretorian> "ADC clients should set ADCS/0.10 as a protocol for CTM and RCM commands." argh do people still use /0.10? DC++'s fault :(
  41. [sön:16:44:47] <Pretorian> For C-C, why do you need to do anything at all? The issue is who-speaks first, which NMDC and ADC does the same.
  42. [sön:16:45:12] <Pretorian> "if $ConnectToMe then NMDC else ADC"
  43. [sön:16:45:28] <Dexo> Yeah, I've seen /0.10 this in EiskaltDC++, I guess. Can be changed in the proposal, of couse.
  44. [sön:16:45:33] <Pretorian> Or maybe you just want that for completeness?
  45. [sön:16:46:27] <Pretorian> "ADC client should set ADCS/<protocol> as a protocol for CTM and RCM commands." would be my personal preference.
  46. [sön:16:46:29] <Dexo> > For C-C, why do you need to do anything at all?
  47. Protocol auto-detection is not perfect, this why I proposed a more reliable way to detect it without waiting for any kind of handshake.
  48. [sön:16:48:40] <Dexo> The reason to not specify the protocol in CTM is to make it work with older clients. New ones will try to use ALPN, and if it fails they will assume the default protocol.
  49. [sön:16:50:17] <Pretorian> (Commands form NATT would also be applicable here, I presume)
  50. [sön:16:50:40] <Dexo> Sure
  51. [sön:16:52:16] <Pretorian> "The client should add at least nmdc name to ALPN's list of supported protocols. Client is also allowed to include any other supported protocol to the ALPN list, for example adc. The list should be in an order from the most preferred protocol to the least preferred one."
  52. [sön:16:52:23] <Pretorian> This could be a security risk, mind you.
  53. [sön:16:53:04] <Pretorian> Or, hm, maybe I'm thinking of signalling multiple IPs and verifiying which is accurate.
  54. [sön:16:53:55] <Pretorian> Oh, no, there's no token though right?
  55. [sön:16:54:27] <Pretorian> No token in NMDC means ADC fallback with INF TO will/should/could fail
  56. [sön:16:56:18] <Pretorian> There is also ACTM (Advanced Connect To Me) in NMDC, but I'm not too used to it to know how that is different.
  57. [sön:16:56:39] <Pretorian> Ah, right ACTM simulates the token.
  58. [sön:16:57:18] <Pretorian> Basically NMDC -> ADC fallback should only really work iff ACTM is used, if one wish to prese the security aspect.
  59. [sön:16:57:22] <Pretorian> preserve*
  60. [sön:16:58:57] <Pretorian> So, I'm not too well versed with TLS and all the options you can do on it; you add nmdc/adc to a 'list' that is communicated on TLS?
  61. [sön:16:59:49] <Pretorian> If that's all you need to do, why do you need to signal it in $Supports etc?
  62. [sön:17:01:16] <Pretorian> Whoever connects signals nmdc/adc in the TLS list, and the other party will simply know what to use?
  63. [sön:17:02:05] <Pretorian> Beyondy our comment with reliability, I guess...
  64. [sön:17:02:09] <Pretorian> -y
  65. [sön:17:02:20] <Pretorian> err, beyond your*
  66. [sön:17:03:03] <Dexo> > you add nmdc/adc to a 'list' that is communicated on TLS?
  67. Yes, initial TLS hadshake may already include the protocols both parties support. So when the TLS connection is open both parties will already know what protocol to speak to.
  68. [sön:17:03:30] <Dexo> It's not possible to implement this with Supports - it won't allow to switch to ADC, for example.
  69. [sön:17:04:45] <Dexo> Also, we plan to send protocol strings like "nmdc-r1" in ALPN to signal a "fixed" version of NMDC (for example, with UTF8 encoding).
  70. [sön:17:04:47] <Pretorian> Re non-TLS, I think your description is fine -- if others are using this then I think this should be a separate description in each document.
  71. [sön:17:05:57] <Dexo> But you are right about the NMDC -> ADC fallback. But clients somehow connects via plain NMDC, so it may not be an issue on their side.
  72. [sön:17:06:22] <Pretorian> Re HTTPS, why is this needed? To alleviate some simpler implementation for hublists?
  73. [sön:17:06:33] <Pretorian> Vs just using PING.
  74. [sön:17:07:06] <Dexo> Sorry, what do you mean by separate description?
  75. Yes, HTTPS is only to simplify pinger to a single HTTP GET.
  76. [sön:17:07:53] <Dexo> For ADC it may be simmple enough, but you as a hublist developer will need to know the protocol. With HTTPS it's way easier - all programming languages already have packages for this one.
  77. [sön:17:08:01] <Pretorian> Separate description in each NMDC/ADC document, as a description on how to handle detection of incoming connections, as it isn't _really_ relying on ALPN or other extensions.
  78. [sön:17:09:07] <Pretorian> "Implementations should not allow running TLS over TLS." <-- error?
  79. [sön:17:09:26] <Dexo> no, it's intentional
  80. [sön:17:10:16] <Pretorian> What does "not allow running TLS over TLS" mean?
  81. [sön:17:11:19] <Dexo> Assuming the implementation may run autodetection over a plain connection and TLS connection, it may by mistake run TLS detection over TLS. Implementation detail, I guess.
  82. [sön:17:11:42] <Pretorian> Uhh so the text should be "TLS detection over TLS"?
  83. [sön:17:11:56] <Pretorian> Otherwise I don't understand the sentence.
  84. [sön:17:12:11] <Dexo> Right. This is a better wording, thanks.
  85. [sön:17:12:50] <Dexo> May I ask to add those comments inline on the Github?
  86. [sön:17:12:54] <Pretorian> Defintely
  87. [sön:17:13:52] <Dexo> Regarding different documents, I think of the detection a bit differently. I do not really think about NMDC and ADC as separate things. Both are only a transport for some abstract DC protocol.
  88. Because of this I wanted to make a single document defining how clients should handle a connection from other client of DC network, regardless of the protocol. Same for hubs.
  89. [sön:17:14:54] <Pretorian> For HTTPS, I'd suggest to add a description of _why_ someone should implement this over PING. Also, all parameters that could be used in INF/PING should be included here.
  90. [sön:17:15:22] <Pretorian> (Nitpick: always use example.net/example.com when referencing web URIs.)
  91. [sön:17:17:06] <Pretorian> Re different documents, it kinda makes me feel like we should have one broad/abstract protocol document and referencing specific implementations with NMDC/ADC. Good idea you're proposing.
  92. [sön:17:18:53] <Dexo> Exactly :) We have some network topology in mind, some concepts regarding the search, peer identification, etc. This can be an abstract part.
  93. And everything else is a specific implementation by each protocol.
  94. [sön:17:19:14] <Pretorian> Yep
  95. [sön:17:19:54] <Pretorian> Some of that information is broadly on <https://en.wikipedia.org/wiki/Direct_Connect_(protocol)> but it'd be good to have all of that concentrated on a project page at DCNF
  96. [sön:17:20:07] <Dexo> +
  97. [sön:17:22:56] <Crise> What have I missed?
  98. [sön:17:23:26] <Pretorian> :)
  99. [sön:17:23:48] <Pretorian> +history :P
  100. [sön:17:24:51] <provolone> Crise you missed a plate of pasta matriciara and steaks in the oven, and red wine
  101. [sön:17:25:40] <Crise> Pretorian: can't blame me for trying... I was feeling lazy :D
  102. [sön:17:26:33] <provolone> hi Crise
  103. [sön:17:26:37] <Pretorian> So, regarding ALPN, I presume/trust you have a working implementation so I guess the whole 'add nmdc/nmdc to a TLS list and it works' is fine.
  104. [sön:17:27:31] <Pretorian> Hm, just re-reading the document, I may have misread before. Do you use *anything* at all to signal ALNP?
  105. [sön:17:27:40] <Dexo> Yes, we have a hub running, so you may check it out :) The source code is also available.
  106. [sön:17:27:45] <Pretorian> Vs just signalling TLS support in $Supports etc?
  107. [sön:17:28:11] <Dexo> No, because ALPN happens _before_ TLS the connection is opened.
  108. [sön:17:28:28] <Pretorian> Ok, then I think I misinterpreted your document.
  109. [sön:17:28:56] <Pretorian> So, we don't do anything at all to ADC/NMDC themselves?
  110. [sön:17:29:04] <Pretorian> (Except signalling TLS in general)
  111. [sön:17:29:25] <Dexo> No, there only some clarification on when to use it.
  112. [sön:17:29:36] <Pretorian> Ok, I like it.
  113. [sön:17:30:39] <Dexo> The idea is that once it's implemented, we can define ADC-r1 and NMDC-r1 and strictly define how protocol should behave. Not a problem for ADC - it's well-written, but makes a huge difference for NMDC.
  114. [sön:17:31:18] <Pretorian> I think the largest point is that the fallback needs to be discussed/considered more.
  115. [sön:17:31:19] <Dexo> And, it may be an opportunity to fix issues, or promote some existing extension into the standard ADC or NMDC protocol.
  116. [sön:17:31:31] <Dexo> Yes, we are working on it.
  117. [sön:17:31:40] <Pretorian> Mostly the token issue.
  118. [sön:17:32:06] <Dexo> But we need at least one client that will try to implement it, so we know earlier if there are any problem with this approach.
  119. [sön:17:32:07] <Pretorian> If you disallow fallback then it's fine I guess.
  120. [sön:17:32:42] <Pretorian> Issue is that ADC clients should (I think?) disallow connections with invalid tokens.
  121. [sön:17:33:11] <Pretorian> But been a while since I checked whether validaiton should be done or not.
  122. [sön:17:33:18] <Dexo> Yes, in other cases the connection is untrusted. But I'm not sure how clients implement it.
  123. [sön:17:35:39] <Pretorian> Also, do one need to specify the correct referrer (ADC RF)? Can we connect/use with ADC and specify a NMDC hub? Sounds/feels weird.
  124. [sön:17:36:40] <Dexo> This is actually intentional. Clients will be able to speak ADC even when connected to NMDC hub.
  125. [sön:17:37:08] <Pretorian> Mhm, I'm just thinking out loud basically.
  126. [sön:17:37:13] <Dexo> So yes, RF should be specified, but this is an "identification" part of the proposal that we are working on right now.
  127. [sön:17:38:42] <Pretorian> In reality, I kinda want to treat ALNP as we did with ONID, by having a list of services (or protocols in this case) that can the functionality can be extended with
  128. [sön:17:39:36] <Dexo> Regarding ADC-r1, there is an opportunity to make some extensions standard. For example, if the client supports ALPN (so it's definitely not a legacy client), and it specifies "adc-r1" which might assume a de-facto standard extensions like SEGA, BZIP, etc.
  129. [sön:17:39:42] <Dexo> Can you please elaborate?
  130. [sön:17:41:01] <Hades> Let me know if asking oftopic questions is ok. I have a few.
  131. [sön:17:41:25] <Pretorian> <https://adc.sourceforge.io/ADC-EXT.html#_onid_online_identification> The purpose with the ONID ADC extension was to have a generic description of signalling features/services and then that service could have its own description/setup.
  132. [sön:17:41:50] <Pretorian> For ALPN I think you could re-arrange some of the wording so it's not as ADC/NMDC/HTTPS specific
  133. [sön:17:41:56] <Pretorian> But otherwise you kinda have that already.
  134. [sön:17:42:10] <Dexo> Yes, it's not specific to those two.
  135. [sön:17:42:11] <Pretorian> E.g., the whole concept of signalling nmdc/adc/https in the TLS header.
  136. [sön:17:42:30] <Pretorian> Hades: Shoot
  137. [sön:17:42:54] <Dexo> But I ONID is signalled as an extension of ADC, so you need a ADC handshake first, and this won't work for any other protocol.
  138. [sön:17:43:08] <Hades> i will wait - finish on ALPN first
  139. [sön:17:43:18] <Hades> i like that idea too but its a bit scarry
  140. [sön:17:43:26] <Pretorian> Yeah, I'm just thinking of the distinction between "generic concept" vs "specific protocol".
  141. [sön:17:43:42] <Dexo> Unfortunately ALPN is not as generic as HTTP headers. It cannot contain custom data, only real protocols that peers support in the order of preference.
  142. [sön:17:44:33] <Dexo> So if I undertood you correctly, it won't work similar to ONID.
  143. [sön:17:44:52] <Pretorian> Nah, I'm just thinking of the document distinction, not implementing it as ONID.
  144. [sön:17:45:11] <Pretorian> I might be able to do a draft later today with how I mean.
  145. [sön:17:45:20] <Crise> Dexo: on a scale from 1 to 10 how difficult would ALPN be to implement by your assesment in e.g. DC++ (read: any client that knows nothing about it)?
  146. [sön:17:45:21] <Dexo> Sorry :)
  147. [sön:17:45:53] <Dexo> Crise: as long as the client uses openssl, enabling ALPN should be <10 lines of code.
  148. [sön:17:46:12] <Crise> this is my kind of proposal :D
  149. [sön:17:46:12] <Dexo> This is the minimal part.
  150. [sön:17:46:21] <Crise> figured
  151. [sön:17:46:58] <Pretorian> Well, still need to detect it.
  152. [sön:17:47:05] <Pretorian> And choose accordingly.
  153. [sön:17:47:39] <Dexo> But, if you really want to take advantage of it, it may be a bit more. Since you can send both "adc" and "nmdc" when connecting, this will probably need a handling in the client to switch the protocol accordingly.
  154. [sön:17:47:42] <Dexo> Yep
  155. [sön:17:48:20] <Dexo> Also, there is a part with auto-detection (if peer does not support TLS), but it's more relevant to hubs, not clients.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!