Re: [TLS] Passive TLS Clients - Reverse Connections

Mohamad Badra <mbadra@gmail.com> Sun, 15 December 2013 09:33 UTC

Return-Path: <mbadra@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A609B1AD8F1 for <tls@ietfa.amsl.com>; Sun, 15 Dec 2013 01:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 SdcEKfxef1li for <tls@ietfa.amsl.com>; Sun, 15 Dec 2013 01:33:44 -0800 (PST)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A91AD68D for <tls@ietf.org>; Sun, 15 Dec 2013 01:33:44 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id ld13so2394067vcb.20 for <tls@ietf.org>; Sun, 15 Dec 2013 01:33:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k6PqU4ZnzcNYX/CdXERhDpkPw9OyLHqjOWK38qbFs8k=; b=kW8f38sk96ooFXcnEgcbn9Z6BYmY7QMQdgtbTJjQIFEk2RSXLKxFvWxyEo8vtUtOM6 KPubPmuQInajizzV2eZkUm8pKLRcqfJ2l/AuGaUVxPsaj17yRPzuibzrC2UmtwZB9Irh JabZtN+yGjWOndUZxIGX3YE+vJ1Ebmi8RV68zdDvWxcTBZxsM5Ws03rjhX/69rQ5bUdl Tu7AsGp7tYE9RwbWp3haGB7eh3fBG+dG13dlKMj7kwaMrvuccp8nxPh0b4FoaoKLbOs9 2hzMrrLKNBxIZlLyNdBhsoH4y9UnlRKr5qbbJBGWFRJlgtDh4ONrMX7Je3zmyPcMP8kA RBLg==
MIME-Version: 1.0
X-Received: by 10.52.162.168 with SMTP id yb8mr4934384vdb.8.1387100017082; Sun, 15 Dec 2013 01:33:37 -0800 (PST)
Received: by 10.220.165.132 with HTTP; Sun, 15 Dec 2013 01:33:36 -0800 (PST)
In-Reply-To: <CACsn0ck4=cdAhVB_mKdWuOrULF1+sY-xptAsNWrLGayPCwC8Ew@mail.gmail.com>
References: <CAOhHAXwwrJJuVKou68yz8zJ1gHZk6xqjuKN40XzxTS0uYxQyUw@mail.gmail.com> <CACsn0ck4=cdAhVB_mKdWuOrULF1+sY-xptAsNWrLGayPCwC8Ew@mail.gmail.com>
Date: Sun, 15 Dec 2013 13:33:36 +0400
Message-ID: <CAOhHAXyes7DiAxqNs6Zpv7JYFg1FZage+ty2YV2pf84tzJyJyg@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=089e01634f1cc947a504ed8f63ad
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Passive TLS Clients - Reverse Connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Dec 2013 09:33:49 -0000

On Sun, Dec 15, 2013 at 4:47 AM, Watson Ladd <watsonbladd@gmail.com>; wrote:

> On Sat, Dec 14, 2013 at 4:41 PM, Mohamad Badra <mbadra@gmail.com>; wrote:
> > Dear All,
> >
> > I've submitted the following document to enable a TLS connection from a
> > server to a client after the initial handshake is complete.
> Do you have a use case for this? Because once the handshake finishes
> you have a perfectly good connection.
> If an application protocol requires this, it can do it at the application
> level.
> Sincerely,
> Watson Ladd
>

​​I don't have an exhaustive list of scenarios where this extension could
be useful:

​- Some of the applicative resources may be hosted behind a proxy or a
firewall that implements NAT for the internal network IP addresses. They
may be hosted on devices in stealth mode or with dynamic IP addresses so
mapping between the resources and IP is not efficient.

- It is suitable for network management protocols such as NETCONF(*). It
will be easier to extend TLS than revising every application to enable
reverse connection over TLS And assign a new port number.

- In the case of reverse connections, it would be more secure to
configure your server (it may be easier to secure one open port than to
having an open port on each server in the network).

(*) Other benefits related to device management may be found at
http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-02#section-3.

Best regards,
Badra