Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

[Göran Selander <[e-mail]>]

Hi Dominique,

Thanks! A few more comments inline.

From: Lake <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Wednesday, 1 April 2020 at 15:34
To: Göran Selander <goran.selander=[e-mail]>, Eric Rescorla <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hello Göran,

Happy to contribute!
Some replies inlined.
Best regards,

Dominique

De : Lake <[e-mail]<mailto:[e-mail]>> on behalf of Göran Selander <goran.selander=[e-mail]<mailto:goran.selander=[e-mail]>>
Date : Wednesday 1 April 2020 13:24
À : Dominique Barthel <[e-mail]<mailto:[e-mail]>>, Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hi Dominique,

Thanks for joining the discussion! I haven’t read the paper yet but have some questions:


-          Does this procedure for complying with the duty cycle apply to normal traffic as well as the network join/on-boarding phase? We noted in a previous mail thread that the rules were more strict for normal traffic than for on-boarding.
[DB] can you please point me at this thread?

[GS] I’ll try to find it, this was over a year ago.

[DB] indeed, EN 320200-1 section 5.4.2 has language that the duty-cycle limit applies to steady state operation, not startup etc.
"The representative period shall be the most active one in normal use of the device. As a guide "Normal use" is considered as representing the behaviour of the device during transmission of 99 % of transmissions generated during its operational lifetime.
Procedures such as setup, commissioning and maintenance are not considered part of normal operation."
The problem is that if you buy a LoRaWAN module from an OEM and write your upper layer stack on top of it, there is no way to call the LoRaWAN stack API with a flag "don't count this frame towards the duty-cycle allowance". I guess this flag would be totally abused. So the situation I see today is that the stack will refuse to send your AKE packet with the error message "out-of-duty-cycle, sorry, come back later", because the module manufacturer is the one who got the certification and is responsible for proper behaviour.
I agree that there might be hope for a better future, but for easier adoption I suggest we try to fit the enveloppe that I described.

[GS] This makes sense if there is no other robust solution to distinguish between them.

-

-          What does ”taking into account 2 repetitions per packet (I.e. 3 transmissions)” mean? That air-time for the protocol messages needs to be divided by 3?
[DB] because this is meant to be a worst case, I'm pretending it takes 3 attempts for a radio frame to make it through. So yes, the air-time per successful messages is 3 times less.

-

-          Does ”Or better yet, in only half or a third of that” mean another factor 2 or 3? (This sounds reasonable, just checking.)
[DB] indeed, I meant another factor of 2 to 3.  Let see what we can do with this factor, and maybe discuss later if we can relax this a bit.

-

-          Since protocol messages are going in both directions, does 36 seconds account for the sum of total air-time for messages going in both directions, independently (within reasonable bounds) of delay between messages?
[DB] the 36 seconds is the cumulated amount allowed for one transmitter (e.g., an IoT device, or a "base-station" known as Radio Gateway in LoRaWAN's parlance) over the last 3600 seconds, at any time. So, not quite independent of delay between messages.
[DB] the 36 seconds I proposed are only for uplink communication (from device to base station).
[DB] The downlink duty-cycle limits are harder to estimate, because: (1) the RGW duty-cycle is shared between downlink communications to all devices, (2) the downlink communication by a RGW can take place either on the same frequency by the uplink it's responding to (with typically 1% duty-cycle), or on a dedicated frequency that has 10% duty-cycle, (3) if a RGW has run out of duty-cycle, the Network Server will chose another RGW to sent the downlink, if device is in coverage of multiple RGW.
[DB] I would suggest to ignore the downlink duty-cycle issue altogether, it's a serious network problem but totally out of control of a single device. Let's just put as a requirement that the volume of data on the  downlink shall be similar to that of the uplink. If we are talking kBytes of downlink, then we need to revisit the question. The downlink is such a scarce resource that some operators have a pay-per-use policy, typically a few cents per downlink message (with a payload in the 50-250 bytes range).

[GS] Another question: the 1-2 minutes waiting time for the technician, is this per device? If there are dozens of devices deployed simultaneously could they interfere with each other so that the waiting time does not increase linearly?

Thanks
Göran


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 1 April 2020 at 10:49
To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>, Göran Selander <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: LoRaWAN use case; Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Hello Göran, Eric, all,

I've read draft-ietf-lake-reqs-02 and the ensuing discussions.
I can contribute to the description of the LoRaWAN constraints.

@Göran, I'm sorry to say that your text does not fairly depict the duty cycle limitation of Sub-GHz systems in Europe.
It is not true that after you have transmitted for 1 second, you have to wait for 99 seconds before your next transmission (to oblige the 1% duty cycle limit).
I highly recommend reading this paper [1].
Not only does it have very clear depictions of Sub-GHz sub-bands and their duty-cycle limitations, but it also contains pointers to the authoritative documents, and discussions on how systems like Sigfox and LoRaWAN comply with the regulations. It even has considerations on the impact of duty-cycle limitations for meshed networks using CoAP.

In a nutshell, the duty-cycle is evaluated on a 1-hour sliding window. It is legal to burst out transmissions to a total of 36 seconds air time on a 1%-duty-cyle sub-band, and then pause for the rest of the hour.

As a telco operating commercial LoRaWAN networks in Europe, here are my observations:
It's perfectly ok to have a technician stand one or two minutes next to the IoT device he/she has just provisioned, in order to make sure everything is up and running.
It's not ok to have the technician stand an hour next to the device, just because the provisioning protocol surpassed the 36 seconds air-time credit given in the first hour.
Hence the challenge to this Working Group (fairly decent worst case):
Can you make some useful/secure key exchange happen within 36 seconds of air-time at LoRaWAN SF12 data rate, taking into account 2 repetitions per packet (I.e. 3 transmissions)?
Or better yet, in only half or a third of that, because you want to give some air-time to the lower layer MAC frames and to the application itself.
Best regards,

Dominique

[1] Saelens, Martijn & Hoebeke, Jeroen & Shahid, Adnan & De Poorter, Eli. (2019). Impact of EU duty cycle and transmission power limitations for sub-GHz LPWAN SRDs: an overview and future challenges. EURASIP Journal on Wireless Communications and Networking. 2019. 10.1186/s13638-019-1502-5. https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1502-5

De : Lake <[e-mail]<mailto:[e-mail]>> on behalf of Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Date : Tuesday 31 March 2020 02:57
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Lake] WGLC for draft-ietf-lake-reqs-01

> >    LoRaWAN has a variable MTU depending on the Spreading Factor (SF).
> >    The higher the spreading factor, the higher distances can be achieved
> >    and/or better reception.  If the coverage and distance allows it,
> >    with SF7 - corresponding to higher data rates - the maximum payload
> >    is 222 bytes.  For a SF12 - and low data rates - the maximum payload
> >    is 51 bytes on data link layer.
> >
> >    The benchmark used here is Data Rates 0-2 corresponding to a packet
> >    size of 51 bytes [LoRaWAN].  The use of larger frame size depend on
> >    good radio conditions which are not always present.  Some libraries/
> >    providers only support 51-bytes packet size.
> >    providers only support 51-bytes packet size.
> >
> > I'm not sure what I am supposed to do with this: it seems like we have
> > packet sizes that range from 51 to 222. I think what this is saying is
> > that I am supposed to assume 51-byte packets, but even that is
> > unclear.
>
>
>
> GS: This text was formed out of the SecDispatch discussion. Section
> 2.10.0 and other parts of the text highlights the need for
> benchmarks. Section 2.10.1.1 indicates that the benchmark for LoRaWAN
> is a packet size of 51 bytes at link layer. The benchmarks are now
> compiled in 2.10.4, hope it is more clear now.

Not really, no. What I am looking for is something that clearly
states:

   (1) the cost at various sizes (packets, flights, etc.)
   (2) what is expected/known to be achievable with a given technology

This is not giving me that, which seems to be what's needed here.




> GS: 2.10.2 speaks about the duty cycle of 1%:
>
>    “A duty cycle of 1% implies that the time to complete a
>
>    fragmentation of the payload increases by at least 10,000%. This
>
>    limitation determines how long time the device will have to wait for
>
>    next use, which encourages the reduction of the message size as much
>
>    as possible.”
>
> For each packet, wait 100 times the transmission time for next
> packet. This excludes potential retransmissions due to lost messages
> or errors etc.

OK, so what's the curve of handshake latency cost for protocols with
various message sizes? That's (in part) what I'm asking for.


> GS: The specified LoRaWAN packet size is at link layer. If fragmention
> with Blockwise, this results in multiple CoAP messages + increase of
> total CoAP header overhead.

Right, so I'm looking for this document to tell me that.


