[Pkg-swan-devel] Bug#848890: public safety risk alert KUJf

spowell5400 spowell5400 at gmail.com
Tue Dec 5 17:01:34 UTC 2017

Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: kids live safe <simon at sdeziel.info> Date: 12/5/17  10:55 AM  (GMT-05:00) To: 848890 at bugs.debian.org Subject: public safety risk alert KUJf 

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  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

>> 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:


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!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-swan-devel/attachments/20171205/276a59aa/attachment-0001.html>

More information about the Pkg-swan-devel mailing list