IETF Logo Mail Archive

Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Jari Arkko <jari.arkko@piuha.net> Thu, 25 August 2005 13:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAl-00086G-2U; Thu, 25 Aug 2005 09:53:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAh-00086B-Py for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18348 for <secmech@ietf.org>; Thu, 25 Aug 2005 09:53:34 -0400 (EDT)
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IBF-0003vK-19 for secmech@ietf.org; Thu, 25 Aug 2005 09:54:09 -0400
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9BA9A89852; Thu, 25 Aug 2005 16:53:26 +0300 (EEST)
Message-ID: <430DCD61.1090109@piuha.net>
Date: Thu, 25 Aug 2005 16:53:37 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Shumon Huque <shuque@isc.upenn.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <Pine.GSO.4.60.0508191330380.16954@ismene> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu>
In-Reply-To: <20050822044255.GC27685@isc.upenn.edu>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: secmech@ietf.org, Nicolas Williams <Nicolas.Williams@sun.com>
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

Shumon Huque wrote:

>I'm also not a fan of automatically assuming that a tunnel is the 
>right solution for many problems. If we are tunnelling in TLS for 
>example, I now have additional issues to deal with. Such as how to 
>query up-to-date certificate revocation status, and whether my 
>users are properly validating the certificates etc.
>  
>
Given choice, I'd rather have a well-design fully
capable mechanisms than a tunnel + a mechanism
that needs to run inside the tunnel.

--Jari



_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech

v2.23.0 | Report a Bug | By Email