> > The answers in this document are frankly pretty unsatisfactory. For
> > instance, it says:
> >
> >    Considering the duty cycle of LoRaWAN and associated unavailable
> >    times, the round trips and number of LoRaWAN packets needs to be
> >    reduced as much as possible.
> >
> >  What I would expect to see is something to the effect of: "this is
> > the incremental cost in {power, bandwidth, time to complete} of an
> > additional packet and therefore we should be able to keep to <X
> > packets",
>
> GS: This, together with the benchmarks, was requested in
> Secdispatch. That lead to the spreadsheets and comparison between TLS
> handshake and EDHOC e.g. Time-on-Air, presented in the virtual interim
> in March 2019 and in the BoF at IETF 105.. The spreadsheets are still
> tavailable:
>
> https://github.com/EricssonResearch/EDHOC/tree/master/docs<https://protect2.fireeye.com/v1/url?k=50dac494-0c50e65b-50da840f-0cc47ad93ea4-3960fa3fbf9bcace&q=1&e=bcff050e-f064-47b0-bef0-68edfc8b1ac2&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEDHOC%2Ftree%2Fmaster%2Fdocs>
>
> https://github.com/EricssonResearch/EDHOC/blob/master/docs/LoRaWAN_ToA.xlsx<https://protect2.fireeye.com/v1/url?k=9c8699f1-c00cbb3e-9c86d96a-0cc47ad93ea4-683c68ed31cdfad5&q=1&e=bcff050e-f064-47b0-bef0-68edfc8b1ac2&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEDHOC%2Fblob%2Fmaster%2Fdocs%2FLoRaWAN_ToA..xlsx>

Yeah, these spreadsheets aren't quite what I want because they are
focused on DTLS vs. EDHOC rather than on what happens with various
protocol sizes. The idea here is to get the relevant curve, so for
instance, "time to handshake completion by size of Message 1
controlling for Message 2" or where the cliffs are, or something, so
that we know what we are designing for.




> > but really the only thing we get is in 2.10.4, which says:
> >
> >    Considering that an AKE protocol complying with these
> >    requirements is expected to have at least 3 messages, the optimal AKE
> >    has 3 messages and each message fits into as few frames as possible,
> >    ideally 1 frame per message.
> >
> > The problem here is that we *know* we are going to have to accept
> > some level of messages that span multiple radio units and so
> > getting a sense of where the real boundaries are is critical,
> > but this document frankly isn't much of a help.
>
> GS: For the certificate case we do need messages that span multiple
> radio units, but not necessarily for PSK or RPK. And those are the
> most relevant cases for constrained IoT. In LoRaAlliance, for example,
> there is work on an RPK-based authentication scheme. We added new text
> in 2.10..4 about this limitation of certificate based authentication.

Well, with RPK and signatures you will still be over three packets
because the server's first message contains both (1) a DH share
and (2) a signature, for a combined minimum of 96 bytes. So, as far
as I can tell, we have this problem. And it's also not clear (at least
to me) if there is incremental cost within the packet cliffs. Is
the answer "no"?




> > SPECIFIC COMMENTS:
> > Abstract:
> >    authenticated key exchange protocol for OSCORE.  This draft is in a
> >    working group last call (WGLC) in the LAKE working group.  Post-WGLC,
> >    the requirements will be considered sufficiently stable for the
> >    working group to proceed with its work.  It is not currently planned
> >    to publish this draft as an RFC.
> >
> > You'll want to change this, obviously.
>
> GS: Some verbs needs to change to past tense, if that is what you mean?

Well, I would have removed this text entirely.


> > S 2.1.
> >    COSE provides the crypto primitives for OSCORE.  The AKE shall
> >    specify how COSE can be reused for identification of credentials and
> >    algorithms of OSCORE and the AKE, as extension point for new schemes,
> >    and to avoid duplicated maintenance of crypto library.
> >
> > This is the first of a number of places where this document tries
> > to pre-make design decisions. The requirement here is lightwightness,
> > not COSE. In general, this document should not be making any
> > such decisions; I've tried to call them out but may have missed
> > some.


> GS: See response to Richard.

Yeah, I don't think "strongly recommended" is appropriate either. This
is not properly the business of the requirements doc.



> >    Moreover, the AKE must support transport over CoAP.  Since the AKE
> >    messages most commonly will be encapsulated in CoAP, the AKE must not
> >    duplicate functionality provided by CoAP, or at least not duplicate
> >    functionality in such a way that it adds extra costs in terms of code
> >    size, code maintenance, etc.  It is therefore assumed that the AKE is
> >
> > This too is too strong. If it required .001% more of something, that might
> > be a totally reasonable tradeoff for some other feature.
>
>
>
> GS:  Added “non-negligible”:  “… it adds non-negligible extra costs … ”

I would say "should attempt to minimize".


