Subject: Re: [Dots] Using SNI

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jan 2018 08:48:23 +0000

Hi Jon,

Both signal and data channel drafts refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see the need to explicitly discuss SNI in these drafts.

Regards,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: [email-masked]
Subject: [Dots] Using SNI

Hi WG,

When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.).  Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work.  I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services.

As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option).

This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello.  Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate.

To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546".

In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port.

Thoughts / comments?

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 09:40:00 -0000

Hi Tiru,

I agree that (indirectly through RFC7525 reference) SNI is mandated to be
supported (but not necessarily has to be used).

However, to guarantee interoperability between different DOTS vendors, I am
saying that the use of SNI is a MUST - in particular for the data channel.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Using SNI

Hi Jon,

Both signal and data channel drafts refer to RFC7525 for secure use of
(D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see
the need to explicitly discuss SNI in these drafts.

Regards,

-Tiru

Hi WG,

When providing a DOTS server data channel service in my environment, this
shares the same ip / port which also provides other services (e.g. GUI /
REST server etc.).  Even if the Root Discovery points to another IP and or
port for the actual data channel activity, the TLS exchanges for the Root
Discovery have to correctly work.  I suspect that I am not the only DOTS
vendor who will have this type of requirement of a single IP providing
multiple TLS services.

As DOTS requires mutual authentication, this is a different security
requirement than required by the GUI environment (DOTS requires client cert
to be presented, GUI does not and providing certificates to every GUI client
is not a practical option).

This can be handled by using SNI by using 2 different FQDNs and requiring
the DOTS client to include the DOTS specific FQDN in the TLS Client Hello.
Whether the GUI client does or does not (likely does with modern browsers)
include a SNI FQDN when connecting to the non DOTS FQDN does not really
matter - for DOTS it is recognizing the DOTS specific FQDN and setting up
the TLS as appropriate.

To make sure interoperability between DOTS vendors, I would like to see
something like added to the data channel spec "DOTS clients MUST include the
DOTS server FQDN in the TLS Client Hello packet by using Server Name
Indication (SNI) RFC 3546".

In addition, I think that this would be a good idea as well for the signal
draft - thereby giving DOTS vendors the opportunity to host multiple DOTS
servers (likely to be different security requirements for their different
client) on a single IP / port.

Thoughts / comments?

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jan 2018 09:54:41 +0000

Hi Jon,

RESTCONF does not mandate client authentication based on TLS client certificate, we can say the following instead:

If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066).

Cheers,

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Using SNI

Hi Tiru,

I agree that (indirectly through RFC7525 reference) SNI is mandated to be supported (but not necessarily has to be used).

However, to guarantee interoperability between different DOTS vendors, I am saying that the use of SNI is a MUST - in particular for the data channel.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Using SNI

Hi Jon,

Regards,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Using SNI

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 10:00:03 -0000

Hi Tiru,

That certainly works for me - thanks

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 January 2018 09:55
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Using SNI

Hi Jon,
 
RESTCONF does not mandate client authentication based on TLS client
certificate, we can say the following instead:
If TLS client certificate is used to authenticate the DOTS client, the DOTS
client MUST include the DOTS server FQDN in server name indication extension
(Section 3 of RFC6066).
 
Cheers,
-Tiru

From: Jon Shallow [mailto:[email-masked]] 
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: RE: [Dots] Using SNI

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,

-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 2 Jan 2018 11:29:18 -0500

Hello,

You might want to discuss your use of SNI on the TLS mailing list
after reviewing this adopted draft:
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00

It'll just be an option in TLS 1.3, but will prevent your use of SNI
as a middlebox if/when implemented.

Best regards,
Kathleen

