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

Marc Petit-Huguenin <petithug@acm.org> Sat, 08 September 2018 21:31 UTC

Return-Path: <petithug@acm.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 BEDEB1292AD; Sat, 8 Sep 2018 14:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.441
X-Spam-Level:
X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, 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 4YS31hzo-Ycs; Sat, 8 Sep 2018 14:31:46 -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 752D0128C65; Sat, 8 Sep 2018 14:31:46 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:4551:936:601e:ba39] (unknown [IPv6:2601:648:8400:8e7d:4551:936:601e:ba39]) (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 D6ACEAE004; Sat, 8 Sep 2018 23:31:42 +0200 (CEST)
To: Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Cc: tram-chairs@ietf.org, tram@ietf.org, tasveren@rbbn.com, The IESG <iesg@ietf.org>, draft-ietf-tram-stunbis@ietf.org
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org> <CABcZeBNk4KWA1Bzw7=i=Siie_6Vf7v-v2cfDyA4WvSAE2D9hrA@mail.gmail.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <CABcZeBN2=a90qbgo8MkihVFpO2bBzi2Ceepj3UpXVxAZJKJrxg@mail.gmail.com> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <CABcZeBMn1G8BT13bx3JTs04zwQk8K72+btj=xwC662F5AcANXg@mail.gmail.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Openpgp: preference=signencrypt
Autocrypt: addr=petithug@acm.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+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA=
Message-ID: <cbb48225-5089-9275-787c-38fa4504a6a4@acm.org>
Date: Sat, 8 Sep 2018 14:31:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBMn1G8BT13bx3JTs04zwQk8K72+btj=xwC662F5AcANXg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3PXJqCwOMi2eXFSmQQHib8fPLWzDTDrLk"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/IphW3mHuCmYfTYiEnNDvq1jmsAo>
Subject: Re: [tram] Eric Rescorla'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: Sat, 08 Sep 2018 21:31:50 -0000

Hi Eric,

Apologies for the delay in getting back to that.

I think that there is some misunderstanding in what STUNbis is trying to do, so please see my comments inline.

On 06/18/2018 10:43 AM, Eric Rescorla wrote:
> Hi folks,
> 
> I've reviewed the new version, but I don't think that the biddown
> discussion makes much sense.
> 
> To recap, there are two hashes here:
> 
> - The hash which you use to store the password with (currently mostly MD5)
> - The hash you use to compute the MAC (currently SHA-1).
> 
> First, let's stipulate that MD5 isn't a great choice here, though SHA-1
> isn't a great choice
> either for pwd hashing You want Argon or the like. With that said, there's
> no sensible
> biddown attack on that hash because it's a per-server feature, not a
> per-transaction
> feature. So, as long as the server has MD5-hashed passwords, the situation
> is bad.

In no place in STUNbis we are proposing to use SHA-1 for password encryption, so I am not sure where that come from.  What we propose is:

- Establish a registry for new password algorithms (section 18.5), so algorithms like Argon2 could be added later (but note that our own proposals to add more password algorithms were rejected by the working group).
- Add a new password algorithm to that registry, namely SHA-256.
- Register MD5 as an initial password algorithm for backward compatibility purpose.

As for the biddown protection itself, it is my recollection that it happened more or less like that:


INT. MEETING ROOM - DAY

One of the co-editors of STUNBis stands at the microphone:

                           CO-EDITOR
                 We added SHA-256 protection for passwords
                 in STUNBis.

                           SOMEONE (V.O.)
                 As MD5 still need to be supported, you need to add
                 protection for bid-down attacks.

CLOSE-UP on CO-EDITOR ROLLING HIS EYES

                           CO-EDITOR
                 OK, I'll work on that.

Four to eight months has passed.

INT. ANOTHER MEETING ROOM - DAY

The same co-editor of STUNBis stands at the microphone:

                           CO-EDITOR
                 We added a nice mechanism to prevent bid-down
                 attacks on passwords.  Any comments?

                           THE ROOM
                 (silence)

                           CO-EDITOR
                 Moving on...


> 
> The second topic is the hash used to compute the MAC. However, I don't see
> how
> this gives you sensible biddown protection because that hash is also used
> to compute
> MAC over the negotiation: an attacker who has compromised a MAC which the
> server
> supports will quite likely be able to forge a MAC over the transcript as
> well. This is,
> I suppose, potentially useful as a defense against some other weakness
> (e.g.,
> version #), but I don't really see how the current design helps against
> attacks on the
> MAC.

There is no biddown attack protection for the MAC, as stated in Section 16.3:

"The bid-down protection mechanism described in this document is new,
 and thus cannot currently protect against a bid-down attack that
 lowers the strength of the hash algorithm to HMAC-SHA1."

What we put in place is a plan for *future* versions of STUN to get biddown protection for the MAC.  That's it, no more, no less.

> 
> You might think that there was a MAC which was easier to reverse to find
> the original
> password, but the defense you have here doesn't help with that because the
> on-path attacker can do a bid-down and use the client as a MAC oracle for
> any MAC the client supports.
> 
> So, I still don't understand what this is supposed to do. Happy to have a
> call if you
> think that helps
> 
> -Ekr
> 
> 
> 
> 
> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo Camarillo <
> Gonzalo.Camarillo@ericsson.com> wrote:
> 
>> Marc, Eric,
>>
>> what is the status of this discussion?
>>
>> Thanks,
>>
>> Gonzalo
>>
>> On 04/05/2018 2:35 AM, Eric Rescorla wrote:
>>>
>>>
>>> On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin <petithug@acm.org
>>> <mailto:petithug@acm.org>> wrote:
>>>
>>>     On 04/22/2018 05:22 PM, Eric Rescorla wrote:
>>>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
>> petithug@acm.org <mailto:petithug@acm.org>>
>>>     > wrote:
>>>     >
>>>     >>
>>>     >>>>      For a request or indication message, the agent MUST
>> include the
>>>     >>>>      USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY
>>>     >> attributes
>>>     >>>>      in the message unless the agent knows from an external
>> indication
>>>     >>>>      which message integrity algorithm is supported by both
>> agents.  In
>>>     >>>>      this case either MESSAGE-INTEGRITY or
>> MESSAGE-INTEGRITY-SHA256 MUST
>>>     >>>>      be included in addition to USERNAME.  The HMAC for the
>> MESSAGE-
>>>     >>>
>>>     >>> This text appears to conflict with S 7.3 of 5245-bis, which says:
>>>     >>
>>>     >> [text missing]
>>>     >>
>>>     >> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure
>> for
>>>     >> stunbis does not apply.
>>>     >>
>>>     >
>>>     > I hear what you're saying, but publishing two documents at the
>> same time
>>>     > which
>>>     > make contrary recommendations about the same basic protocol is
>> un-good.
>>>
>>>     Sure, but wouldn't it be simpler to have rfc5245bis using stunbis
>>>     and have them updating their text, more than adding some tortuous
>>>     text in stunbis?
>>>
>>>     >
>>>     >
>>>     >>>      The STUN usage must specify which transport protocol is
>> used, and
>>>     >> how
>>>     >>>>      the agent determines the IP address and port of the
>> recipient.
>>>     >>>>      Section 8 describes a DNS-based method of determining the
>> IP
>>>     >> address
>>>     >>>>      and port of a server that a usage may elect to use.  STUN
>> may be
>>>     >> used
>>>     >>>>      with anycast addresses, but only with UDP and in usages
>> where
>>>     >>>>      authentication is not used.
>>>     >>>
>>>     >>> Why this restriction? You should be able to use anycast with
>> long-term
>>>     >>> AUTH for (say) TURN.
>>>     >>
>>>     >> https://www.ietf.org/mail-archive/web/behave/current/
>> msg03582.html
>>>     <https://www.ietf.org/mail-archive/web/behave/current/msg03582.html>
>>>     >>
>>>     >> I think that the decision of permitting Anycast should be left to
>> each
>>>     >> STUN Usage.  Basic STUN Usage does not use authentication and use
>> only a
>>>     >> one round trip for the Binding transaction, so Unicast can be
>> used.
>>>     >>
>>>     >
>>>     >> OTOH, TURN and ICE should probably say something about that, so I
>> added a
>>>     >> new bullet point in Section 13:
>>>     >>
>>>     >>    o  If Anycast addresses can be used for the server in case TCP
>> or
>>>     >>       TLS-over-TCP, or authentication are used.
>>>     >>
>>>     >
>>>     > Are you leaving this text in? That seems very confusing.
>>>
>>>     In isolation yes, but I think it makes sense which the text before
>>>     the bullet points:
>>>
>>>        A STUN usage defines how STUN is actually utilized -- when to send
>>>        requests, what to do with the responses, and which optional
>>>        procedures defined here (or in an extension to STUN) are to be
>> used.
>>>        A usage also defines:
>>>
>>>     [...]
>>>
>>>        o  If Anycast addresses can be used for the server in case TCP or
>>>           TLS-over-TCP, or authentication are used.
>>>
>>>
>>> What is the need for the restriction at all.
>>>
>>>
>>>
>>>     >>>>      transaction over UDP or DTLS-over-UDP is also considered
>> failed if
>>>     >>>>      there has been a hard ICMP error [RFC1122].  For example,
>> assuming
>>>     >> an
>>>     >>>>      RTO of 500ms, requests would be sent at times 0 ms, 500
>> ms, 1500
>>>     >> ms,
>>>     >>>>      3500 ms, 7500 ms, 15500 ms, and 31500 ms.  If the client
>> has not
>>>     >>>>      received a response after 39500 ms, the client will
>> consider the
>>>     >>>>      transaction to have timed out.
>>>     >>>
>>>     >>> I note that these recommendations now seem crazily long. I
>> assume the
>>>     >>> WG had consensus on this, but I wanted to note it.
>>>     >>
>>>     >> Not just the WG, also the IESG that approved RFC 5389 too as, but
>> for the
>>>     >> addition of "or DTLS-over-UDP", this is the same text than in RFC
>> 5389.
>>>     >>
>>>     >
>>>     > Yes, I know. My point is that while they might have bee sensible
>> when
>>>     > 5389 was published they *now* seem crazily long. Did the WG
>> explicitly
>>>     > decide not to update them?
>>>
>>>     No, nobody ever suggested that there was an issue there.
>>>
>>>
>>> OK, well, this seems like it should be considered, then, because this
>>> doesn't
>>> match modern practice.
>>>
>>>
>>>
>>>     > This would be good to explain.
>>>
>>>     New text:
>>>
>>>        [...]
>>>        containing the subjectAltName of that certificate.  The test on
>> the
>>>        MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction
>> is
>>>        authenticated and that the client implements this specification
>> and
>>>        so can process the ALTERNATE-DOMAIN attribute.
>>>
>>>
>>> All right.
>>>
>>>
>>>     >
>>>     >
>>>     >>>>      o  What authentication and message-integrity mechanisms
>> are used.
>>>     >>>>
>>>     >>>>      o  The considerations around manual vs. automatic key
>> derivation
>>>     >> for
>>>     >>>>         the integrity mechanism, as discussed in [RFC4107].
>>>     >>>>
>>>     >>>>      o  What mechanisms are used to distinguish STUN messages
>> from other
>>>     >>>
>>>     >>> Why is this required? It seems like that's a generic STUN
>> feature.
>>>     >>
>>>     >> That text is identical to the text in RFC 5389.  RFC 5764/7983 is
>> one such
>>>     >> mechanism, but there is nothing that prevent another protocol
>> stack to use
>>>     >> a different mechanism (inference, shim, etc...)
>>>     >>
>>>     >
>>>     > But ultimately no matter what the other protocol provides for
>> demux, STUN
>>>     > has its
>>>     > own demux.
>>>
>>>     In fact I think that the reason for that item was because
>>>     FINGERPRINT can also be used to demux STUN traffic, but it is
>>>     optional.  So an STUN Usage needs to tell if FINGERPRINT is
>>>     mandatory (like in ICE).
>>>
>>>
>>> This should be explained.
>>>
>>>
>>>     >>>
>>>     >>>>      that is not readily subject to offline dictionary attacks.
>>>     >>>>      Protection of the channel itself, using TLS or DTLS,
>> mitigates
>>>     >> these
>>>     >>>>      attacks.
>>>     >>>>
>>>     >>>>      STUN supports both MESSAGE-INTEGRITY and
>>>     MESSAGE-INTEGRITY-SHA256,
>>>     >>>>      which is subject to bid down attacks by an on-path
>> attacker.
>>>     >>>
>>>     >>> By an on-path attacker who can forge HMAC-SHA1 in real-time?
>>>     That's a
>>>     >>> pretty serious adversary, so you should clarify here
>>>     >>>
>>>     >>
>>>     >> New text:
>>>     >>
>>>     >>    STUN supports both MESSAGE-INTEGRITY and
>> MESSAGE-INTEGRITY-SHA256,
>>>     >>    which is subject to bid down attacks by an on-path attacker
>> that
>>>     >>    would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving
>>>     only the
>>>     >>    MESSAGE-INTEGRITY attribute and exploiting a potential
>>>     vulnerability.
>>>     >>    Protection of the channel itself, using TLS or DTLS, mitigates
>>>     these
>>>     >>    attacks.  Timely removal of the support of MESSAGE-INTEGRITY
>> in a
>>>     >>    future version of STUN is necessary.
>>>     >>
>>>     >
>>>     > I still don't understand the capabilities you seem to believe the
>>>     attacker
>>>     > has.
>>>     > Can you describe the exact attack.
>>>     >
>>>
>>>     1. Vulnerability is found in HMAC-SHA1
>>>     2. Client Alice still supports M-I and M-I-256, does not know what
>>>     version of STUN server Bob supports and so send both.
>>>     3. On-path attacker removes M-I-256.
>>>     5. stunbis server Bob thinks that Alice is an RFC 5389 client and
>>>     continue with that protocol.
>>>
>>>
>>> This seems like an extremely weak attack. In general, any protocol of
>>> this type is as strong
>>> as the weakest integrity algorithm it supports, so it's not that the
>>> protocol has a downgrade
>>> attack, but rather that the minimum algorithm supported is one you don't
>>> trust as much
>>> as you might like.
>>>
>>> -Ekr
>>>
>>>
>>>     --
>>>     Marc Petit-Huguenin
>>>     Email: marc@petit-huguenin.org <mailto:marc@petit-huguenin.org>
>>>     Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.
>> org>
>>>     Profile: https://www.linkedin.com/in/petithug
>>>     <https://www.linkedin.com/in/petithug>
>>>
>>>
>>
> 


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