Re: [Pce] Use of TCP AO and TLS in PCEP

"Diego R. Lopez" <diego@tid.es> Tue, 11 February 2014 14:26 UTC

Return-Path: <diego@tid.es>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2831A03E6 for <pce@ietfa.amsl.com>; Tue, 11 Feb 2014 06:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.85
X-Spam-Level:
X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 83BxBNZOH8Ks for <pce@ietfa.amsl.com>; Tue, 11 Feb 2014 06:26:13 -0800 (PST)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 238691A03CC for <pce@ietf.org>; Tue, 11 Feb 2014 06:26:13 -0800 (PST)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0U003JM5FITU@tid.hi.inet> for pce@ietf.org; Tue, 11 Feb 2014 15:26:09 +0100 (MET)
Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 9F.28.03314.1033AF25; Tue, 11 Feb 2014 15:26:09 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0U003JQ5FKTU@tid.hi.inet> for pce@ietf.org; Tue, 11 Feb 2014 15:26:08 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.159]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 15:26:08 +0100
Date: Tue, 11 Feb 2014 14:26:08 +0000
From: "Diego R. Lopez" <diego@tid.es>
In-reply-to: <52F401A1.7040209@isi.edu>
X-Originating-IP: [10.95.64.115]
To: Joe Touch <touch@isi.edu>
Message-id: <AC3F0A3D-76E2-4E75-8C80-47BC36129636@tid.es>
Content-id: <29C2FA48B1A2C84C8719E123DF55BF41@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US, es-ES
Thread-topic: [Pce] Use of TCP AO and TLS in PCEP
Thread-index: Ac8VNFeRvCG6i4qyTfiGqoE+7Nwh2wN2xWYAABscN4AA7CRfAA==
X-AuditID: 0a5f4068-b7fe58e000000cf2-82-52fa330148d5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhinfg0mU0/hVk8PQ/q0XT/RvsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2HlBuGCaasXGFR2MDYxzVLoYOTkkBEwkXl47wQphi0lcuLee rYuRi0NI4ACjxPzF3UwQzldGiZkHjjBDODMZJSb0bWYGaWERUJV4u+YpC4jNBmQ/av7NDmIL CxhIzFj/jA3E5hRQl5hzcBo7xAoFiT/nHoPViwjISjz48wYszizgJvF37l+wel4BS4knC3cw QcTNJObe38kEEReU+DH5HlAvB1BcXWLKlFyIEnGJ5tabLBC2osS0RQ2MIDYj0Ph38+ezQqwy lDjedglqrZPEo8kfGCHOEZBYsuc8M4QtKvHy8T9WiB9bGSUuXDjHPoFRYhaSM2YhOWMWwhmz kJwxC8kZCxhZVzGKFScVZaZnlOQmZuakGxjqZWTqZeallmxihERdxg7G5TtVDjEKcDAq8fBq fP0RJMSaWFZcmXuIUYKDWUmEV03tV5AQb0piZVVqUX58UWlOavEhRiYOTqkGxh12xfOem3/a zOVSqXXIZP5uhUDx2HN5mrEsrpwtOyJN5aTvCk7OLuM4yJ34mUPiJBeDyOtW1iv9p17VzP9s Gfd2WwjPxy3dmrsiSh7JBsbXX5QNqfx574LPE0enWY/PPmBvqZeRztHL6j/qtf3sIR2LnD3N fkc8psuLuxsWsEu47rM1fflfiaU4I9FQi7moOBEApA8wX5gCAAA=
References: <07b801cf1534$bec46b60$3c4d4220$@olddog.co.uk> <4698EB6C-9BEC-4E76-8291-FBCA51753950@tid.es> <52F401A1.7040209@isi.edu>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] Use of TCP AO and TLS in PCEP
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2014 14:26:17 -0000

Hi Joe,

Too much travel making my email backlog grow, I'm afraid...

On 6 Feb 2014, at 22:41 , Joe Touch <touch@isi.edu> wrote:
>> The rationale is the common practice derived from the TLS layered
>> approach, so a client knows how and when require the server to start a
>> TLS connection, and the server knows in advance what the client is
>> requiring and match it against its policy.
>
> That is common when there is no other way to determine whether a connection uses TLS or not (and even then is at best a performance optimization).

I'd say is not only performance, but a security optimization. Unless the server is sure that starting a TLS session is explicitly required by the client, how can a server know whether there has been an intentional downgrade by a man-in-the-middle? Furthermore, the client and server codes become completely independent of what happens at the TCP layer, and I think this is in general a good design practice.

And even if you find counterarguments to the two reasons above, the common practice is the use of either a dedicated port or a dedicated command. And that implies that developers will find plenty of choices to implement this, widely validated and understood by the community. And when it comes to security, this is of great value, mostly when PCEP peer developers will not usually be security experts.

> The use of TCP protection must be orthogonal to the use of TLS, so it
>> can not be used for the server making a guess of the protocol
>> security encapsulation.
>
> TCP protection isn't orthogonal to TLS for pcep as currently specified; see the table above. The only connections that can use TLS would be those that do not use TCP MD5 (see the list of cases above).
>
>> Either we have a protocol-specific mechanism (a-la-STARTTLS) or we
>> usea specific port.
> ...
>
> For every connection, you already know the mode before the connection starts. If the connection is configured to require TCP MD5, then there is no TLS. If not, then there must be TLS.

What I cannot see is why the combination of TCP MD5 with TLS could not happen, or the combination of TCP AO without TLS. We are talking about independent layers, or am I missing something? FWIW, you could use any of them on an IPsec connection as well...

> There are no protocol changes required to make this happen; you just need to use the information you already have.

By not having TCP protection and TLS orthogonal we are mixing security mechanisms at two different layers, and assuming there is some kind of cross-layer exchange that may not necessarily happen because is out of the common practice, and that is a recipe for security holes.

Maybe that the current writing of the PCEPS draft is not clear enough in that respect. We would really appreciate any suggestion in improving it.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx