IETF Logo Mail Archive

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

Michael StJohns <msj@nthpermutation.com> Sat, 19 April 2014 21:39 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 C80671A0033 for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 14:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ZLg3XOizxdqH for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 14:39:25 -0700 (PDT)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id AD2811A00A5 for <tls@ietf.org>; Sat, 19 Apr 2014 14:39:25 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id x3so2790236qcv.40 for <tls@ietf.org>; Sat, 19 Apr 2014 14:39:21 -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=HQMq3ptDmAAjFVDpePxpzpg2ObAgrvEBVSg8g9TJDCk=; b=LoDnW/S/ZTdm0oh8xFVN5m4i25ybaofIHc+dup/zY5RkVGeYWkhM8tK7nUHtR8D3LH jzAZ/emHzvMiph8Vpk+y212usb00xadVtNfcFuReZFmKO6ZFy7J52tpMVIzpYp848nMh KoEClGxjtJc4kdEbUgzHQLyC1W/zWRIThGbNPO+iG5/dLiIrg3YLewfxfE3C4oCWjkZk sMeSSimmY4HsTdZzbFi+j6oN3CruvtAtdj3wUHZY5FRQaznzF5Pu9sxRMR1XehTgQSFQ wr5rpmgDNvlwXDgT7bIOr7bxWOmAJjxnO+wkawtUOUfpnJBp4RtTGv3ZLnJoWQ7fiA67 +yUA==
X-Gm-Message-State: ALoCoQlkwXGUjUgM0XT4k88sHYMD1KTGXFe5LDV/8qLpg5LSl4x0qU0ZNZjTOYVv59ZOBu46X7Gl
X-Received: by 10.224.2.131 with SMTP id 3mr28325034qaj.71.1397943561143; Sat, 19 Apr 2014 14:39:21 -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 r4sm63721750qat.16.2014.04.19.14.39.20 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 14:39:20 -0700 (PDT)
Message-ID: <5352ED0E.4090203@nthpermutation.com>
Date: Sat, 19 Apr 2014 17:39:26 -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>, Paul Lambert <paul@marvell.com>
References: <53513F36.7050106@nthpermutation.com> <CABkgnnXugZw2U3Zv8H2H1J8we_N2b-p=qCdwsZyBDNqDZVYE2w@mail.gmail.com> <53515BDF.7010909@nthpermutation.com> <7BAC95F5A7E67643AAFB2C31BEE662D0197DEF8FAC@SC-VEXCH2.marvell.com> <CABkgnnUqdc3yhycAP2ufXvG2e4jBZoE7LBOmWNkHvAGD53EO+w@mail.gmail.com>
In-Reply-To: <CABkgnnUqdc3yhycAP2ufXvG2e4jBZoE7LBOmWNkHvAGD53EO+w@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/Vjln43c54H6fJoDZk6xwSFv7pbk
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: Sat, 19 Apr 2014 21:39:29 -0000

On 4/18/2014 4:28 PM, Martin Thomson wrote:
> On 18 April 2014 13:26, Paul Lambert <paul@marvell.com> wrote:
>> Specifically for the data path. SHA-256 is appropriate key management, generation etc.
> The PRF is only needed for key management, generation, extractors,
> etc...  I think that (perhaps) Mike wants to go one further and be
> able to ship a stack that doesn't even HAVE SHA-256.
>
>

Exactly.  There are a pile of cheap chips out there that implement AES 
but don't implement a hashing algorithm (and strangely vice versa).  On 
the software side, the tradeoffs between performance and space for the 
SHA functions are interesting choices.

On the other hand, I can't find any "standard" block cipher based 
hashing functions.  There are a number of proprietary and a number of 
"standards proposals" (e.g. to the SHA3 competition), but none that's 
showing up as a NIST/ISO/IEEE/IETF approved hashing function.

And please ignore my CMAC('0', data) suggestion.  It was pointed out to 
me (something that I used to know) that CMAC with a known key lacks 
collision resistance.

Mike

v2.23.0 | Report a Bug | By Email