Re: [TLS] Require deterministic ECDSA

Bill Cox <waywardgeek@google.com> Tue, 26 January 2016 00:41 UTC

Return-Path: <waywardgeek@google.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 A69C11AC3E9 for <tls@ietfa.amsl.com>; Mon, 25 Jan 2016 16:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 PR8KrNPDBAwb for <tls@ietfa.amsl.com>; Mon, 25 Jan 2016 16:41:49 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7017A1AC3E6 for <tls@ietf.org>; Mon, 25 Jan 2016 16:41:49 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id 77so169957509ioc.2 for <tls@ietf.org>; Mon, 25 Jan 2016 16:41:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ej9ko5wvlpJwrjjQnO52g2Gk8zIeQQMvChIp7TWUb+A=; b=HJn86j23e2yVZdn+6/QPInoy5xA25DzC09UVoLoLgHp0HbYr659OFyynM1G0XyejyJ /d/a/VLoqOXxfQ7U3nzo97iBFawSDm0R1DXm1fUPGpBdBtZqzgtsB3lanrgsluqOKAZ1 pJGb5ZfI0ephFeeuUXEcgMAS0NpScWQ8GSztqB/MTvW3FD+9zyOkZDcpNk7zPBuhbAH2 IKqQLociYPOJOgsLQX7oydZEMiU5ak7776RFf6F+25JDRiPelOUXmIY/PiqAnjXm4u02 vP17arjnKS2Bmh5BPk2WlJFpO+K3zDYBc6IJYuxfjMg4wEqjKpo9NGmOmYqXPZATskI6 d89A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ej9ko5wvlpJwrjjQnO52g2Gk8zIeQQMvChIp7TWUb+A=; b=WkuN0GiHO+X23nC6ltzlQIGKDu2YGFrYQlJrz65fq2sdJKGfgmq3WMG+znCDuKv6Aq qcS+A8gQ3NCMV7SXc23Z4l31rN5yHFYADR/ZVVxq8fb8r3pKM0AjuDj6dy1F7hQHMeKX VmbK1wm10OSQIDh+Ubpyx5J+zR6osh++cN1YfLf1fKNDZSVCC96dzqbtdvupBGkwx61m KL4kVguYCt7Lvk8yOy4F68A7X8UH11jfY4QCzupIDW3a4YIQ36ApkxFaylN2EahtqcSi epKta3LRl/ygfZqgRupw29IL3Dm4Lvwu8NNu41hRoRbKbzBCX1fhagmYyFYM6mI0TQEV C8sw==
X-Gm-Message-State: AG10YOQ6EFMDpCNbxVDwGO1rhb0QdQc+T6TCNGet6WyDzAHE9Ad44m3mxOuJYnSGWTkW+rxvyAkVrmIDXq1HDl/y
MIME-Version: 1.0
X-Received: by 10.107.132.231 with SMTP id o100mr20508409ioi.60.1453768908670; Mon, 25 Jan 2016 16:41:48 -0800 (PST)
Received: by 10.107.141.12 with HTTP; Mon, 25 Jan 2016 16:41:48 -0800 (PST)
In-Reply-To: <658f368606174b10af76d8c38cbe16b6@ustx2ex-dag1mb1.msg.corp.akamai.com>
References: <CACaGAp=-xJZN=L3av+DX_WQcki_k=L-_tc5dZnJNtM=M0W8MnQ@mail.gmail.com> <CAGwT64i5v+0xXLzQYFO5JVKs302x6BgZYN+ffYzMVesgbB9biA@mail.gmail.com> <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> <CAGwT64ge2RTw2hxzvQTUzYXStSNnb+uS9GcHU0t38VF9Kv+zkQ@mail.gmail.com> <b075e5774d104662b4b39c0bca9d9d94@ustx2ex-dag1mb1.msg.corp.akamai.com> <CACsn0c=atv-YvrD512MReWudZ-z5z5Pe-9gE3cUQU91jxOp4eA@mail.gmail.com> <658f368606174b10af76d8c38cbe16b6@ustx2ex-dag1mb1.msg.corp.akamai.com>
Date: Mon, 25 Jan 2016 16:41:48 -0800
Message-ID: <CAH9QtQGfpH_rr-Y17MrUthn26sZyKCa=JBnt=p=-SLF_q8ByMQ@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary="001a113ebf5463611e052a31f3c8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/eixjOBFD5_XC8tPVZMngg8G8FAk>
Cc: Jacob Maskiewicz <jmaskiew@eng.ucsd.edu>, Joseph Birr-Pixton <jpixton@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Require deterministic ECDSA
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Jan 2016 00:41:50 -0000

Just an off-topic point about the missile example... Thankfully, the Air
Force seems to have the sense to follow the KISS rule now and then.  I
would be shocked to see TLS in the launch flow :)  Can you imagine the
handshake?  Hopefully this humorous rather than poor taste:

Command: Here's everything you need in one flight of packets to launch.
Missile: Please send a CertificateVerify, and let's do a 1-RTT.  I'll just
ignore that launch command.  Here's my new server-config so you can learn
to speak to me properly.  I rotate it ever 7 years to provide
forward-secrecy.
Command: Here's my cert, and another launch command.  I was supposed to
resend it, right?  Let's not tell the application layer that I sent the
launch command twice, or that my first flight is replayable.
Missile: Symantec, really?  What about certificate transparency?  Was I
supposed to include that first launch command in the handshake hash?  :-p

I have low expectations for IoT vendors' TRNGs.  When deadlines get tight,
good engineering on the TRNG is easy to drop.  As long as they whiten the
output, it is very difficult to detect TRNG flaws, so there is little
incentive to put in much engineering.  IIRC, the FIPS standard requires
vendors to be secretive about their TRNGs.  They are not allowed to give us
access to the raw data from the entropy source, and cannot show us
schematics for their design, making it nearly impossible to differentiate a
well designed TRNG from an insecure one.

Basically, it is a poor assumption that the TRNG is any good.  Sure, it's
required for secure crypto, but whatever...

Bill