Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

Michael Gray <mickgray@au1.ibm.com> Tue, 06 October 2009 23:34 UTC

Return-Path: <mickgray@au1.ibm.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 E0DF73A683D for <tls@core3.amsl.com>; Tue, 6 Oct 2009 16:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 YPr-FkrNG-Tq for <tls@core3.amsl.com>; Tue, 6 Oct 2009 16:34:34 -0700 (PDT)
Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id DE2F23A6407 for <tls@ietf.org>; Tue, 6 Oct 2009 16:34:33 -0700 (PDT)
Received: from d23relay02.au.ibm.com (d23relay02.au.ibm.com [202.81.31.244]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id n96Na5IN032601 for <tls@ietf.org>; Wed, 7 Oct 2009 10:36:05 +1100
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay02.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n96Na97r467002 for <tls@ietf.org>; Wed, 7 Oct 2009 10:36:09 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n96Na8BE020899 for <tls@ietf.org>; Wed, 7 Oct 2009 10:36:09 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n96Na8oC020894; Wed, 7 Oct 2009 10:36:08 +1100
In-Reply-To: <p0624087dc6efe84bcc54@[10.20.30.163]>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OFD9D00D78.79487C37-ON4A257647.0076965D-4A257647.0081A07B@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Wed, 07 Oct 2009 09:35:52 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 07/10/2009 10:42:19
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Cc: tls@ietf.org
Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
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, 06 Oct 2009 23:34:36 -0000

Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> >   Title      : Additional PRF Inputs for TLS
> >
> >   Author(s)   : J. Solinas, P. Hoffman
> >   Filename   : draft-solinas-tls-additional-prf-input-00.txt
> >   Pages      : 6
> >   Date      : 2009-10-5
> >
> >This document describes a mechanism for using additional PRF inputs
> >   with Transport Layer Security (TLS) and Datagram TLS (DTLS).
> >
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-
> prf-input-00.txt
>
> Greetings again. We would like to hear input on this draft from the
> TLS community. The basic idea is an extension that would allow the
> two parties to give additional information that is directly mixed
> into the master secret through the PRF.
>
> --Paul Hoffman, Director
> --VPN Consortium

Comparing this with draft-rescorla-tls-extended-random-02.txt I see the
requirement for the size of Server response is missing and thus undefined.
>From 3.1 in the above we have:

   If the server wishes to use the extended randomness feature, it MUST
   send its own "extended_random" extension with an
   extended_random_value equal in length to the client's
   extended_random_value

Additionally, I think some limitation of the size/amount of data that can
be requested from a server is needed as large sizes could pose an attack on
a server by exhausting the entropy pool and/or causing server performance
degradation.  Our prototype implementation allows servers to ignore or
respond with error, depending on configuration, requests from clients that
are larger than 256 octets.

Mick Gray
IBM

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls