IETF Logo Mail Archive

Re: [TLS] PRF Negotiation - Finished "gotcha"

Michael StJohns <msj@nthpermutation.com> Fri, 18 April 2014 17:07 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5E11A044A for <tls@ietfa.amsl.com>; Fri, 18 Apr 2014 10:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 GYXGsNx-BmQy for <tls@ietfa.amsl.com>; Fri, 18 Apr 2014 10:07:44 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id 98F161A01DE for <tls@ietf.org>; Fri, 18 Apr 2014 10:07:44 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so1851773qgf.7 for <tls@ietf.org>; Fri, 18 Apr 2014 10:07:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1TA0WDVsdwqi2+Olb7H2lr0RkmJlRTFE0ZIZnM0PShs=; b=BSosaYIxso55ZKH8eRMcZQ2rumdDLTbbSYTWSYbzNAgm+oz34YhUzWoeMsd+gCCvap vcL8C/aOimwy+sscmKZ2t/QevIZZQBBISSGUqKEUEBRlBkzbzFFTiBElBginw8joJPh1 IRAWAlkdM48JunnD1f6mzBxsQtk1MwSTu+jhP8exJC4iSa93GpBcfbFfqHsCyodL5x2j KQxM8UHznh9Q6wW61VYH+wFJjCiWQN5pTR1sVQkiw8T/Jgd6EOkq4sH98BRWkF014LMl YWB23RQdWDfLIR4NZZYDOrBwwT12DdolELc2j6gRgB7PUCMjisrk+Y4sWtmwXbx2p/A8 WlwQ==
X-Gm-Message-State: ALoCoQnVtPjzvvnz4YqQRMjZuQgTWrI78SCiLEMgpRsqPZ7SjB3nmGH9mzKz4Fh5MUggrOo+1viV
X-Received: by 10.140.102.166 with SMTP id w35mr9876126qge.97.1397840860342; Fri, 18 Apr 2014 10:07:40 -0700 (PDT)
Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id q62sm10341852qgd.0.2014.04.18.10.07.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 10:07:39 -0700 (PDT)
Message-ID: <53515BDF.7010909@nthpermutation.com>
Date: Fri, 18 Apr 2014 13:07:43 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <53513F36.7050106@nthpermutation.com> <CABkgnnXugZw2U3Zv8H2H1J8we_N2b-p=qCdwsZyBDNqDZVYE2w@mail.gmail.com>
In-Reply-To: <CABkgnnXugZw2U3Zv8H2H1J8we_N2b-p=qCdwsZyBDNqDZVYE2w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6ollmSLneEv4W4uNRu7zp7t4UEs
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PRF Negotiation - Finished "gotcha"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Fri, 18 Apr 2014 17:07:50 -0000

On 4/18/2014 12:46 PM, Martin Thomson wrote:
> On 18 April 2014 08:05, Michael StJohns <msj@nthpermutation.com> wrote:
>> As I was working through the "finished" message email I just sent, I
>> realized something about PRF negotiation.   The client, when it sends a
>> ClientHello, doesn't necessarily know which PRF it will be using (assuming
>> there are multiple PRFs defined in the offered cipher suites) until it gets
>> the ServerHello back.  I think that means that the client either needs to
>> keep a copy of the ClientHello around (or the data to rebuild it), or needs
>> to keep multiple HASH states - one for each PRF algorithm.
>>
>> It may be useful to add a paragraph on PRF negotiation implications that
>> provides this guidance.
> Indeed.
>
> There is another way to avoid this problem: don't negotiate the hash
> function used for the PRF.  SHA-256 might be good enough until we next
> revise the protocol.
>
> https://github.com/tlswg/tls13-spec/issues/26
>
>

But I *really* want to be able to build a cipher suite that only needs 
AES encrypt....

v2.23.0 | Report a Bug | By Email