[TLS] Thoughts on Hardware Support

Watson Ladd <watsonbladd@gmail.com> Sat, 14 February 2015 19:23 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 7AE3D1A01E7 for <tls@ietfa.amsl.com>; Sat, 14 Feb 2015 11:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 JC-jdzO0aFVc for <tls@ietfa.amsl.com>; Sat, 14 Feb 2015 11:23:34 -0800 (PST)
Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (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 97EEE1A0191 for <tls@ietf.org>; Sat, 14 Feb 2015 11:23:31 -0800 (PST)
Received: by mail-yh0-f45.google.com with SMTP id a41so11004362yho.4 for <tls@ietf.org>; Sat, 14 Feb 2015 11:23:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/Lql4o3H/HcLFd5aysXGPcaiWyImfL/mYTzUPOfqafY=; b=Q7i95e9Q9NCK64W69rysY+jAXkC5bDhsFb9L+MkQgXX9lS4yRUsunL6UfXKFm3X1gj EeslFONmQuAnQdHsKXx0/nrsDIq40RaaN2UhkDqJlPvRFCYjMKOzEfDeHVmuDnteSSbu wL46ZYtNci5YjcKlyglGQUmrqo0bSyhnMOLdqIcLVIwck1GcbtH52xI1APGrrj3akQLx 252C2ITrqoMPn8wfQRjCai/QMBRh/eDhXybG7nt0hKSlAhDjzH7tLEzVPo2lT+TGJFlG oFiB+mmyGXywGRK0hdkaeOYJvHsjwOBeFw3LkKhxNZ60T8fA4BXHAAH0XeTZAHNsWj/b JL2g==
MIME-Version: 1.0
X-Received: by 10.236.220.65 with SMTP id n61mr12583378yhp.44.1423941810876; Sat, 14 Feb 2015 11:23:30 -0800 (PST)
Received: by 10.170.126.10 with HTTP; Sat, 14 Feb 2015 11:23:30 -0800 (PST)
Date: Sat, 14 Feb 2015 11:23:30 -0800
Message-ID: <CACsn0cnuHDwOXtqrFwqzVvUQTWxawBRea9it9_URVvZJsjHjWg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pU7SihJ-C26bD7NRI0wVEGd4uDc>
Subject: [TLS] Thoughts on Hardware Support
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, 14 Feb 2015 19:23:37 -0000

Dear all,

A while ago I promised Michael St. Johns to think hard about his goal
of making it possible to use hardware to secure the record layer
without dirty hacks. For those unaware of the problem, the same key is
used to derive encryption keys that shouldn't go out on the wire, and
IVs that do, and so it becomes difficult to ensure that keys can't be
leaked, if you expose the IV generation.

I think the easiest way is to eliminate the IV derivation entirely,
and have the record layer send the entire nonce each time. if that's
too much a waste of bandwidth, then we can specify entirely the
portion that is in TLS 1.2 derived from the MS. I think this is in
spirit similar to his proposal, but I don't recall the exact details.

I'm sure there are disadvantages of this change I am missing, or
aspects of the problem that I'm neglecting, but I seem to recall this
being the major issue.

Sincerely,
Watson Ladd