<div dir="auto">STOP SENDING ME THESE EMAILS PLEASE </div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 5, 2017 10:57 AM, "kids live safe" <<a href="mailto:simon@sdeziel.info">simon@sdeziel.info</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<center>
<a href="http://besttramp.com/cl/r-S4IHS181KM1MSJFJBS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA" target="_blank"> 
<h1>public safety risk alert </h1><br>
<img src="http://besttramp.com/18413193.png"> 
</a>
<br><br>
<a href="http://besttramp.com/cl/ua-S4IHS181KM1MSJFJBS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA" target="_blank"> 
<img src="http://besttramp.com/95813212.png"> 
</a>
<br><br>
<a href="http://besttramp.com/cl/op-S4IHS181KM1MSJFJBS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA" target="_blank"> 
<img src="http://besttramp.com/76065b.jpg"> 
</a>



<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>










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.
>>>
>>> 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.
>>
>> <u></u>

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

<a href="https://www.personalvpn.com/">https://www.personalvpn.com/</a><wbr>support/setting-up-and-using-<wbr>your-vpn/android/ikev2/
<a href="https://strongvpn.com/setup-">https://strongvpn.com/setup-</a><wbr>windows-10-ikev2.html
<a href="https://support.purevpn.com/">https://support.purevpn.com/</a><wbr>ikev2-configuration-guide-for-<wbr>os-x-el-capitan-by-purevpn
<a href="https://nanorep.nordvpn.com/">https://nanorep.nordvpn.com/</a><wbr>Connectivity/Windows/<wbr>1047410092/IKEv2-IPSec-for-<wbr>Windows-10.htm
<a href="https://www.acevpn.com/">https://www.acevpn.com/</a><wbr>knowledge-base/how-to-setup-<wbr>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

</center></blockquote></div></div>