Re: [TLS] To API or not
Bill Frantz <frantz@pwpconsult.com> Tue, 10 November 2009 22:31 UTC
Return-Path: <frantz@pwpconsult.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 BB24A28C21A for <tls@core3.amsl.com>; Tue, 10 Nov 2009 14:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 XICBYtQJUEHz for <tls@core3.amsl.com>; Tue, 10 Nov 2009 14:31:50 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A686B28C1FF for <tls@ietf.org>; Tue, 10 Nov 2009 14:31:50 -0800 (PST)
Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1N7zG5-0006rv-Tj for tls@ietf.org; Tue, 10 Nov 2009 17:32:18 -0500
Date: Tue, 10 Nov 2009 14:32:15 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: "'tls@ietf.org'" <tls@ietf.org>
X-Priority: 3
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBF7E@il-ex01.ad.checkpoint.com>
Message-ID: <r02010500-1049-E639C801CE4811DEAFA00030658F0F64@[192.168.1.5]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.1.5 (Blindsider)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796ab95d1f84a3e0b1d8df097478696c9d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.34
Subject: Re: [TLS] To API or not
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: Tue, 10 Nov 2009 22:31:51 -0000
I would like to add a voice in favor of considering abstract APIs in TLS. I see abstract APIs as a series of statements like, "The API SHOULD provide a way for the application to validate and approve the public key of the other end." Background: For many years the E language project <http://www.erights.org>, has been considering moving from our home-brew protocol VatTP <http://www.erights.org/elib/distrib/vattp/index.html> to TLS. The last coherent thing I wrote discussing the issue was: I think the attributes we want to preserve from the existing VatTP are: Perfect forward security - Symmetric encryption and MAC keys exist only for the duration of the connection. They can not be recovered after the endpoints have removed them from memory. Distributed public key authentication - The sturdy-refs held by a vat contain enough information to authentic the public key sent by the remote vat, so additional mechanisms should be avoided. The system uses only known-secure algorithms, modes, and protocols. When I wrote <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html>, there was confusion in my mind between supporting SSL and using SSL. In our case, we want to use SSL/TLS, and do not need to worry about any of the many CipherSuites (for example TLS_NULL_WITH_NULL_NULL), which are not applicable to our use. The CipherSuites (from RFC 4346 and RFC 3268) which seem most applicable to VatTP are: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA - This CipherSuite uses the same algorithms as the current VatTP. All are somewhat dated. TLS_DH_DSS_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_CBC_SHA - These update 3DES to the spiffy new AES. When two vats connect, they exchange public keys. The vats check the public key they receive against the SHA1 hash in any sturdy refs to be used, providing assurance that the remote vat is indeed the correct vat. This procedure is quite different from the certificate authority procedure used by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have the user-exits to support this form of authentication. It may be necessary to adopt an new approach to provide distributed public key authentication. It would help this process if an RFC gave an idea of what interfaces one should expect from a library API. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.periwinkle.com | learned anything about security?" -- Bruce Schneier
- [TLS] draft-rescorla-tls-renegotiate and MITM res… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Dr Stephen Henson
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yair Elharrar
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Steve Dispensa
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… David-Sarah Hopwood
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Peter Saint-Andre
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Yoav Nir
- Re: [TLS] To API or not Bill Frantz
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate and MITM… Martin Rex
- [TLS] RC4+3DES rekeying - long-lived TLS connecti… Martin Rex
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… David-Sarah Hopwood
- Re: [TLS] RC4+3DES rekeying - long-lived TLS conn… Peter Saint-Andre