Re: [TLS] Summarizing identity change discussion so far

<Pasi.Eronen@nokia.com> Wed, 09 December 2009 13:40 UTC

Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF0F3A6895 for <tls@core3.amsl.com>; Wed, 9 Dec 2009 05:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.548
X-Spam-Level:
X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjSh04cflr5c for <tls@core3.amsl.com>; Wed, 9 Dec 2009 05:40:35 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A26373A67C2 for <tls@ietf.org>; Wed, 9 Dec 2009 05:40:34 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB9De38N013614; Wed, 9 Dec 2009 15:40:21 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:39:38 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:39:34 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 9 Dec 2009 14:39:33 +0100
From: Pasi.Eronen@nokia.com
To: mrex@sap.com
Date: Wed, 09 Dec 2009 14:39:32 +0100
Thread-Topic: [TLS] Summarizing identity change discussion so far
Thread-Index: Acp4R0mAs3G8WparTri1llpRksOp4AAjURlQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D24095@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 08:45:49 pm <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp>
In-Reply-To: <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Dec 2009 13:39:34.0337 (UTC) FILETIME=[0B1E1B10:01CA78D5]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Summarizing identity change discussion so far
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Wed, 09 Dec 2009 13:40:36 -0000

Martin Rex wrote:

> > Although using the callback-style APIs might be more common (and in
> > some sence nicer, since it allows you to abort the handshake
> > a bit earlier -- but an app developer might not care about this very
> > much), I think it would be a surprise to most app developers that
> > using the get-style APIs might not be secure.
> >
> > (And I wouldn't be surprised at all if real applications using
> > those get() style APIs are found...)
> 
> The get-style API is _the_only_ API that I provide to our applications.
> Besides, I'm coming from the GSS-API world, and there never was
> a callback API.
> 
> If you think that get-style API is dangerous, then you seem to be
> quite unaware about the risks involved with some of the callback APIs
> (besides being difficult to use in distributed architectures).

I did not intend to imply that callback-style APIs are somehow 
better; clearly both can have cases where what the app developer
expects the library to do could be quite different from what
TLS actually does...

Best regards,
Pasi
(not wearing any hats)