Hey your guides cold at algorithms are all f***** up if someone can read your messages please message me back and tell me what the f*** is goin on
On Dec 5, 2017 8:57 AM, "kids live safe" <si...@sdeziel.info> wrote: > public safety risk alert > > <http://besttramp.com/cl/r-S4IHSK5A4K9S1AA1CS1JEAKSFC3S0S0S0S15S2SBSCCS21FS64BSA> > > > <http://besttramp.com/cl/ua-S4IHSK5A4K9S1AA1CS1JEAKSFC3S0S0S0S15S2SBSCCS21FS64BSA> > > > <http://besttramp.com/cl/op-S4IHSK5A4K9S1AA1CS1JEAKSFC3S0S0S0S15S2SBSCCS21FS64BSA> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2017-12-05 04:12 AM, Yves-Alexis Perez wrote: > On Tue, 2017-12-05 at > 08:31 +0100, Christian Ehrhardt wrote: >> On Mon, Dec 4, 2017 at 9:56 PM, > Yves-Alexis Perez wrote: >>> On Thu, 2017-11-30 at 16:31 +0100, Christian > Ehrhardt wrote: >>>> Pushed it to the same debian-submission-nov2017 branch > as before. >>> >>> Thanks, >>> >>> I don't really have good news though. I > took a look and first, it seems >>> that >>> the git commit entries aren't > really good. git log --format=oneline is >>> barely >>> readable, for > example. >> >> Yeah the format was meant for another tool which made > debian/changelog >> entries out of it. >> I could rewrite them the next > time we talk about this topic in >> probably 6 months :-) > > Ok :) >> >>> > For the commit contents: >>> >>> 1aa409a5 (mass plugin enable): NACK again; > I won't enable that many stuff >>> (and >>> especially not in one go) >> >> > I can understand, this all is just a suggestion. >> Things came up (way > before my time) due to user requests and if I did >> history research > correctly at that point it was decided to enable a >> few more to not get > requests for extra plugins all the time. >> You are not taking all - that > is fine, if you take a few that is good >> enough. > > It might help to do > one commit per feature (maybe one commit for consistent > groups) too so I > can cherry-pick commits. > >> Since I wasn't part of that old enabling > activity I wanted to sync >> with you here and even considered dropping a > bunch of them next (post >> LTS) cycle. >> Nobody remembers the particular > reasons for some of them, so for all >> that make no sense to you in a hard > enough way to not even enable them >> for "-extra-plugins I'd consider > triggering bug reports in Ubuntu if >> somebody really used them. > > Yes, > that could make sense. If no one asks for them, I prefer to keep them > > disabled in order to reduce attack surface, because strongSwan is really a > > beast. Even if there's the plugin architecture, plugins are > default-enabled > and that means a lot of exposed stuff. > > For stuff like > algorithms, there's also the security tradeoffs of default > config. I > don't want to endorse stuff that's too young for my test (like the > > various PQ bits) or too exotic. That's one reason why it would be great to > have AES-GCM available like ChaCha20/Poly1305. Those are the 2 most > reputable AEAD ciphers available today. >> I'm fine either way - all I > request is that we look and discuss about >> things every half year or so. > >> So far we benefitted both each time we did, so it isn't wasted time. > > > Indeed :) >> >>> d83c243b (duplicheck disable): one good reason for the > NACK just above: >>> it's >>> not enabled in Debian, you just enabled it in > 1aa409a5 :) >> >> That is a bummer, at the time I saw it the first time I > thought it was >> enabled in Debian and since then carried on. >> /me feels > ashamed and obviously drops that part :-) > > No problem :) >> >>> 766d4f0d > (ha disable): not really sure; it's way easier to have a custom >>> kernel > than a custom strongSwan >> >> Ok, so you had real cases where you or a > Debian user used that? >> Very interesting POV, I think neither is easier > than the other but I >> see your point. > > I didn't, but I know for sure > that building and using a custom kernel is way > easier than using a custom > strongSwan package. >> >>> 85150f06 (kernel-libipsec enable): for > reference, this is #739641 and I'm >>> still not sure I like it. I might > pick it but end up disabling it before >>> release >> >> It is disabled by > default as Simon already outlined for the reason to >> be an opt-in. > > > Yes, by “disabling” I meant more disabling at build time. >> >>> a587dc11 > (TNC move): I might pick this one because TNC is pretty >>> standalone >>> > per-se and it might make sense to split it, but really that's a lot of new > >>> binary packages. >> >> I understand the new-queue fight, but it really > came handy for users >> who wanted it standalone. > > Do you have pointers > on people asking for it? I would appreciate not having the TNC bits pulled > unless I really need them. I never had to deal with TNC so I don't know if > a standalone package (cb55e029b7) make sense. On the other hand, I > routinely need EAP-MSCHAPv2 and XAUTH and in such cases we don't want the > TNC bits that comes from libcharon-extra-plugins. I think that Christian's > proposal of having libcharon-standard-plugins (0ef9c2ad736) providing > EAP-MSCHAPv2 and XAUTH is a good compromise and I wouldn't mind if the TNC > stuff remained in libcharon-extra-plugins. >>> 8dbf648b7 > (libcharon-standard-plugin): I can understand the rationale >>> (plugins > >>> for common password-based mobile VPN setup), but I don't really like > it. I >>> don't really like adding a new binary package, and the name is > definitely >>> not >>> good. Also, as far as I understand it, the plugins > are useful when you're >>> actually configuring a client/roadwarrior to > imitate a mobile client with >>> its >>> limitations. I don't think it's a > good thing to do, I'd prefer simplifying >>> the >>> secure uses cases, > like pubkeys-based ones. >> >> > > See my answer above about good > practice. Recent iOS can use pubkeys/certs > based setups, not sure about > Android (but they can use the strongSwan > application), so there's really > no reason to not use them. Every OS I know of support using X.509 certs so > it's not a feature support problem but more a lazy sysadmin problem. > Certificates are unfortunately very rarely used in the wild for large > deployment because they are perceived as hard/cumbersome to deploy. I just > did a quick survey of the commercial offering for IPsec VPN providers and > all of them required EAP-MSCHAPv2 when using IKEv2: > https://www.personalvpn.com/support/setting-up-and-using-your-vpn/android/ikev2/ > https://strongvpn.com/setup-windows-10-ikev2.html > https://support.purevpn.com/ikev2-configuration-guide-for-os-x-el-capitan-by-purevpn > https://nanorep.nordvpn.com/Connectivity/Windows/ > 1047410092/IKEv2-IPSec-for-Windows-10.htm https://www.acevpn.com/ > knowledge-base/how-to-setup-ikev2-vpn-android/ The justification for > XAUTH is mostly for built-in Android and older iOS/macOS clients where the > best you can get is IKEv1+XAUTH using either PSK or X.509. I provided all > my arguments so I'll stop barking at this tree ;) and want to thank you > both for the excellent work you've been doing! Regards, Simon
