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 9th Jan 2014 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2014-01-09> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, dazo, jamesyonan, janjust, mattock, plaisthos and syzzer participated in this meeting. -- Discussed the "definition of the new data frame format with and without session ID" issue previously discussed here: <http://thread.gmane.org/gmane.network.openvpn.devel/8128/focus=8142> <https://community.openvpn.net/openvpn/wiki/MunichHackathon2013#results> The conclusions reached in Munich (see second link) still mostly hold. The session ID can be embedded into both ping packets and into small data packets; this will ensure that the MTU will not be exceeded. Specific timing and configuration of feature is subject to further discussion when we have a prototype to experiment with. James will document both the old and new packet formats once the definition has crystallized fully. -- Discussed the "Missing "IV_OPENVPN_GUI_VERSION" in OpenVPN Connect" issue. James has added this string to OpenVPN Connect, but it was decided to shorten the string to IV_GUI_VER to save some space before this feature is in wide use. -- Discussed the "ssl: enable basic ecdsa" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/7958/focus=7961> Syzzer will do further review on this patch and hopefully ACK it soon, even if it only provides partial EC support; this because having full EC support is not easily doable at this point. -- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(20.01.19) mattock: hi (20.01.25) mattock: so meeting time for a change (20.01.31) dazo: :) (20.01.33) ***syzzer reporting (20.01.36) mattock: james should hop in here very soon (20.01.44) ***cron2 is here (20.02.06) dazo: I can't promise to be mentally present the whole time, but I'll do my best to pay attention :) (20.02.42) jamesyonan [~jamesy...@c-24-9-78-222.hsd1.co.comcast.net] è entrato nella stanza. (20.02.42) modalità (+o jamesyonan) da ChanServ (20.02.51) ***cron2 sends a glass of coffee liqueur to dazo (20.03.37) dazo: heh :) thx! (20.03.39) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2014-01-09 (20.03.40) vpnHelper: Title: Topics-2014-01-09 – OpenVPN Community (at community.openvpn.net) (20.03.55) mattock: janjust said he tries to get in this meeting (20.04.18) mattock: so we have some heavy-duty stuff today: "Figure out definition of the new data frame format with and without session ID" (20.04.34) mattock: links to previous discussion on the topic page (20.04.53) cron2: I think that one is pretty much "remind james that he wants to tell us how it should look like" :) (20.05.03) mattock: :P (20.05.19) mattock: james: do you have any documentation on this matter? (20.07.55) mattock: plaisthos: are you present? (20.08.00) plaisthos: mattock: yes (20.08.03) mattock: ok, great! (20.08.15) mattock: you will be needed for the next topic (20.09.29) mattock: jamesyonan? (20.11.01) jamesyonan: hi, just refreshing my memory on this (20.11.26) mattock: ok (20.11.51) mattock: these is a summary of our Munich discussions here: https://community.openvpn.net/openvpn/wiki/MunichHackathon2013#results (20.11.53) vpnHelper: Title: MunichHackathon2013 – OpenVPN Community (at community.openvpn.net) (20.12.19) mattock: under "packet format and alignment" if I'm not mistaken (20.14.04) jamesyonan: right, the basic idea is that if bandwidth were never an issue we just send the full session ID with every packet, but... (20.14.32) jamesyonan: to save bandwidth, optimize this in some way so that both peers only need to send the session ID when necessary (20.15.23) plaisthos: So basically two new opcode for IS_SWAPPED and HAS_SESSION ID (20.15.23) jamesyonan: we already do this to some extent, in that currently only control channel packets contain a session ID (20.15.53) plaisthos: so the new session ID is only needed for DATA packets? (20.15.58) jamesyonan: yes (20.15.59) cron2: yep (20.16.26) plaisthos: so P_DATA_SWAPPED and P_DATA_SESSIONID (20.16.57) cron2: which source files do I need to read to understand frame format, and opcode definitions? (20.16.58) plaisthos: (and the sessionid would have also a nice alignment) (20.17.14) plaisthos: cron2: ssl.h has the opcodes (20.17.21) plaisthos: packet format is iirc implicit (20.17.44) cron2: plaisthos: session ID would be swapped as well (20.18.07) cron2: plaisthos: well, "which .c file builds packets"? never had to research *that* (20.20.17) plaisthos: cron2: hm it is in forward.c but spread over multiple functions (20.20.30) cron2: *note* (20.20.45) plaisthos: but the problem we are talking about is [opcode - one byte][encrypted data] (20.21.20) cron2: plaisthos: I think I fully understand the problem and solution proposed ;-) - I just had no idea where to look for actual code (20.21.43) cron2: the compression layer also does the byte-swapping-for-alignment (20.21.44) plaisthos: cron2: tls_post_encrypt for the op code adding to data (20.21.58) cron2: thanks (I'll go and read) (20.24.16) plaisthos: how many bits do we need for a session id? (20.24.25) plaisthos: 24, 32, 56? (20.24.38) jamesyonan: 64 (20.25.41) plaisthos: that is the session id size of the control session, right? (20.26.04) jamesyonan: yes (20.27.08) plaisthos: so for the new P_WITH_SESSION ID should we use the session id to align the packet or keep it in place and do swapping? (20.27.28) plaisthos: like [op][first 3 byte of session][tls data][5 byte of session id]? (20.27.45) jamesyonan: I think we have to swap (20.27.46) cron2: I'd go for "with the new opcode, you always swap the first byte" (20.28.00) cron2: opcodes (20.28.12) jamesyonan: otherwise the first opcode byte will misalign everything that comes after (20.28.29) janjust [~janjust@openvpn/community/support/janjust] è entrato nella stanza. (20.28.29) modalità (+v janjust) da ChanServ (20.29.02) jamesyonan: we also need to add some capabilties negotiation so that peers can indicate whether or not they support P_DATA_SWAPPED and P_DATA_SESSIONID (20.29.12) cron2: all in the minutes from Munich :) (20.29.51) cron2: right at the end there's a TODO list for this (20.30.00) plaisthos: we could do this by adding a IV_FORMAT 1? (20.30.46) cron2: well, I called it IV_PROTO=2, but you can name it IV_FORMAT=1 if you want (20.30.58) plaisthos: IV_PROTO sounds nice (20.30.59) plaisthos: r (20.30.59) cron2: peer-info is transmitted in the control stream, as is pushed config (20.31.06) janjust: hi y'all ; did the meeting start? or is it 2000 euro time? (20.31.23) plaisthos: janjust: did start at 1900 cet (20.31.29) mattock: janjust: the meeting started 30 mins ago, we're still at first topic (20.31.35) janjust: whoops, sorry for being late (20.31.51) jamesyonan: the buffer where IV_x parms are staged is small, so we want to be conservative in terms of space (20.32.05) jamesyonan: maybe IV_FLAGS=x and we can add flags as needed (20.32.21) plaisthos: jamesyonan: we can still make IV_PROTO count up (20.32.57) cron2: that was my assumption, just count up for new wire-format changes (20.33.23) jamesyonan: sure, that's reasonable (20.36.43) plaisthos: we could also mandate that all IV_PROTO=2 client support at least STUB compression (or even lz4) (20.36.57) mattock: once you guys are done with the discussion, please summarize it for me, all this goes over my head :D (20.37.09) mattock: for me + the general public (20.37.12) cron2: mattock: as far as we're today, it's all in the notes from Munich :-) (20.37.20) cron2: except that we now have opcode names (20.37.30) mattock: ok (20.37.43) mattock: we'll see where this goes and update the docs (20.38.18) jamesyonan: I'm wary of making compression algs part of IV_PROTO because sometimes for space or licensing reasons a given alg might not be included, even though the OpenVPN implementation uses a higher IV_PROTO level (20.38.35) plaisthos: jamesyonan: ah okay (20.38.49) plaisthos: was just a quick idea (20.42.30) cron2: ok, I think we have all we need, except for one thing - is one of us volunteering to go forward with this "soonish" (mainly to avoid two persons starting and doubling effort) (20.42.46) janjust: I am still reading up on the IV_PROTO part ... (I've been out of openvpn & its development for some time). Does IV_PROTO=2 allow for some sort of negotiation (say similar to PPP style negotation) ? (20.43.07) cron2: yes and no, we already have negotiation of many sorts :-) (20.43.29) cron2: client sends capabilites in IV_ strings in the "peer info", server sends back result as part of PUSH_REPLY (20.43.35) janjust: well, how about encryption/compression/hashing negotiation? (20.43.45) plaisthos: janjust: different topic :) (20.44.05) plaisthos: compression is in there (20.44.06) cron2: this works for all but --cipher and --auth, but that's primarily due to the 2.x code base not permitting pushed --cipher - protocolwise, it would work (20.44.30) janjust: plaisthos: true, but when designing a new IV_PROTO mechanism it would be nice to ensure that a negotation is possible in the future (20.44.45) dazo: and pushing --cipher would be quite hard, as you would need to re-setup the tunnel with the new parameters (20.44.46) cron2: janjust: listen closely :-) (20.44.50) cron2: dazo: no (20.45.05) cron2: I said "2.x code base". The 3 code base already understands this (20.45.05) plaisthos: dazo: no (20.45.17) jamesyonan: the basic concept that OpenVPN currently uses for negotiation is to have the client send a list of key value pairs (IV_x) to server stating capabilities then server sends "push" commands back based on the intersection of its own capabilities and those of the client (20.45.22) janjust: pushing a ciphier is not the same as negotiating one - for example , the TLS channel cipher that is chosen is actually negotiated by the OpenSSL TLS session layer in most cases (20.45.47) cron2: PUSH_REPLY and peer-info happens in the TLS bit, data layer is crypted+authed by --cipher/--auth (20.45.54) dazo: no? The push comes after the TLS authentication and encryption setup, doesn't it? (20.46.13) cron2: dazo: yes, but the *TLS* parameters are not used for *data* packets (20.46.20) plaisthos: dazo: yes but typtically you have different encryption ciphers for control and data packets (20.46.21) dazo: ahh, okay (20.46.32) cron2: this is actually quite nice :-) (20.46.44) dazo: agreed (20.46.47) janjust: but I'm digressing here - as long as the new IV_PROTO system is extensible in the future then I'm happy (20.46.47) cron2: janjust: the client would send a list of supported ciphers, and the server would pick the "best" and push the result back (20.47.14) cron2: so it might not be full two-way negotiation (like in PPP where you can go back and forth numerous times) but a client/server thing (20.47.37) cron2: we can do it today for compression protocol (lzo/snappy/lz4), just not yet for --cipher and --auth (20.47.40) janjust: cron2: agreed (20.48.21) cron2: (and I've not yet spent thoughts whether it would work for peer-to-peer mode where you don't have push) (20.48.40) janjust: there are other parameters that might be worthwhile to 'negotiate', e.g assymetric tun-mtu sizes (20.49.06) janjust: but again, I'm digressing, so I'll shut up for now (20.51.32) mattock: so has this topic been covered? (20.51.52) plaisthos: Think so (20.52.09) plaisthos: Aside from someone coding a prototype (20.52.18) syzzer: Yeah, except that we need commitments ;) (20.52.55) syzzer: not sure about coding prototype, a clear doc on the (old and) new packet format would be a good start I think (20.53.02) mattock: syzzer: +1 (20.53.14) mattock: who could do that? James? (20.53.17) cron2: you crypto guys are so obsessed with documentation... (20.53.34) mattock: who need any frigging documentation, right? :P (20.53.52) dazo: R T F code (20.53.59) krzee: crypto code documents itself, amirite? (20.54.01) krzee: :D (20.54.02) syzzer: hehe, yeah, we tend to do that ;) (20.54.09) dazo: :) (20.54.13) plaisthos: krzee: have fun reading openssl code (20.54.17) jamesyonan: yes, I can document (20.54.24) dazo: plaisthos++ (20.54.34) krzee: plaisthos, i couldnt even handle openvpn code ;] (20.54.44) plaisthos: krzee: have no idea (20.54.47) plaisthos: +you (20.55.03) plaisthos: try reading openssl (20.55.16) syzzer: jamesyonan: well at least I would appreciate that ;) (20.55.22) cron2: +1 (20.55.25) plaisthos: and you start asking yourself why this horrible code is one of the most used security libraries (20.55.31) jamesyonan: openssl is so retro 90s C -- gotta love it :) (20.55.36) janjust: lol @ plaisthos ; I'm a little too familiar with the openssl code (20.55.42) mattock: ok, I'll make a note that "James will document the old and new packet format" (20.55.42) janjust: at least it's C and not C++ :P (20.55.57) plaisthos: I can code an intial protype for the new format in OpenVPN 2.x (20.55.58) cron2: should we tell janjust about OpenVPN 3? (20.56.07) plaisthos: cron2: nah (20.56.09) janjust: hehe cron2, I'm aware that that's written in C++ (20.56.10) ***dazo grabs some popcorn (20.56.20) jamesyonan: C++ is great (20.56.39) mattock: dazo: good idea :) (20.56.45) janjust: well written C++ is great, horribly written C++ is far worse than horribly written C (20.56.57) jamesyonan: agreed (20.57.22) plaisthos: (like without fancy automatic recovery and stuff, just always send the session id) (20.58.40) plaisthos: but so client and server understand the new formats (20.59.08) jamesyonan: plaisthos: are you saying we should always send the session ID even in data packets? (20.59.14) cron2: plaisthos: well, not "alway" please, just once a second or so (20.59.22) cron2: (for the prototype) (20.59.51) plaisthos: jamesyonan, cron2: I have to look at the timer stuff in OpenVPN (21.00.08) ***cron2 is in the "we only send the session ID if we haven't heard from the other side in a suspicously long time" camp (21.00.13) plaisthos: I have no idea how hard it is to figure out (is the last timestamp 1s ago) (21.00.32) cron2: it's not exactly "timer" as in "tell me about this in <x> ms", more in "keep a timestamp $somewhere" (21.01.14) jamesyonan: well one starting point would be to initially only send the session ID on ping (keepalive) packets (21.01.43) cron2: is a ping packet a normal data packet? (21.01.53) jamesyonan: yes, mostly (21.02.11) jamesyonan: it follows the data channel (21.04.43) jamesyonan: one approach could be something like (a) when sending packet, include session ID if last session ID was transmitted more than n seconds ago, and (b) always include session ID on pings (21.05.22) cron2: if it's easy to do, I'd go for "if the last packet from the other side was heard longer than <n> time units ago" (21.05.39) cron2: because if both sides are happily sending packets back end forth, we have no need whatsoever for a session ID (21.06.02) cron2: but if we do not see packets from the other side, we might have "lost" the peer (21.06.43) cron2: (module some "no more often than <x>" if we have truly unidirectional traffic) (21.08.03) plaisthos: or just relay on PING alltogether (21.08.26) plaisthos: so we don't run into the packets with session id have a smaller mtu than packets without (21.08.50) cron2: people tell me that they want to send pings very seldom (battery life) but have fast float failover for their mobile stuff... (21.09.13) cron2: but I think this is something that can be nicely tuned if the basic mechanics are there (21.09.15) syzzer: cron2++ (21.09.38) jamesyonan: right now pings are only sent during traffic quiet time (21.10.07) jamesyonan: so an active connection with packets flowing in both directions will never xmit a ping (21.10.08) plaisthos: cron2: I meant sending an out of order ping with session id (21.10.34) plaisthos: or if we have session ids just reduce the mtu by 8 (21.10.48) plaisthos: otherwise we might get strange mtu problems :/ (21.11.00) cron2: plaisthos: ah, yes, that would work as well. Or just do it for non-full packets. (21.11.02) jamesyonan: yes, good point (21.11.31) cron2: jamesyonan: but if packets are flowing both ways, you have no need to send the session ID anyway (21.12.34) jamesyonan: but using only ping packets could potentially add to the delay before peers can reconnect on new network (21.13.16) syzzer: if one side is sending out packets, I guess it won't send out ping packets (21.13.38) cron2: true, so use "non-full" packets or artificial ping, if the other side went silent suddenly (21.13.52) plaisthos: cron2: non full won't work (21.14.00) jamesyonan: is it the case that the only purpose of this feature is to allow client to change its IP address without full TLS renegotiation? (21.14.07) cron2: "if there is no non-full packet around, send a ping" (21.14.22) plaisthos: jamesyonan: as I understood it, yes (21.14.38) cron2: jamesyonan: the session ID is only for --float in TLS mode (21.14.44) cron2: ("as I understood") (21.15.03) jamesyonan: what if we think about this differently… suppose we just add a new control channel message that says "client changed IP address" (21.15.04) cron2: the IV_PROTO=2 is for alignment, and it gives us a nice vehicle to do the other bit right away (21.15.18) cron2: you don't necessarily know that the IP address has changed (21.15.30) cron2: there are broken enough setups with layers of NAT... (21.16.06) plaisthos: jamesyonan: the client might not know that (21.16.39) cron2: a mobile client that roams wifi/3G will know, but someone behind an expiring/rebooting NAT might not (21.16.40) plaisthos: the NAT of my mobile provider has a timeout of 60s for UDP unless I use the SIP UDP port (21.17.13) jamesyonan: on mobile though, usually the client gets a message about network transitions (21.18.21) syzzer: well, Android for example tries to do that, but (at least about a year ago) fails to report properly quite regularly... (21.20.03) plaisthos: jamesyonan: not about the expiring NAT session :/ (21.21.05) plaisthos: the control channel message with "client changed IP address" is ping with session id, right? (21.21.38) cron2: +1 :) (21.22.12) jamesyonan: ping with session ID would be a data channel message (21.23.29) jamesyonan: I would tend to agree that adding the session ID to a ping packet is probably the best/easiest-to-implement solution (21.24.48) jamesyonan: however then we would need to change the ping timing alg to always ping even when traffic exists (21.24.55) plaisthos: ah a ping packet is basically a data packet with lenght 0 (21.25.05) ***plaisthos found it in the source (21.25.15) jamesyonan: and the ping delay would become the worst case delay for network transition detection (21.25.42) jamesyonan: no, a ping is a specific sequence of bytes (21.25.58) plaisthos: okay I misread the source then (21.26.23) plaisthos: yeah I did (21.26.39) jamesyonan: it's a 16 byte constant message sent within the framing of a data channel packet (21.30.26) cron2: ok, I think this topic has been exhaustively covered :-) (21.30.37) jamesyonan: the downside of session ID hitching a ride on a ping packet is that we might want to increase the ping delay in the future to reduce overhead, and this means that we will also be increasing worst-case failover delay (21.30.45) cron2: shall we jump to GUI VERSION and come back to this when we have a prototype (21.31.14) cron2: jamesyonan: this is why I proposed to do "ping with ID" and as well "data packet with ID if we feel like it" and the "if we feel like it" can be fine tuned when we have experience (21.31.59) jamesyonan: agreed, but plaisthos has a good point about not wanting to push against mtu limits (21.31.59) mattock: yeah, let's continue (21.32.16) mattock: let's "sleep over it" (21.32.30) mattock: maybe discuss it on the ml and/or next week in a meeting (21.32.54) cron2: jamesyonan: if no suitable data packet can be found, we can just send an out-of-order ping "because we feel like it" (21.33.54) jamesyonan: right, maybe hitch session ID on smaller data packets, and only resort to out-of-order ping if necessary (21.34.08) cron2: that was my idea (21.36.27) jamesyonan: that sounds good with the added logic that sess ID only added to packets if doing so does not increase packet size beyond mtu (21.36.57) cron2: yep, "suitable data packet" (21.37.32) jamesyonan: is this something that will be on by default, or enabled with a directive? (21.37.54) jamesyonan: and if it's a directive, does it include a max-seconds-delay parameter? (21.38.48) ***cron2 hasn't thought about that question yet (but I assumed there would be a configurable "delay" parameter) (21.40.42) jamesyonan: ok, shall we move on? (21.40.46) cron2: yep (21.40.54) mattock: sounds good, 100 minutes for one topic is a lot :P (21.41.06) mattock: "Missing "IV_OPENVPN_GUI_VERSION" in OpenVPN Connect" (21.41.21) mattock: so plaisthos added this thing to OpenVPN for Android already, right? (21.41.22) jamesyonan: ok, good new is that I just added it (21.41.31) mattock: nice! (21.41.31) cron2: is it on staging? (21.41.42) plaisthos: jamesyonan: you said earlier that IV_ space is precious (21.41.57) plaisthos: we can also still change that to something small like IV_GUI_VER (21.42.52) jamesyonan: yes, IV_GUI_VER would be better if it's not too much trouble to change (21.43.25) cron2: as it is in no released 2.x version yet, now would be a good time to do so (21.43.41) mattock: could someone review/fix this very brief summary of the previous discussion: http://fpaste.org/67160/29653413/ (21.43.49) mattock: something is surely missing :P (21.43.59) cron2: IV_OPENVPN_GUI_VERSION=net.openvpn.connect.ios_1.0.4-133 (21.44.02) cron2: \o/ (21.45.07) jamesyonan: + for IV_GUI_VER (21.45.10) jamesyonan: +1 (21.45.19) cron2: mattock: "specific timing and configuration of feature is subject to further discussion when we have a prototype to experiment with" (21.45.31) mattock: cron2: ok, fixing (21.47.33) mattock: ok, next topic? (21.48.15) mattock: which would be "Signal handling is a bit funny in some places" (21.48.22) mattock: of course, we don't have to discuss everything today (21.48.31) cron2: I've just sent a IV_GUI_VER= patch to the list (21.48.40) mattock: oh, that was quick (21.50.09) cron2: trivial change :) (21.50.18) mattock: yep :) (21.50.43) mattock: actually, maybe we should discuss the "ssl: enable basic ecdsa" patch? (21.50.53) mattock: janjust is here primarily for that reason (21.51.15) mattock: and we're at 1:50 and counting :P (21.51.51) janjust: hehe yep (21.52.14) janjust: my main question about that patch is: is something blocking it? (21.52.33) janjust: I know it is not full EC support, but at least it allows for ecdsa+sha2 signed certs (21.53.21) syzzer: ah, I think this is my cue :p (21.53.35) janjust: yep (21.53.50) syzzer: the patch actually is ECDH, not ECDSA, but still it's nice and should be integrated (21.54.31) cron2: syzzer: so ACK. For 2.4, or do you feel it's safe+needed for 2.3? (21.54.34) janjust: agreed, I misnamed it because openssl itself misnames it (21.54.36) jamesyonan: the patch only addresses OpenSSL right now? (21.54.40) syzzer: I've started looking at it a couple of weeks ago, and the basis is good (21.54.43) janjust: jamesyonan: yes (21.54.57) syzzer: jamesyonan: but hat is not an issue, I've got patches for polar lying around (21.54.58) jamesyonan: it might be nice to have a PolarSSL patch as well (21.55.08) jamesyonan: what more is required for full EC support? (21.55.24) syzzer: problem is, it needs stuff that's not yet released by pkcs11-helper (well, it is in git master...) (21.55.40) jamesyonan: like what? (21.55.43) janjust: "full EC support" means that the key exchange in openvpn needs to be altered (21.56.01) janjust: encryption is still done using AES - but ECDH replaces regular DH key exchange (21.56.24) syzzer: jamesyonan: the ECDH patch from janjust uses a fixed or chosen curve for ECDH, while the TLS spec actually says 'use the curve from the certificate' (21.56.40) janjust: syzzer: the second version of my patch allows a user to choose a curve (21.56.44) jamesyonan: but if it's just a change to TLS negotiation, wouldn't it be transparent to OpenVPN data channel? (21.57.05) syzzer: yeah, so security-wise it's fine, its just not really TLS-compliant (21.57.14) janjust: jamesyonan: yes, but it might be nice to alter the key exchange for the data channel as well to support Elliptic Curves (21.57.33) syzzer: ECDH is the key exchange, ECDSA the signature algorithm (21.57.40) jamesyonan: but the data channel is purely a symmetric crypto operation (21.57.48) syzzer: for full EC-support we'll need ECDSA too (21.58.00) syzzer: yep, no EC stuff neede for the data channel (21.58.14) janjust: ah good, this is new for me :) (21.58.23) syzzer: furthermore, TLS also keeps using AES or some other symmetric cipher for the tls-encryption (21.58.40) syzzer: it will just use EC for key exchange and signature algorithm (21.58.48) syzzer: just the way it does for RSA (21.58.59) jamesyonan: syzzer: but what do you mean by "not really TLS-compliant"? (21.59.30) syzzer: TLS expects ECDH to use the same curve as was used in the certificate, so same curve as for ECDSA (21.59.40) syzzer: but for that, we'll need ECDSA support (22.00.23) janjust: syzzer: what would we need for ECDSA support? I'm willing to investigate/contribute (22.00.53) jamesyonan: but can this be done in a way that only affects OpenVPN code that configures the SSL/TLS connection prope rties, not the control channel or data channel code? (22.01.04) syzzer: I'n not sure yet, I'm not too familiar with the OpenSSL API. (22.01.27) syzzer: jamesyonan: yes, I think so (22.01.41) janjust: errrr, if we do full ECDSA (signing) support, wouldn't it make sense to sign the datachannel using ECDSA also? (22.01.42) jamesyonan: OpenVPN tries to treat SSL/TLS protocol as a black box (other than initial setup) (22.02.12) syzzer: data channel uses HMAC (22.02.26) syzzer: which is way faster and very secure (22.02.53) syzzer: it needs the slow (and less trusted) asymmetric stuff just for key exchange (22.03.13) jamesyonan: Right -- I don't think the asymmetric stuff belongs in the ovpn data channel (22.03.19) janjust: I agree (22.04.04) janjust: it's just that I'm a bit confused about hashing and signing - certs can be signed using ECDSA or using SHA1; the data channel can be protected using SHA HMAC signing. (22.04.06) syzzer: TLS basically does the same, it uses (EC)DH for key exchange, ECDSA/RSA for proving identity and then exchanges AES/SHA keys for encrypting and authenticating data packets (22.04.33) syzzer: ECDSA certificates still use SHA (22.04.41) janjust: ah ok syzzer (22.04.49) syzzer: the data is first hashed, and the hash is signed using RSA or ECDSA (22.05.26) syzzer: HMAC-SHA is different from 'regular' SHA (22.06.03) janjust: if that's the case then all EC stuff can be kept outside of the data channel (22.06.12) cron2: mattock: as complete cross-talk - I've looked at the "new tickets" and there is nothing which I consider urgent for 2.3.3, so we can safely postpone that (22.06.13) syzzer: yes, I'm sure of that :) (22.06.33) mattock: cron2: ok, good (22.06.38) janjust: cron2: I added a few comments to some tickets, esp about the pkcs11 stuff (22.06.42) syzzer: data channel is symmetric cipher only (22.06.48) cron2: janjust: cool, thanks (22.06.55) plaisthos: cron2: I acked your IV_GUI_VER patch (22.07.09) syzzer: so, commitments then... (22.07.11) cron2: plaisthos: already pushing (22.07.21) plaisthos: cron2: :) (22.08.03) syzzer: I'm planning for a while now to at least review janjust's ECDSA patch, and even wanted to look into the ECDSA additions (22.08.19) syzzer: problem is, life keeps getting in the way :p (22.08.28) janjust: hehe I know that problem a bit too well (22.08.29) cron2: syzzer: haha :-) (22.08.30) syzzer: so I'm a bit afraid to make primises (22.08.34) syzzer: *promises (22.09.03) cron2: syzzer: as long as you don't feel annoyed with me poking you here and then :-) (22.09.20) syzzer: nope, I'm perfectly fine with that :) (22.10.00) syzzer: I do think I'll be able to ACK janjust's patch "soonish" (22.10.19) janjust: it's only been lying around for a year or so, what's a few more weeks? (22.10.48) syzzer: I need to dig in OpenSSL a bit further, I don't trust their API to do what one would expect... (22.11.03) plaisthos: syzzer: :D (22.11.30) plaisthos: like rsa_sign with the SIGN_FOR_TLS actually being to sign for TLS :D (22.12.09) syzzer: yeah, or their use functions with 'sslv23' in their name to enable cipher negotiation... (22.13.28) vpnHelper: RSS Update - gitrepo: Reduce IV_OPENVPN_GUI_VERSION= to IV_GUI_VER= <https://github.com/OpenVPN/openvpn/commit/7efaca734b8d633441ec3d7def2a2768864dedcf> (22.13.30) syzzer: as for polarssl, they've already included my patches in 1.3.3, and pkcs11-helper has included my patch in their tree, so I could send my patches to the mailinglist (22.14.06) syzzer: but then users would need an unreleased pkcs11-helper version on their system to get it to work (22.14.15) mattock: you guys still want some more punishment, or shall we call it a day after this topic? (22.14.20) janjust: only if they want pkcs11+ec support (22.14.42) plaisthos: ecdsa unfortunately will require me/someone else to patch external-key-management to something different than only RSA (22.14.44) cron2: syzzer: I think that stuff would go to 2.4, which we're not going to release for a few more months... (22.15.05) syzzer: no, for polar ec-support needs polar 1.3, which needs these patches for pkcs11-helper (22.15.38) cron2: (release planning is "2.3.3 in a few weeks, 2.4_alpha when the dual-stack stuff is fully merged and stable, and d12fk's stuff is in" (22.15.49) syzzer: plaisthos: polar itself needs more patches for ec+pkcs11 indeed (22.15.55) syzzer: openvpn could then just copy that code ;) (22.16.22) plaisthos: syzzer: that stuff is OpenSSL specific (22.16.28) mattock: cron2: that makes sense - all we need is d12fk to push his patches to the ml :P (22.16.33) plaisthos: like changing from rsa_method to ENGINE_* (22.16.42) syzzer: cron2: okay, I'll dig the polar 1.3 patches up soon then (22.17.59) syzzer: plaisthos: yes, you are right, management-external-key needs more patches for ecdsa too... (22.20.14) mattock: so, continue the discussion next week / on the ml? (22.20.53) syzzer: yep, I think so (22.20.55) cron2: yep... (22.21.00) mattock: excellent! (22.21.13) mattock: rather lengthy and technical meeting, but we made some good progress