> > S 2.2.
> >    To further minimize the bandwidth consumption it is required to
> >    support transporting certificates and raw public keys by reference
> >    rather than by value.  Considering the wide variety of deployments,
> >    the AKE must support different schemes for transporting and
> >    identifying credentials, including those identified in Section 2 of
> >    [I-D.ietf-cose-x509].
> >
> > Really? so we need to support both x509bag and x509chain? Why?
>
> GS: One point with using COSE is that it specifies schemes relevant
> for constrained IoT, like x5u, x5t and provides an extension point for
> new smart schemes in this setting. Do we need both x5bag and x5chain?
> We do want to support x5chain for simpler processing, but I’ve heard
> of people using either (but not both). We omitted x5bag pending input
> from the WG.

So I don't think the way to phrase this is by reference to COSE but
by reference to the requirements, which seem to be:

- Certs by URL
- Certs by hash
- Certs explicitly [Incidentally, TLS experience was we specified
  what's effectively x5chain but everyone wanted x5bag because
  of cross-signatures]


> >    Assuming that both signature public keys and static DH public keys
> >    are in use, then also the case of mixed credentials need to be
> >    supported with one endpoint using a static DH public key and the
> >    other using a signature public key.  The AKE shall support the
> >    initiator signaling which public key credential mix to be used in the
> >    protocol such that the responder knows and can verify that the
> >    intended variant was executed.
> >
> > I don't understand what this means. The initiator doesn't know what
> > the responder can use and so can offer but can't dictate it.
>
> GS: In constrained deployments the initiator could very well know
> e.g. because only one is supported. We rephrased this.
>
> ”The AKE shall support negotiation of public key credential mix and
> that both can verify the variant that was executed..”

Thanks.


> > S 2.3.
> >    The AKE must provide mutual authentication during the protocol run.
> >
> > So unilateral authentication is completely out of scope? Why?
>
> GS: See response to Richard’s mail.

I am surprised to hear that,but OK.



> >    authenticated the other's credential.  In particular, both endpoints
> >    must agree on a fresh session identifier, and the roles and
> >    credentials of both endpoints..
> >
> > What are the properties of this identifier? I don't see it described.
> > Is this a CK-style session identifier?
>
>
> GS: Yes, as far as I understand. Karthik provided this input for formal verification purposes.

OK, so I think this needs to be a lot clearer, given that you
also use "connection identifier".




> >     *  The AKE shall protect against identity misbinding attacks
> >       [Misbinding].  Note that the identity may be directly related to a
> >       public key such as for example the public key itself, a hash of
> >       the public key, or data unrelated to a key.
> >
> > I don't understand what this means, but it seems like having names
> > that are public keys is a potential cause of misbinding attacks.
>
> GS: This is a placeholder for the analysis needed to take into account
> different ways of identifying the subject.

Well, I don't really think that placeholders have a place in requirements
documents. In any case, it's very different to have the key pointed
at by reference and have the endpoint identified by the key, and they
have differentbinding properties.



> >    Moreover, it shall be possible for the receiving endpoint to detect a
> >    replayed AKE message.
> >
> > What does this mean? I don't know how to detect replay of the initial
> > message without maintaining infinite state or an extra round trip
> > (or catching it later in the protocol run) do you.
>
> GS: Rephrased based on proposal by Chris.

Will take a lool.