On Tue, Jan 2, 2018 at 5:00 AM, Jon Shallow <[email-masked]> wrote:
> Hi Tiru,
>
>
>
> That certainly works for me – thanks
>
>
>
> Regards
>
>
>
> Jon
>
>
>
> saying that the use of SNI is a MUST – in particular for the data channel.
>
>
>
> Regards
>
>
>
> Jon
>
>
>
> (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don’t see
> matter – for DOTS it is recognizing the DOTS specific FQDN and setting up
> the TLS as appropriate.
>
>
>
> something like added to the data channel spec “DOTS clients MUST include the
> Indication (SNI) RFC 3546”.
>
>
>
> draft – thereby giving DOTS vendors the opportunity to host multiple DOTS
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>

-- 

Best regards,
Kathleen

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 16:51:53 -0000

Hi Kathleen.

Thanks for keeping a watch out for things like this.

However, the use of SNI would be on a hop by hop basis - a DOTS client would be talking directly to the next hop DOTS server by resolving its FQDN  and using server_name extension in the client_hello - the connection terminating on the DOTS server.  If the DOTS server was a part of a DOTS gateway, then the new connection from the DOTS gateway to the next DOTS server would be using a different FQDN so I do not think we will have an issue here.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Kathleen Moriarty
Sent: 02 January 2018 16:29
To: Jon Shallow
Cc: Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] Using SNI

Hello,

You might want to discuss your use of SNI on the TLS mailing list after reviewing this adopted draft:
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00

It'll just be an option in TLS 1.3, but will prevent your use of SNI as a middlebox if/when implemented.

Best regards,
Kathleen

On Tue, Jan 2, 2018 at 5:00 AM, Jon Shallow <[email-masked]> wrote:
> From: Dots [mailto: [email-masked]] On Behalf Of Konda, 
> Tirumaleswar Reddy
> If TLS client certificate is used to authenticate the DOTS client, the 
> DOTS client MUST include the DOTS server FQDN in server name 
> indication extension (Section 3 of RFC6066).
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> I agree that (indirectly through RFC7525 reference) SNI is mandated to 
> be supported (but not necessarily has to be used).
>
>
>
> However, to guarantee interoperability between different DOTS vendors, 
> I am saying that the use of SNI is a MUST – in particular for the data channel.
>
>
>
> Regards
>
>
>
> Jon
>
>
>
> From: Dots [mailto: [email-masked]] On Behalf Of Konda, 
> Tirumaleswar Reddy
> (D)TLS and RFC7525 mandates TLS implementations to support SNI. I 
> don’t see the need to explicitly discuss SNI in these drafts.
>
>
> Regards,
>
> -Tiru
>
>
>
> When providing a DOTS server data channel service in my environment, 
> this shares the same ip / port which also provides other services 
> (e.g. GUI / REST server etc.).  Even if the Root Discovery points to 
> another IP and or port for the actual data channel activity, the TLS 
> exchanges for the Root Discovery have to correctly work.  I suspect 
> that I am not the only DOTS vendor who will have this type of 
> requirement of a single IP providing multiple TLS services.
>
>
>
> requirement than required by the GUI environment (DOTS requires client 
> cert to be presented, GUI does not and providing certificates to every 
> GUI client is not a practical option).
>
>
>
> This can be handled by using SNI by using 2 different FQDNs and 
> requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello.
> Whether the GUI client does or does not (likely does with modern 
> browsers) include a SNI FQDN when connecting to the non DOTS FQDN does 
> not really matter – for DOTS it is recognizing the DOTS specific FQDN 
> and setting up the TLS as appropriate.
>
>
>
> To make sure interoperability between DOTS vendors, I would like to 
> see something like added to the data channel spec “DOTS clients MUST 
> include the DOTS server FQDN in the TLS Client Hello packet by using 
> Server Name Indication (SNI) RFC 3546”.
>
>
>
> In addition, I think that this would be a good idea as well for the 
> signal draft – thereby giving DOTS vendors the opportunity to host 
> multiple DOTS servers (likely to be different security requirements 
> for their different

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 2 Jan 2018 11:55:59 -0500

Hi Jon,

Thanks for the detailed explanation of your usage.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 3 Jan 2018 07:20:30 +0000

Hi Jon,

We may want to use "SHOULD" instead of "MUST" in the below line (for example, SNI is not required if the DOTS client and server are in the same enterprise network).

-TIru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, January 2, 2018 3:30 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Using SNI

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Using SNI

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,
-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 3 Jan 2018 10:47:19 -0000

Hi Tiru,

My main goal here is to make sure that we can have DOTS vendor
interoperability.  As found during my implementation, having certain things
in place helps considerably - providing strong hints to the implementer as
to what should be available for interoperability helps.

Instead of 
 
"If TLS client certificate is used to authenticate the DOTS client, the DOTS
client MUST include the DOTS server FQDN in server name indication extension
(Section 3 of RFC6066)."
 
We could perhaps have
 
"The DOTS client MUST support enabling the use of SNI (Section 3 of
RFC6066).  When enabled, this SHOULD include the DOTS server FQDN in the
server name indication extension."
 
