What is this? Brooke
> On Dec 5, 2017, at 8:55 AM, kids live safe <si...@sdeziel.info> wrote: > > public safety risk alert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 wr= ote: >>> 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=3Doneline i= s >>> 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 :-) >=20 > Ok :) >> >>> For > the commit contents: >>> >>> 1aa409a5 (mass plugin enable): NACK again; I > won't enable that many stu= ff >>> (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. >=20 > It might help to do one commit per > feature (maybe one commit for consiste= nt > groups) too so I can cherry-pick > commits. >=20 >> 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. >=20 > Yes, that could make sense. > If no one asks for them, I prefer to keep the= m > disabled in order to > reduce attack surface, because strongSwan is really = a > beast. Even if > there's the plugin architecture, plugins are default-enabl= ed > and that > means a lot of exposed stuff. >=20 > 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. >=20 > 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 :-) >=20 > > No problem :) >> >>> 766d4f0d (ha disable): not really sure; it's way > easier to have a custo= m >>> 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. >=20 > > 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 befor= e >>> > release >> >> It is disabled by default as Simon already outlined for the > reason to >> be an opt-in. >=20 > Yes, by =E2=80=9Cdisabling=E2=80=9D 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. >=20 > 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 definite= ly >>> 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 wi= th >>> its > >>> limitations. I don't think it's a good thing to do, I'd prefer simplify= > ing >>> the >>> secure uses cases, like pubkeys-based ones. >> >> >=20 > 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/i= > kev2/ https://strongvpn.com/setup-windows-10-ikev2.html > https://support.purevpn.com/ikev2-configuration-guide-for-os-x-el-capitan-b= > y-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
