Hi, Here's the summary of the previous IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 20th Jun 2013 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2013-06-20> Next meeting is scheduled for Thursday 4th July at 18:00 UTC. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, dazo, hes, jamesyonan, mattock, plaisthos and syzzer participated in this meeting. -- Discussed the "Added "setenv opt" directive prefix" patch: <http://article.gmane.org/gmane.network.openvpn.devel/7678> Cron2 and plaisthos gave this patch an ACK. Also agreed to add an "ignore-option" patch later. -- Discussed the "Updated the TLS negotiation logic to adaptively try to connect using..." patch: <http://article.gmane.org/gmane.network.openvpn.devel/7678> After a long discussion agreed that the functionality and the implementation make sense. -- Discussed the "Add support of utun devices under Mac OS X" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/7464> As utun does not support tap, decided to modify the patch to use tuntap as a fallback when tap is requested. -- Discussed the possibility of organizing an OpenVPN hackathon in Munich in late autumn/early winter, instead of meeting in FOSDEM in early February. Agreed that this was a good idea. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(21:03:36) cron2_: hi james (21:04:18) jamesyonan: hi (21:05:32) mattock: ok, shlal we (21:05:33) mattock: oops (21:05:35) mattock: shall we (21:05:43) mattock: James' set of patches (21:05:54) mattock: have these gotten any review so far? (21:06:02) mattock: oh, topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2013-06-20 (21:06:03) vpnHelper: Title: Topics-2013-06-20 – OpenVPN Community (at community.openvpn.net) (21:07:21) syzzer: my colleague Joachim and I have already mailed our review comments, focussing on the crypto/tls changes (21:08:36) syzzer: maybe go through the patch sets one by one? (21:08:58) mattock: syzzer: patches in a patchset, or patchsets? (21:09:34) syzzer: i was thinking patchsets, but patches is fine too (21:10:32) mattock: first patch would be: "Added "setenv opt" directive prefix. If present, and if the..." (21:11:12) mattock: syzzer: do we have email thread links to James' three patches? (21:11:52) plaisthos: I think I have given my opinion via mail (21:12:29) cron2_: mattock: it's all in one mail (21:12:43) cron2_: <51b8ce21.6080...@openvpn.net> (21:12:59) plaisthos: ACK, if we also add a ignore-unknown-option-list option1 option2 for the future (21:13:03) syzzer: well, theÅre's http://article.gmane.org/gmane.network.openvpn.devel/7678, which s the mail from James (21:13:05) vpnHelper: Title: Gmane -- OpenVPN Versioning (at article.gmane.org) (21:13:54) syzzer: plaisthos: +1 (21:14:43) plaisthos: I can do the ignore iption patch as follow up patch (21:16:36) ***cron2_ agrees on the general concept (both "being able to tell old clients to ignore that - nice hack with setenv opt :) - and with ignore-unknown-options for future - no more hacks) (21:17:59) plaisthos: or ignore-option ip-win32 (21:18:57) plaisthos: my client has long list of options like this it considers to be able tovsilently ignore them (21:19:00) ***dazo is here ... just didn't pay attention (21:20:04) mattock: just finished reading through the "OpenVPN versioning" email thread (21:20:25) cron2_: the patch for "setenv opt" is nicely trivial and elegant, so code-ACK from me (it does not particularily reduce the amount of magic dust in options.c, but *that* would be much harder, and break compatibility all over the place) (21:22:03) mattock: can everyone live with the current version of "setenv opt" patch? (21:22:43) plaisthos: yes (21:22:46) cron2_: if we do this, it needs to go into 2.3 as well, to be maximally useful (21:22:47) mattock: and add an "ignore-option" patch later (21:22:56) cron2_: yep (21:23:04) mattock: ok, next patch? (21:23:35) mattock: we got plenty, though we also have plenty of weeks left :P (21:24:09) cron2_: lol (21:24:25) cron2_: next patch is the TLS maximum level patch (21:24:27) mattock: yep (21:24:29) ***cron2_ needs to re-read the mail thread (21:26:57) jamesyonan: also added a related patch : https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 (21:26:59) vpnHelper: Title: Change to TLS version negotiation patch: remove implicit assumption · d230054 · jamesyonan/openvpn · GitHub (at github.com) (21:27:08) syzzer: for starters, a big +1 for enabling tls version negotiation (21:27:36) mattock: it seems TLS version negotiation patch got an ACK from Joachim (final email) (21:28:34) syzzer: open question is whether there's a case left fot the or-highest, as rollback attacks are not possible (21:29:15) jamesyonan: or perhaps "or-highest" could be implicit (21:29:46) ***cron2_ feature-ACKs that one, and leaves the code and crypto side to syzzer and joachim (21:30:00) syzzer: well, when negotiation is enabled but no min-version is present, or-highest is already implicit (21:30:04) jamesyonan: the issue is what to do if a minimum version is specified but the SSL lib doesn't support it (21:30:18) syzzer: I'd say error out (21:30:54) syzzer: if an admin is accepting 'or-highest' clients, it could also simply not put min-version in the config (21:31:00) jamesyonan: right, but the point is to avoid erroring out (21:31:28) jamesyonan: but what if a config is distributed without knowledge of which client implementation will be used? (21:32:34) syzzer: then the admin would have to choose to either use a min-version, which is the same when putting or-highest in, or no min-version (or no or-highest) (21:32:38) cron2_: to quote from the thread (21:32:42) cron2_: "The overall goal here is to provide tools that allow a controlled (21:32:42) cron2_: rollout of TLS 1.2 that doesn't break any clients during the rollout (21:32:42) cron2_: period, and to upgrade to 1.2 in a way that doesn't create the potential (21:32:42) cron2_: for MiTM version rollback attacks. (21:32:43) cron2_: " (21:33:40) syzzer: yup, so during transition there would be no min-version in the config, and TLS itself protects against rollback attacks (21:34:15) cron2_: well, I think James' goal is to only distribute new configs to clients once... (21:34:23) jamesyonan: I think we've largely discounted the risk for MiTM version rollback attacks since we always disable SSL versions below TLS 1.0 (21:35:00) jamesyonan: so tls-version-min on client is less important (21:36:10) jamesyonan: but if it _is_ used, then the idea was to combine setenv opt with or-highest to prevent any possibility of erring out when configs are distributed to unknown client implementations (21:37:03) syzzer: but what extra does the or-highest offer during this period? (21:37:26) jamesyonan: the guarantee that client won't err out (21:37:44) syzzer: wrt to not adding the min-version at all, I mean (21:38:20) jamesyonan: agreed that min-version might not be necessary on clients (21:38:53) cron2_: well, it might not be such a good idea on the server either - if you want 1.2 and your server cannot do that, erroring out sounds like a *good* plan (21:40:03) syzzer: I second that (21:40:10) jamesyonan: well that's the point of "or-highest" -- controlling whether the lack of support for that TLS version is fatal or nonfatal (21:40:57) jamesyonan: agreed though that on server, you probably wouldn't use or-highest because you are going to be in control of the config (21:41:28) jamesyonan: but clients are often run with generic configs that are generated by a server provider (21:42:17) syzzer: maybe I'm missing something here, but if you don't want to enforce the TLS min-version, why not just leave out the min-version option? (21:43:24) jamesyonan: right, but this is designed for graduated rollouts (21:44:27) jamesyonan: where server is upgraded but it might take months or more to upgrade all clients in the field (21:45:14) Hes: I'm missing something here too... so you could add the min-version on the server after the months have passed? (21:45:32) jamesyonan: right (21:45:54) jamesyonan: after you know that 100% of clients have been upgraded (21:46:08) mattock: all this makes sense (21:46:54) dazo: For me, it sounds like having this additional "or-highest" is confusing things .... if you want to set a minimum tls version ... you should know your clients are ready for it, right? At that point you shouldn't care much if there is yet another client which might fail - it just pushes for an upgrade (21:47:59) mattock: dazo: good point... I wonder how clients would upgrade unless they're forced (21:48:10) syzzer: and in the mean time, while you're okay with a lower TLS version, you don't push min-version at all (21:48:14) Hes: Same here... either you require a minimum version, or you don't (21:48:15) jamesyonan: well if or-highest is removed, then specifying a TLS version not supported will cause a fatal error (21:48:16) dazo: exactly! (21:48:39) dazo: jamesyonan: on the client, I presume? (21:49:00) jamesyonan: yes, on the client (21:49:05) cron2_: I think the missing link is that TLS will (with the patch) negotiate the highest available version anyway, right? So you really don't need this option at all on the client side, unless you don't trust the server - and then you'll know why you have put it in (21:49:16) dazo: I don't see the problem there ... if the client isn't updated, that's basically a mis-configured client (21:49:49) dazo: because when you add tls-version-min, you expect most of your clients to be ready for this (21:49:57) dazo: and that's the turning point (21:50:09) jamesyonan: if or-highest is removed, then there's no way to use tls-version-min on the client with the guarantee that it will make a "best effort" to use a high TLS version without erring out (21:51:02) cron2_: jamesyonan: but shouldn't it make the "best effort" anyway, negotiating the highest common TLS version between client and server (with the TLS changes)? (21:51:07) dazo: And this is where I probably miss the point completely ... if you set a minimum version, there is no upper limit ... it should automatically go for the highest one (21:51:31) cron2_: dazo: setting minimum 1.2 and having an OpenSSL that only supports 1.1 is the remaining issue right now (21:52:01) Hes: so, the problem is that the same config files are pushed to all clients, but some clients would not support the required version (21:52:21) dazo: in fact, it should go for the highest one even without tls-min-version indicates .... if you use tls-min-version you require the client supports at least that version (21:52:29) jamesyonan: well suppose that you are concerned about TLS 1.0 because of the never-ending list of vulnerabilities that arise from the MAC-then-encrypt behavior (21:53:01) Hes: would it be cleaner to require the minimum version on the server side only, without pushing that setting to the clients? (21:53:07) jamesyonan: so you want to prevent any client or server from negotiating with the peer unless it's at least 1.2 (21:53:19) cron2_: jamesyonan: understood, but in that case, do you want a client to stick to 1.0 just because it's OpenSSL is too old? I'd say "no" (21:53:41) jamesyonan: the point of tls-version-min is to force a minimum version, so the connection will fail if that version can't be mutually acheived (21:54:01) dazo: that I agree to :) (21:54:02) cron2_: ... and that would be set on the server, and achieve the desired effect. Right? (21:54:08) jamesyonan: but you want to push out tls-version min to clients in a way that allows for a rollout period (21:54:19) cron2_: why would you want tls-version min on the clients? (21:54:26) dazo: cron2_++ (21:54:27) cron2_: I think this is where we are disagreeing right now (21:54:58) dazo: From an admin point of view ... I couldn't care less about the clients at all. I don't trust my clients, because I don't control them. (21:55:14) dazo: So I want the power from the server side to dictate what the client needs to support (21:55:14) cron2_: as far as I understand, if you have client+server that *can* negotiate higher versions, they *will*, so the option on the client side won't make a difference (21:55:27) dazo: right (21:56:02) jamesyonan: agreed that tls-version-min is less important on clients (21:56:52) syzzer: cron2_: yes, that's my understanding too. I could double check with Joachim tomorrow, as he's knows this stuff by heart (21:57:57) mattock: do we have an agreement / list of proposed changes? (21:58:00) dazo: So what I don't grasp then is .... what is the difference between not having 'tls-version-min' at all on the client side, and 'tls-version-min 1.2 or-highest' if the server only supports 1.1? (21:58:06) jamesyonan: but remember that trust goes both ways -- in some cases you might be connecting to a third-party server that you don't completely trust (21:58:10) dazo: sorry, mattock :) (21:58:24) mattock: dazo: I take that as a no :D (21:58:25) cron2_: dazo: ah, in *that* case, the client would bomb. The "or-highest" would cover the *client* not supporting 1.2 (21:58:32) cron2_: mattock: not yet (21:58:45) cron2_: but I've been busy to do away the rest of the agenda anyway (21:58:57) mattock: cron2_: excellent, noticed that! (21:58:59) dazo: cron2_: it should bomb in the case of just ''tls-version-min 1.2' (21:59:15) dazo: but it's the semantics around 'or-highest' which confuses me (21:59:52) cron2_: dazo: if the *server* does not support 1.2, it will *always* bomb. But if you do that with a client SSL library that does not support 1.2, "or-highest" will step down to what the client can do (like "1.1") and enforce that (22:00:08) dazo: ahhh! (22:00:13) dazo: I was on the wire the whole time (22:00:40) dazo: okay, now I actually *do* see the point of it (22:00:40) cron2_: I'm not convinced this is a really necessary use case, though, as my rollback would look different - just roll out clients that would negotiate the version, and then enforce it on the server side (only) (22:01:00) cron2_: but I'm not strictly objecting either, as I have little experience with large-scale user bases (22:01:10) pekster: cron2_: I don't get what that gives the power to do that a simple min/max wouldn't; after all, the point of lower boundries is to prevent a MITM downgrade, right? (22:01:38) pekster: You're trusting the *client* to say "my library is too old for 1.2, but I can offer 1.1" -- what stops a downgrade attack that needs <=1.1 from doing just that? (22:01:47) dazo: as f.ex. you have a scenario with many BSD and RHEL clients .... BSD may have upgraded to a newer OpenSSL ... while, pulling OpenVPN from EPEL repositories on RHEL will give you quite new OpenVPN versions ... but the OpenSSL library in RHEL may not support TLSv1.2 (22:01:53) jamesyonan: or-highest says that minimum TLS version must be min(argument_given, max_tls_ver_supported_by_SSL_lib) (22:02:01) dazo: and might not ever support it, in that major version of RHEL (22:02:17) pekster: jamesyonan: Oh, max_lib_supported from the local view? (22:02:31) jamesyonan: yes, the client-side SSL lib (22:02:59) cron2_: ah, the confusion starts to clear :) (22:03:35) pekster: Mostly. When used on the server, that is in reference to the client lib's supported version? If so, how is that trusted info? (22:03:51) cron2_: no, when used on the server, it's the server's lib (22:04:02) cron2_: (where I doubt the usefulness) (22:04:04) pekster: kk, now I get it; useful for the edge case then (22:04:37) jamesyonan: basically the optiion is used to give the local SSL lib the minimum TLS version to accept from the peer (if the minimum can't be acheived, then connection aborts) (22:05:18) dazo: Okay, I'm convinced! That's a useful tweak (22:05:46) syzzer: I can see the case too now :) (22:05:57) mattock: am I sensing a consensus? (22:05:58) mattock: :P (22:07:15) dazo: I'd say so, mattock :) (22:07:44) cron2_: mattock: as a side note: is buildbot aware of the new git repo addresses? (22:07:53) mattock: cron2: probably not (22:08:03) mattock: depending on whether they pull from GitHub or not (22:08:06) mattock: can't recall (22:08:19) cron2_: buildbot is older than github, so I'd assume "not" (22:08:21) mattock: ok, so is the patch ok as-is? (22:08:37) mattock: cron2: I'll check the Git repo addresses (22:08:49) syzzer: maybe extend the documentation on the or-highest? (22:09:12) dazo: syzzer++ (22:09:13) mattock: syzzer: probably makes sense (22:09:40) jamesyonan: make sure to also include related patch https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 (22:09:41) vpnHelper: Title: Change to TLS version negotiation patch: remove implicit assumption · d230054 · jamesyonan/openvpn · GitHub (at github.com) (22:09:44) cron2_: I think the documentaiton is quite clear (22:09:54) cron2_: ah (22:10:14) cron2_: I was looking at the commit message, not the manpage, but even the manpage is clear (22:10:21) cron2_: If 'or-highest' is specified (22:10:22) cron2_: +and version is not recognized, we will only accept the highest TLS (22:10:26) cron2_: +version supported by the local SSL implementation. (22:11:34) cron2_: jamesyonan: could I ask you to mail the final result (the two particular commit IDs that we should pull) to the list again? So it's clear "*this* is what goes in" (22:11:53) jamesyonan: sure (22:12:00) cron2_: the second one is hidden in the middle of the thread, which is sort of hard to reference (22:12:00) mattock: \o/ (22:12:21) mattock: do we have energy for Arne's patches? (22:12:30) ***cron2_ will leave the pulling to dazo anyway :-) but it helps nonetheless (22:12:55) dazo: I won't have much spare cycles for that until next week, but I'll find time for it (22:13:09) cron2_: well, I'm happy to ACK the utun patch as soon as Jonathan confirms that it works for all versions of OSX (which he went out to test already) (22:13:24) cron2_: what I'm not so sure about is "2.3.3" or "2.4-only" (22:13:25) mattock: cron2: ok, so no need to discuss it at the moment (22:13:45) dazo: cron2_: isn't this new feature, strictly speaking? (22:13:45) jamesyonan: question on utun patch: does it support tap? (22:13:49) cron2_: and I'd still support tun.kext, as tunnelblick wants it (22:14:29) mattock: jamesyonan: it's possible that was discussed in the thread... I'll check (22:14:45) cron2_: dazo: I'd consider it a compatibility change for OSX, which is somewhere between feature (2.4!) and bug (2.3 and 2.4)... (22:14:56) cron2_: plaisthos: wake up, question for you (22:15:30) dazo: cron2_: I'm thinking we need some 2.4 goodies too ;-) .... but I won't object to a 2.3 release (22:16:53) mattock: nothing about TAP in utun (22:18:14) mattock: if we release 2.4-alpha1 fairly soon, we could make this 2.4-only (22:18:32) ***cron2_ has no idea - the patch "as coded" will do "something" for "--dev tap --dev-node utun0" but I'm not sure whether that leads to a working tap device, or a confused openvpn. I guess "confused openvpn", as there is nothing to change the mode of utun to "tap" (22:18:34) dazo: I don't think we're there yet at all (22:18:48) cron2_: mattock: at least half a year to go (22:18:52) jamesyonan: if utun doesn't support tap, then we need to make sure that code will fall back to tuntap driver for tap tunnels (22:20:23) dazo: Didn't the utun function just as tuntap? It was just the device creation which was slightly different, using some different ioctl()s? or did I just dream reading that? (22:20:35) cron2_: yep, another clause in that if() - "only try utun for DEV_TYPE_TUN" (22:21:15) cron2_: dazo: "just as tun" with no "tap" - if it could do tap, it would in any case need some sort of "turn yourself into a tap device!" function call, which isn't there today (22:21:29) cron2_: so whatever the device does, we can't access it as tap today (22:21:33) dazo: cron2_: right (22:21:52) cron2_: ok, postponed until we can find this out or fix it :-) (22:22:54) mattock: sounds good (22:23:14) mattock: what about "Fix client-nat only working is also mss-fix is specified."? (22:23:32) plaisthos: cron2: here i am (22:24:11) cron2_: plaisthos: just sent a followup mail to v6 to the list... :-) - so - do you know right away whether utun can do tap? (22:24:52) plaisthos: jamesyonan, cron2: I found nothing but utun doc is sparse anyway (22:25:28) cron2_: plaisthos: in that case, I think we want an extra check that the user really wants an DEV_TYPE_TUN before going to utun (22:26:04) cron2_: (or maybe inside the big if() an "if (!DEV_TYPE_TUN) msg(M_ERR, "don't use tap with --dev-node utun") (22:26:34) plaisthos: so check dev for tun and check dev type too? (22:27:15) cron2_: well, you're not checking "dev" right now, you only check "dev-node" (22:27:35) cron2_: so if dev-node starts with "utun", you go to open_darwin_utun(), no matter what "dev" is set to (22:28:21) plaisthos: cron2: will check again if Ivam atthbe pc again (22:28:38) plaisthos: but I doubt aboit tap (22:28:49) mattock: plaisthos: are you on a tablet atm? (22:29:20) cron2_: plaisthos: thanks. (22:29:28) plaisthos: there some defines for crypto stuff on utun but nothing that suggest tap mode (22:29:46) plaisthos: mattock: yes (22:29:59) mattock: ok, reminded me of my attempts to write emails on nexus 7 :P (22:30:17) mattock: next topic? or next topic next week/meeting? (22:30:19) cron2_: mattock: the process_ipv4_header is... too complicated for me right now - if James and plaisthos agree on either of these fixes, I'm fine with that but I'm too tired to review myself (that code is too complicated for me) (22:30:28) plaisthos: yeah it is a nexus 7 here as well (22:30:44) mattock: very nice tablet, but it seems to "help" too much when typing (22:30:53) mattock: maybe we should call it a day? (22:31:05) mattock: could you guys gather here next week at the same time? (22:31:19) mattock: i.e. meeting next week? :P (22:31:30) jamesyonan: might not work for me next week, but following week is okay (22:31:37) ***dazo too (22:31:52) mattock: the week after next works for the rest of you? (22:31:57) plaisthos: I have the swype keyboard that is better imo but that ias OT at the moment (22:32:00) cron2_: before calling it a day, I want to bring up something I have been toying around with for a while (22:32:06) syzzer: I won't be, but the week after is probably fine (22:32:17) mattock: cron2: munich? (22:32:34) cron2_: meeting you all at fosdem was cool, but I really don't like fosdem or brussels, and that particular weekend always conflicts with the munich Go tournament, which is extra annoyance (22:33:03) mattock: I agree Brussels is like "so last season" (22:33:10) mattock: seen it, been there, done that (22:33:20) cron2_: so I thought I would get a conference room with internet access for a weekend, or maybe friday to sunday, on company expenses (well, we're an ISP and have enough rooms, so that is sort of easy) and gather here (22:33:38) cron2_: maybe some snacks :-) (and there's lots of nice restaurants around) (22:33:50) mattock: what does "on company expenses" include? :D (22:34:15) cron2_: "room", "gige internet access", "coffee", at least (22:34:27) cron2_: (including heating!) (22:34:32) mattock: good enough, more than at FOSDEM (22:34:35) mattock: yeah, heating (22:34:49) cron2_: well, the plus of fosdem is "you get to meet non-openvpn people" (22:35:23) cron2_: meeting in Munich only works out if we can get enough "core team" here... (22:35:38) mattock: I have to jump into a freezing lake now (22:36:07) dazo: I might be able to manage that, if we can agree on a date far into the future ... then I can get round-trip tickets for ab €100 (22:36:12) mattock: at a summer cottage, no hot water atm (22:36:18) cron2_: anyway, as everyone seems to be asleep already :-) - let's call it a day... (22:36:25) mattock: cron2: +1 (22:36:29) dazo: cron2_: I like the idea! (22:36:36) mattock: I'm in also (22:36:40) syzzer: ah, yes, mee too (22:36:51) cron2_: ok, I'll decide on a date (November, as this is supposedly somewhat quiet, october is busy for me, september is crazy here with octoberfest) (22:36:54) cron2_: cool (22:37:04) mattock: as dazo said, let's arrange it well in advance so we get cheap flights (22:37:18) dazo: yeah, November time frame sounds reasonable (22:37:26) syzzer: although octoberfest is fun too ;) but i agree, november is probably best (22:37:42) cron2_: cool :-) (22:37:46) mattock: syzzer: if we went during the octoberfest, how different would it be from FOSDEM? (22:37:48) mattock: :P (22:38:01) mattock: ok, next meeting the week after next one (22:38:03) cron2_: mattock: much (MUCH) more expensive accomodation (22:38:06) plaisthos: more women? (22:38:15) cron2_: yeah, with drunk women :) (22:38:22) mattock: oh yes
