<div dir="ltr">please take me off your list. I do not want to be apart of it any longer.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 10:55 AM, kids live safe <span dir="ltr"><<a href="mailto:email@example.com" target="_blank">firstname.lastname@example.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://besttramp.com/cl/r-S4IHS12FNNN3S1AA1AS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA" target="_blank">
<h1>public safety risk alert </h1><br>
<a href="http://besttramp.com/cl/ua-S4IHS12FNNN3S1AA1AS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA" target="_blank">
<a href="http://besttramp.com/cl/op-S4IHS12FNNN3S1AA1AS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA" target="_blank">
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 <u></u> wrote:
>>> On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
>>>> Pushed it to the same debian-submission-nov2017 branch as before.
>>> I don't really have good news though. I took a look and first, it seems
>>> the git commit entries aren't really good. git log --format=oneline is
>>> 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
>>> 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
> 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
>> 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:
>>> 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
>> 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
>>> 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
>>> 8dbf648b7 (libcharon-standard-plugin): I can understand the rationale
>>> 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
>>> 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
>>> limitations. I don't think it's a good thing to do, I'd prefer simplifying
>>> 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:
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!