As an aside, I have been able to get my DOTS server to support both PKI and
PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the
same time (I agree this is not a generally recommended case).  This was not
done using SNI, but would have been considerably easier to implement if
using SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI
clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the
same IP.
 
So being able to use SNI in both the signal and data channels makes sense to
me.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 January 2018 07:21
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Using SNI

Hi Jon,

We may want to use "SHOULD" instead of "MUST" in the below line (for
example, SNI is not required if the DOTS client and server are in the same
enterprise network).

-TIru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,

-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 4 Jan 2018 07:18:39 +0000

Hi Jon,

How about the following line instead ?
"If PKI-based authentication is used by the DOTS client to validate the DOTS server identity, the DOTS client SHOULD include DOTS server FQDN in the server name indication extension (Section 3 of RFC6066)."

Cheers,
-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Wednesday, January 3, 2018 4:17 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Using SNI

Hi Tiru,

My main goal here is to make sure that we can have DOTS vendor interoperability.  As found during my implementation, having certain things in place helps considerably - providing strong hints to the implementer as to what should be available for interoperability helps.

Instead of

"If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066)."

We could perhaps have

"The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066).  When enabled, this SHOULD include the DOTS server FQDN in the server name indication extension."

As an aside, I have been able to get my DOTS server to support both PKI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the same time (I agree this is not a generally recommended case).  This was not done using SNI, but would have been considerably easier to implement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the same IP.

So being able to use SNI in both the signal and data channels makes sense to me.

Regards

Jon

Hi Jon,

-TIru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,
-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 4 Jan 2018 08:15:10 -0000

Hi Tiru,

I do not think that this is about validation, and unlikely to be used by the
DOTS client to validate the DOTS server identity (yes, the DOTS server could
present different certificates based on the SNI, but not sure how that helps
the DOS client to validate).

To me, it is all about the ability of the DOTS server to be able to decide
which security policy to install for the incoming connection - is this a
DOTS connection or is this a request to access a GUI or is this for a
RESTful interface etc. etc. ? - all on the same IP and port - the decision
is keyed off the SNI information.

Part of the challenge I have here is that the data channel root discovery
against port 443 ideally has to have the same security requirements as when
the data channel is used for aliases and filter updating.  So even if root
discovery redirects the DOTS connection to a different port, the correct
security policy still needs to applied to DOTS client root discovery and a
different policy applied for the GUI connection.  If a peer certificate is
to be requested for mutual authentication checks in a DOTS connection,
requesting a peer certificate from a browser fails (unless a specific peer
cert is installed in the browser - impractical scaling request) and so GUI
access will fail.  One policy (DOTS) needs to request the peer cert, the
other (GUI) must not request a peer cert.  SNI is the only way I have found
to handle this.

I also do not think it is limited to PKI for DOTS - as mentioned below,
accessing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along
with the appropriate SNI information, the DOTS server can easily decide to
install a PSK or PKI security policy.

The DOTS client needs to be able to provide the SNI information - it is up
to the DOTS server as to how it is used (which could be to ignore it) - to
provide DOTS vender interoperability.

So, no, I am not comfortable with your suggestion.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 04 January 2018 07:19
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Using SNI

Hi Jon,

"If PKI-based authentication is used by the DOTS client to validate the DOTS
server identity, the DOTS client SHOULD include DOTS server FQDN in the
server name indication extension (Section 3 of RFC6066)."

Cheers,

-Tiru

Hi Tiru,

Instead of 

We could perhaps have

 

Regards

Jon

Hi Jon,

-TIru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,

-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 4 Jan 2018 10:47:33 +0000

Hi Jon,

Thanks, I now understand your concerns :)

Proposed text:
The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)TLS server the name of the server it wants to contact.  This is a useful extension for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may not know if it is interacting with a DOTS server in the hosting environment, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extension.

Cheers,
-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Thursday, January 4, 2018 1:45 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Using SNI

Hi Tiru,

I do not think that this is about validation, and unlikely to be used by the DOTS client to validate the DOTS server identity (yes, the DOTS server could present different certificates based on the SNI, but not sure how that helps the DOS client to validate).

To me, it is all about the ability of the DOTS server to be able to decide which security policy to install for the incoming connection - is this a DOTS connection or is this a request to access a GUI or is this for a RESTful interface etc. etc. ? - all on the same IP and port - the decision is keyed off the SNI information.

Part of the challenge I have here is that the data channel root discovery against port 443 ideally has to have the same security requirements as when the data channel is used for aliases and filter updating.  So even if root discovery redirects the DOTS connection to a different port, the correct security policy still needs to applied to DOTS client root discovery and a different policy applied for the GUI connection.  If a peer certificate is to be requested for mutual authentication checks in a DOTS connection, requesting a peer certificate from a browser fails (unless a specific peer cert is installed in the browser - impractical scaling request) and so GUI access will fail.  One policy (DOTS) needs to request the peer cert, the other (GUI) must not request a peer cert.  SNI is the only way I have found to handle this.

I also do not think it is limited to PKI for DOTS - as mentioned below, accessing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along with the appropriate SNI information, the DOTS server can easily decide to install a PSK or PKI security policy.

The DOTS client needs to be able to provide the SNI information - it is up to the DOTS server as to how it is used (which could be to ignore it) - to provide DOTS vender interoperability.

Regards

Jon

Hi Jon,

Hi Tiru,

Instead of

We could perhaps have

Regards

Jon

Hi Jon,

-TIru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,
-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 4 Jan 2018 10:55:12 -0000

Hi Tiru,

That is much better.  However for additional clarity, it may be better to
say

The SNI extension [RFC6066] defines a mechanism for a client to tell a
(D)TLS server the name of the server it wants to contact.  This is a useful
extension for hosting environments where multiple virtual servers are run on
a single IP address. The DOTS client may or may not know if it is
interacting with a DOTS server in a virtual server hosting environment, so
the DOTS client SHOULD include the DOTS server FQDN in the SNI extension.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 04 January 2018 10:48
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Using SNI

Hi Jon,

Thanks, I now understand your concerns J  

Proposed text:

The SNI extension [RFC6066] defines a mechanism for a client to tell a
(D)TLS server the name of the server it wants to contact.  This is a useful
extension for hosting environments where multiple virtual servers are run on
a single IP address. The DOTS client may or may not know if it is
interacting with a DOTS server in the hosting environment, so the DOTS
client SHOULD include the DOTS server FQDN in the SNI extension.

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Instead of 

We could perhaps have

 

Regards

Jon

Hi Jon,

-TIru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,

-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 4 Jan 2018 10:57:41 +0000

Thanks, works for me.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Thursday, January 4, 2018 4:25 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Using SNI

Hi Tiru,

That is much better.  However for additional clarity, it may be better to say

The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)TLS server the name of the server it wants to contact.  This is a useful extension for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may not know if it is interacting with a DOTS server in a virtual server hosting environment, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extension.

Regards

Jon

Hi Jon,

Proposed text:

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Hi Tiru,

Instead of

We could perhaps have

Regards

Jon

Hi Jon,

-TIru

Hi Tiru,

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

Regards,
-Tiru

Hi WG,

Thoughts / comments?

Regards

Jon