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
- [TLS] Require deterministic ECDSA Joseph Birr-Pixton
- Re: [TLS] Require deterministic ECDSA Joseph Birr-Pixton
- Re: [TLS] Require deterministic ECDSA Geoffrey Keating
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Brian Smith
- Re: [TLS] Require deterministic ECDSA Dave Garrett
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Watson Ladd
- Re: [TLS] Require deterministic ECDSA Filippo Valsorda
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Michael StJohns
- [TLS] Fwd: Re: Require deterministic ECDSA Michael StJohns
- Re: [TLS] Require deterministic ECDSA Hubert Kario
- Re: [TLS] Require deterministic ECDSA Jacob Maskiewicz
- Re: [TLS] Require deterministic ECDSA Salz, Rich
- Re: [TLS] Require deterministic ECDSA Adam Langley
- Re: [TLS] Require deterministic ECDSA Yoav Nir
- Re: [TLS] Require deterministic ECDSA Salz, Rich
- Re: [TLS] Require deterministic ECDSA Daniel Kahn Gillmor
- Re: [TLS] Require deterministic ECDSA Joseph Birr-Pixton
- Re: [TLS] Require deterministic ECDSA Watson Ladd
- Re: [TLS] Require deterministic ECDSA Salz, Rich
- Re: [TLS] Require deterministic ECDSA Jacob Maskiewicz
- Re: [TLS] Require deterministic ECDSA Bill Cox
- Re: [TLS] Require deterministic ECDSA Michael StJohns