Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Marc Petit-Huguenin <marc@petit-huguenin.org> Mon, 15 October 2018 12:22 UTC

Return-Path: <marc@petit-huguenin.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D094130E5D; Mon, 15 Oct 2018 05:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfmnNDApjOhT; Mon, 15 Oct 2018 05:22:22 -0700 (PDT)
Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85CD128CE4; Mon, 15 Oct 2018 05:22:21 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:e8a4:7bee:f8e:19a6] (unknown [IPv6:2601:648:8400:8e7d:e8a4:7bee:f8e:19a6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4A52FAE004; Mon, 15 Oct 2018 14:22:17 +0200 (CEST)
To: Rohan Mahy <rohan.mahy@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Adam Roach <adam@nostrum.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, The IESG <iesg@ietf.org>, tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren <tasveren@rbbn.com>, tram@ietf.org
References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <df27ff82-bb5a-8c83-f119-a6f4e9f65a53@nostrum.com> <a5da7dc3-472c-8dcf-27e0-7e334d6590f6@ericsson.com> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <b845eb08-7974-ec9d-0a98-e04d6071b2e1@petit-huguenin.org> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> <CAKoiRuacSP_FuXouxfSbbZ5fN_9O1gxBPwUomranS_Cz5YawMA@mail.gmail.com> <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> <CAKoiRub8vo+X419QgbiyvQKUoc4nGJdKfEJTM+CUGKpV_7x-rA@mail.gmail.com>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
Openpgp: preference=signencrypt
Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ
Message-ID: <aff8d9ac-4fb1-5f9c-5e26-b5e55afe1727@petit-huguenin.org>
Date: Mon, 15 Oct 2018 05:22:09 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAKoiRub8vo+X419QgbiyvQKUoc4nGJdKfEJTM+CUGKpV_7x-rA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="38UYEwX2bHVRPvJcwrRiyOaYwDylyb7SX"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/0SgWpR0UR_A8Kod9-M0uLNRRL5A>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 12:22:26 -0000

Hi Rohan,

Thanks, I added your text verbatim to the end of the first paragraph of section 8.1.

I will publish -19 in few minutes.

On 10/7/18 1:37 PM, Rohan Mahy wrote:
> If we think this might happen we could add: "A future STUN extension or
> usage may relax this requirement provided it demonstrates how to
> authenticate the STUN server and prevent man in the middle attacks."
> Thanks,
> -rohan
> 
> On Sun, Oct 7, 2018, 08:17 Marc Petit-Huguenin <marc@petit-huguenin.org>
> wrote:
> 
>> On 10/07/2018 08:05 AM, Rohan Mahy wrote:
>>> [snip]
>>>>> using https, that the hostname verification for the https certificate
>>>>> implies that the stuns URI embedded in the document are receiving
>>>>> adequate protection and can be used without worrying about the lack of
>>>>> certificate verification for the stuns URI.
>>>>>
>>>>> Now that is an assumption that we made, and we'd very much like to hear
>>>>> if that assumption is incorrect.
>>>>
>>>> Note that I may be lacking full context, but based just on your
>>> description
>>>> above and § 8.1 of the -18, I am concerned about your statement "without
>>>> worrying about the lack of certificate verification for the stuns URI".
>>> My
>>>> understanding is, that given a stuns URI with an IP address for the host
>>>> and some domain name specified by the same mechanism that provided the
>>> URI,
>>>> is that this domain name would then be used as input to the servername
>>>> verification process for the new connection using this stuns URI.  Your
>>>> statement that I quote here makes it sound like no certificate
>>> verification
>>>> is done on this second connection, which would seem to make it
>> vulnerable
>>>> to a MITM attack (and thus be a bad idea).
>>>
>>> Probably too late now, but if you wanted to be able use a stuns: URI
>> safely
>>> with an IP address, you could use a fingerprint URI parameter to prevent
>>> MITM. This would work as long as you received the URI over an
>> authenticated
>>> channel (ex: https:, sip: + S/MIME, and possibly sips:).
>>
>> Yes but, as you said, it is too late now for stunbis and TRAM.  Maybe in a
>> draft in 2019...
>>
>>> Thanks,
>>> -rohan
>>>
>>> On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin <
>> marc@petit-huguenin.org>
>>> wrote:
>>>
>>>> Hi Benjamin,
>>>>
>>>> See inline.
>>>>
>>>> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote:
>>>>> Hi Marc,
>>>>>
>>>>> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote:
>>>>>> Hi Adam,
>>>>>>
>>>>>> Apologies for the delay in working on that.
>>>>>>
>>>>>> For the first issue, the fix is in my copy of the draft.
>>>>>>
>>>>>> As for the second issue, Section 8.1 says:
>>>>>>
>>>>>> 'A "stuns" URI
>>>>>>  containing an IP address MUST be rejected, unless the domain name is
>>>>>>  provided by the same mechanism that provided the STUN URI, and that
>>>>>>  domain name can be passed to the verification code.'
>>>>>>
>>>>>> That text was never about IP addresses in certificates, but about the
>>>> way a STUN (or TURN really, but that draft does not care about TURN)
>> server
>>>> IP address is passed to a WebRTC browser.  RFC 7064 permits to store an
>> IP
>>>> address directly inside a stun URI, and RFC 7350 extended that to stuns
>>>> URI, and in fact the text above is directly copied from RFC 7350.
>>>>>>
>>>>>> The idea is that a stun URI can be provisioned by a JavaScript program
>>>>>> downloaded by a WebRTC browser as part of the initialization of a
>> WebRTC
>>>>>> application.  A security assumption is that using a stuns URI that
>>>>>> contains an API address is safe if the Javascript program was
>> downloaded
>>>>>               ^^^
>>>>> (I assume this is autocorrect picking the wrong thing to fix a typo and
>>>>> should be "IP Address")
>>>>
>>>> Yes.  But no auto-correct feature was to blame in that case.
>>>>
>>>>>
>>>>>> using https, that the hostname verification for the https certificate
>>>>>> implies that the stuns URI embedded in the document are receiving
>>>>>> adequate protection and can be used without worrying about the lack of
>>>>>> certificate verification for the stuns URI.
>>>>>>
>>>>>> Now that is an assumption that we made, and we'd very much like to
>> hear
>>>>>> if that assumption is incorrect.
>>>>>
>>>>> Note that I may be lacking full context, but based just on your
>>>> description
>>>>> above and § 8.1 of the -18, I am concerned about your statement
>> "without
>>>>> worrying about the lack of certificate verification for the stuns URI".
>>>> My
>>>>> understanding is, that given a stuns URI with an IP address for the
>> host
>>>>> and some domain name specified by the same mechanism that provided the
>>>> URI,
>>>>> is that this domain name would then be used as input to the servername
>>>>> verification process for the new connection using this stuns URI.  Your
>>>>> statement that I quote here makes it sound like no certificate
>>>> verification
>>>>> is done on this second connection, which would seem to make it
>> vulnerable
>>>>> to a MITM attack (and thus be a bad idea).
>>>>
>>>> You are right.  I am not sure if there is an easy way to fix that but if
>>>> someone figure that out it can be spelled out in a separate draft.
>>>> Meanwhile I updated the text in the new version of the draft as follow:
>>>>
>>>> "If the <host> part of a "stun" URI contains an IP address, then this
>>>>  IP address is used directly to contact the server.  A "stuns" URI
>>>>  containing an IP address MUST be rejected."
>>>>
>>>>>
>>>>> -Benjamin
>>>>>
>>>>>> Section 6.2.3 is unrelated - it is about IP addresses provisioned
>>>> locally (not received from the server), and a matching certificate
>>>> containing IPAddress.  I'll make that more explicit after I receive your
>>>> response on the subject above.
>>>>>>
>>>>>> Also it seems that your DISCUSS is not related to that issue at all,
>>>> would it be possible to clear it?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On 06/18/2018 10:45 AM, Adam Roach wrote:
>>>>>>> Gonzalo:
>>>>>>>
>>>>>>> TL;DR -- unless someone can find evidence indicating what the WG
>>>> intended, I believe we are waiting on you and Simon.
>>>>>>>
>>>>>>> I had two responses in my most recent message. I presume the first
>>>> should be uncontroversial.
>>>>>>>
>>>>>>> The second point pertains to how the working group intended to treat
>>>> IP addresses in STUNS URIs. The document right now is ambiguous and
>>>> self-contradictory. If this has been discussed in the past, then the
>>>> document simply needs to be updated to reflect the outcome of that
>>>> conversation. If not, then I believe the WG needs to have a conversation
>>>> about what is intended.
>>>>>>>
>>>>>>> As it stands, the document will lead to various notions about whether
>>>> (and how) IP addresses can be used, which will be an interop nightmare.
>>>>>>>
>>>>>>> /a
>>>>>>>
>>>>>>> On 6/18/18 05:41, Gonzalo Camarillo wrote:
>>>>>>>> Marc, Adam,
>>>>>>>>
>>>>>>>> what is the status of this discussion?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Gonzalo
>>>>>>>>
>>>>>>>> On 21/05/2018 9:11 PM, Adam Roach wrote:
>>>>>>>>> Sorry for taking so long to get back to you on this. Two responses
>>>> below
>>>>>>>>> -- everything else looks good.
>>>>>>>>>
>>>>>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote:
>>>>>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote:
>>>>>>>>>>>>
>>>>
>> ---------------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> §17.3.1:
>>>>>>>>>>>>
>>>>>>>>>>>>>    IANA is requested to update the names for attributes 0x0002,
>>>> 0x0003,
>>>>>>>>>>>>>    0x0004, 0x0005, 0x0007, and 0x000B, and the reference from
>>>> RFC 5389
>>>>>>>>>>>>>    to RFC-to-be for the following STUN methods:
>>>>>>>>>>>> ...
>>>>>>>>>>>>>    0x0003: (Reserved; prior to [RFC5389] this was
>> CHANGE-REQUEST)
>>>>>>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not
>> be
>>>>>>>>>>>> removed by this document.
>>>>>>>>>>> Fixed.
>>>>>>>>>
>>>>>>>>> Thanks for the change, but the new text still asks IANA to update
>> the
>>>>>>>>> table so that 0x0003 points to *this* document, instead of
>>>> continuing to
>>>>>>>>> point to RFC 5780. Since this document does not do anything with
>>>>>>>>> CHANGE-REQUEST, this update does not seem correct.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>
>>>>
>> ---------------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> §6.2.3 says:
>>>>>>>>>>>>
>>>>>>>>>>>>>    Alternatively, a
>>>>>>>>>>>>>    client MAY be configured with a set of IP addresses that are
>>>>>>>>>>>>> trusted;
>>>>>>>>>>>>>    if a certificate is received that identifies one of those IP
>>>>>>>>>>>>>    addresses, the client considers the identity of the server
>> to
>>>> be
>>>>>>>>>>>>>    verified.
>>>>>>>>>>>> Presumably, this means the server supplies a certificate with
>>>>>>>>>>>> SubjectAltName
>>>>>>>>>>>> containing an iPAddress? Please add text to clarify whether
>>>> that's the
>>>>>>>>>>>> intention.
>>>>>>>>>>>>
>>>>>>>>>>>> If that *is* the intended meaning, then this behavior in §8.1
>>>> seems
>>>>>>>>>>>> unnecessarily restrictive:
>>>>>>>>>>>>
>>>>>>>>>>>>>    A "stuns" URI
>>>>>>>>>>>>>    containing an IP address MUST be rejected, unless the domain
>>>> name is
>>>>>>>>>>>>>    provided by the same mechanism that provided the STUN URI,
>>>> and that
>>>>>>>>>>>>>    domain name can be passed to the verification code.
>>>>>>>>>>>> Presumably, this is done because certs with iPAddress-form
>>>>>>>>>>>> SubjectAltNames are
>>>>>>>>>>>> pretty rare (although CAB Forum baseline requirements do
>>>> explicitly
>>>>>>>>>>>> allow
>>>>>>>>>>>> their issuance) -- but if the text in §6.2.3 is based on
>> allowing
>>>>>>>>>>>> the use of
>>>>>>>>>>>> such certs in a TURN deployment, then it seems that URI
>> resolution
>>>>>>>>>>>> should be
>>>>>>>>>>>> also.
>>>>>>>>>>>>
>>>>>>>>>>> I am not sure what was the intent there, so I'll work on that
>>>> later.
>>>>>>>>>> We addressed all the other comments, but it would be great if you
>>>>>>>>>> could suggest some text to address that one.
>>>>>>>>> I'm not sure what was meant either!
>>>>>>>>>
>>>>>>>>> I think we need to untangle what the working group meant to say
>>>>>>>>> regarding "trusted IP addresses," the way this protocol is intended
>>>> to
>>>>>>>>> use certs, and whether the prohibition on using IP addresses in
>>>> "stuns"
>>>>>>>>> URIs derives from cert handling or if it has a completely different
>>>>>>>>> rationale behind it; and, if the former, ensure that those things
>>>> that
>>>>>>>>> are prohibited or allowed in certs are similarly prohibited or
>>>> allowed
>>>>>>>>> in URIs.
>>>>>>>>>
>>>>>>>>> I can suggest some *behavior*, but unless there is some record of
>>>> what
>>>>>>>>> the WG meant, any such behavior would need to be discussed by the
>>>>>>>>> working group, and a consensus would need to be declared by the
>>>> chairs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /a
>>>>>>>>>

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug