Re: [TLS] Deprecating more (DSA?)
Watson Ladd <watsonbladd@gmail.com> Sat, 19 April 2014 17:44 UTC
Return-Path: <watsonbladd@gmail.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 839EE1A0064 for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 10:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 DfOOFVYLEqhW for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 10:44:33 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) by ietfa.amsl.com (Postfix) with ESMTP id EE36A1A0061 for <tls@ietf.org>; Sat, 19 Apr 2014 10:44:32 -0700 (PDT)
Received: by mail-yk0-f180.google.com with SMTP id 19so2279468ykq.11 for <tls@ietf.org>; Sat, 19 Apr 2014 10:44:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lP+CneJajfhTjuL3PnYwFhh/TKujz51Qw6kO/UXwvqo=; b=Ky8oq1LBQU3XnA10+SE+wrr0FMdpQgKee3T4xCOiYyJEbCGPuLeo0BnUT3tUJ3IBAx ENWyLva5cf10sgCyF/mLy1gDrgB4IATJM5Sua7iBTUnR+Vx5gzM5P0M00n5REY0odTlE JFvaqLratsFxOaD60pjzuwC5xjdTjm3pvQvRVkRxIwAglUgwAvvUfnxiksGcuNx2C87c r1Zl3iTPDn+8gR0OXYpK4kiKFgM1agTbbgCLwzH+J9YyN+P/kM8ybypni4uMz7xey5i6 hDdMW2yzSSsDPWdaWQ8tw2KQq3buRJvKs9pn+BRMQn6KgMo5zwA/Kalvw8rlS8+kAg19 SZvA==
MIME-Version: 1.0
X-Received: by 10.236.128.180 with SMTP id f40mr4332382yhi.71.1397929468335; Sat, 19 Apr 2014 10:44:28 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Sat, 19 Apr 2014 10:44:28 -0700 (PDT)
In-Reply-To: <r422Ps-1075i-43D743DBEE6346E8AE549E0553E2F454@Williams-MacBook-Pro.local>
References: <m2a9bkkk3k.fsf@usma1mc-0csx92.kendall.corp.akamai.com> <r422Ps-1075i-43D743DBEE6346E8AE549E0553E2F454@Williams-MacBook-Pro.local>
Date: Sat, 19 Apr 2014 10:44:28 -0700
Message-ID: <CACsn0cm9-V9eGZxPprCU81SLuXg5wpRqmwqLUZ54V0XBKS+9Dg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Bill Frantz <frantz@pwpconsult.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sHoT33FrzcKuvtanljc8UD2C_4c
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating more (DSA?)
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 17:44:37 -0000
On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz <frantz@pwpconsult.com> wrote: > There are two use cases to keep in mind here: > > There are environments which need authentication and replay protection but > can not use secrecy. Amateur radio communications comes to mind where the > FCC regulations forbid encoding a message with the intent of obscuring its > meaning. > > Now the risks of having secrecy compromised in the many palaces we want to > have it out weigh the advantages of supporting this small part of of the use > space, but at least we should think for a moment about the choice. Authenticated only channels are occasionally nice, we can do them, but most users don't need them, and most implementations don't keep them separate enough to avoid mistakes. > > > The other use case to always keep in mind is limited performance devices. > With the Internet of Things, we will continue to see new 8 bit, and possibly > even 4 bit processors as manufactures drive in the direction of the small, > low power, and cheap. These devices will be much safer if they have > authentication and replay protection. While secrecy is probably not as > important, it might also be vital in certain applications of these devices. So AES-CCM fixes one issue (the wire PDU), but we really, really, need a hash for the handshake. These devices also might not even have random number generators that aren't deterministic or a counter to avoid replays. There's a lot to be done: benchmarking, thinking hard about protocol problems that might cause issues, determining what we can and cannot provide. >From some cursory research, hash functions are the real issue here. AES is byte-oriented, but Keccak is slow as molasses at big capacities sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR benchmark data? JW Bos has some ideas about reusing AES in a hash construction of double the size. With ECC life can get interesting. Drop the idea of RSA and DHE over F_p: too slow. 8 bit saturated arithmetic is probably the best. Timings are pretty slow: lots of verifications are a terrible idea. With PSK you don't need any of this, but I think that some embedded CPUs have the horsepower to do ECC, even at 8 bits. Make sure that this happens rarely, i.e. mostly static keys so results can be cached, and I think we are good. Due to memory pressure ladders are great. I've never seen a 4 bit micro. Anyone got details on what they are like and can do? Sincerely, Watson Ladd > > Cheers - Bill > > ----------------------------------------------------------------------- > Bill Frantz | Truth and love must prevail | Periwinkle > (408)356-8506 | over lies and hate. | 16345 Englewood Ave > www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Matt Caswell
- [TLS] Deprecating RC4 (was: draft-ietf-tls-encryp… Eric Rescorla
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Thomson
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Kurt Roeckx
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Daniel Kahn Gillmor
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Peter Yee
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Andrei Popov
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Stephen Checkoway
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Yoav Nir
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Geoffrey Keating
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Jim Schaad
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Johannes Merkle
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Stephen Farrell
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Richard Hartmann
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Yoav Nir
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Warren Kumari
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Eric Rescorla
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Rex
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Thomson
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Rex
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Watson Ladd
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Bill Frantz
- [TLS] Deprecating more (DSA?) (was Re: Deprecatin… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Yoav Nir
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Daniel Kahn Gillmor
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Tom Ritter
- Re: [TLS] Deprecating more (DSA?) Alyssa Rowan
- Re: [TLS] Deprecating more (DSA?) Joseph Salowey (jsalowey)
- Re: [TLS] Deprecating more (DSA?) Watson Ladd
- Re: [TLS] Deprecating more (DSA?) Alyssa Rowan
- Re: [TLS] Deprecating more (DSA?) Johannes Merkle
- Re: [TLS] Deprecating more (DSA?) Brian Sniffen
- Re: [TLS] Deprecating more (DSA?) Bill Frantz
- Re: [TLS] Deprecating more (DSA?) Watson Ladd
- Re: [TLS] Deprecating more (DSA?) Samuel Neves
- Re: [TLS] Deprecating more (DSA?) Bill Frantz