> >    Furthermore, the endpoints shall be able to verify that the identity
> >    of the other endpoint is an acceptable identity that it is intended
> >    to authenticate to.  (This requirement extends beyond the AKE in that
> >
> > What does this text mean?
>
> GS: This was requested by people working on formal verification. The
> requirement means that the AKE shall have a step verifying the
> endpoint being authenticated. In TLS web setting when connecting to
> example.com<http://example.com> it needs to verify that the certificate is issued for this
> domain. In 3GPP when connecting to a visited network it needs to
> verify that there is a roaming agreement. A more restricted setting
> could be a pre-provisioned public key of the manufacturer used to
> verify information about which network to join. Can we formulate this
> better?

Not sure. Can you give me an example of something that is an AKE that
doesn't otherwise have this property?



> > S 2.4.
> >    Perfect Forward Secrecy may alternatively be achieved with a nonce
> >    exchange followed by appropriately derived new session keys provided
> >    that state can be kept in the form of a session counter.  Note that
> >    OSCORE specifies a method for session key update involving a nonce
> >    exchange (see Appendix B in [RFC8613]).
> >
> > As noted in my comments on SAAG, the whole FS landscape is pretty
> > complicated, and this doesn't do that great a job of capturing it. For
> > instance, where do session tickets fit in?
>
> GS: I put in this text in as placeholder for Karthik’s mails about
> alternatives for forward secrecy, and added text about hash-based
> ratcheting after Chris’s recent comment. The draft does not pretend to
> give any deeper insights on this topic. The function of this paragraph
> is merely as placeholder for input provided to the requirements
> discussion, so those inputs do not get lost in mail archive, and so
> that we can return to that when we evaluate the solution against the
> requirements. We can add text about session tickets here, but may just
> as well wait with that to the solution discussion where probably this
> entire discussion better belong.

I believe that this document should be self-contained, so I'm not that
enthusiastic about placeholders.



> >    *  The AKE shall support negotiation of COSE algorithms
> >       [IANA-COSE-Algorithms] to be used in the AKE and in OSCORE.  A
> >       successful negotiation shall result in the most preferred
> >       algorithms of one of the parties which are supported by the other.
> >
> > This is overly specific, and I don't see why it's a requirement. The
> > way you want to phrase this is that it resists downgrade.
>
> GS: One reason why we may want to require more than “resisting
> downgrade” is that a protocol that always results in the least
> preferred common algorithm would comply with that requirement, and
> that obviously is not desirable.

I'd be interested in understanding how you propose to define
this property. For instance consider a protocol like TLS where
one end sends their list and the other end picks, that doesn't
guarantee highest preferred algorithm. It seems like the
definition people have come to is about integrity of negotiation
not about "best preferred" https://eprint.iacr.org/2016/072.pdf<https://protect2.fireeye.com/v1/url?k=55ffe4af-0975c660-55ffa434-0cc47ad93ea4-29c54eea46b01a68&q=1&e=bcff050e-f064-47b0-bef0-68edfc8b1ac2&u=https%3A%2F%2Feprint.iacr.org%2F2016%2F072.pdf>.



> >    The AKE negotiation must provide strong integrity guarantees against
> >    active attackers.  At the end of the AKE protocol, both endpoints
> >    must agree on both the crypto algorithms that were proposed and those
> >    that were chosen.  In particular, the protocol must protect against
> >    downgrade attacks.
> >
> > Would be good to quantify "strong". I suggest >= 128 bits.
>
> GS: This is another topic we discussed in connection with the BoF at
> IETF 105 and decided at the time not to do. Another reason for leaving
> this out is that it is not always clear what 128 bits mean. Curve25519
> may be characterized as < 128 bits. MACs shorter than 128 bits may be
> acceptable, this needs to be verified in the concrete protocol. The
> purpose of this work is to provide an AKE that works in very
> constrained settings. If too strong integrity requirement leads to a
> protocol that no one uses because of low performance then nothing is
> gained.

Hmm... I don't really remember that discussion, but I don't agree with
that outcome, and the purpose of a WGLC is to discuss this kind of
question. On the technical merits the 25519 thing is easy to handle by
either just saying 127 bits or just saying that we consider 25519 to
be about 128 bits. As for the MAC, the requirement I am talking about
is the strength of the protocol, not the size of the MAC, and I
think we should specify that.



> > S 2.6.
> >    In case of a PSK identifier, this may be protected against passive
> >    attackers, for example with a key derived from a Diffie-Hellman
> >    shared secret at the earliest in flight 3.  As a consequence, in
> >    order to authenticate the responder within the AKE, at least four
> >    protocol flights are needed in case of symmetric key authentication
> >    with identity protection.  Considering the need to keep the number of
> >    round-trips at a minimum (see Section 2.10.4), unless there are other
> >    good reasons for having more than 3 flights, it is not required to
> >    protect the PSK identifier, and it may thus be sent in the first
> >    flight.
> >
> > This kind of buries the lede. I would just say it's not a requirement.
>
> GS: This text came out of a mail discussion about what kind of
> identity protection is needed for PSK. If we remove the motivation
> the next reviewer will ask why. We kept one sentence as placeholder
> for that discussion.

OK.


> >    The AKE should avoid mechanisms where an initiator takes a guess at
> >    the policy, and when it receives a negative response, must guess,
> >    based upon what it has tried, what to do next.
> >
> > I don't agree with this at all, and I'm not sure why this is
> > here. There are good reasons to do this. In fact, it's the main way to
> > get a three message protocol with confidentiality for the server's
> > first flight.
>
>
> GS: This text was suggested by Michael. Just noting a potential
> difference in what you say: Michael’s text speaks about initiator
> guessing twice. In your example that is not the case, right?

Right.. Thanks for pointing that out.

-Ekr

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.