Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt

Nico Williams <nico@cryptonector.com> Wed, 16 May 2012 20:30 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A9D21F86FC for <tls@ietfa.amsl.com>; Wed, 16 May 2012 13:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level:
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1vIkBcMJ5DF for <tls@ietfa.amsl.com>; Wed, 16 May 2012 13:30:47 -0700 (PDT)
Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0A21F86F3 for <tls@ietf.org>; Wed, 16 May 2012 13:30:47 -0700 (PDT)
Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 44E331F0086 for <tls@ietf.org>; Wed, 16 May 2012 13:30:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=hYvkedylMOC7tK38nhrdy VIpQ8/4NS6n0qJcdOE6hFLfHgDD6JGdhpt2PIRWOOwkzwpu8YUkaEoiJP9Ym6/pX w8u9mY5zNaR6rKFRxfFMTidhhdKNlw8In7rXZyUi/L+TR72kEeSHP3rInzoQH3P9 Anc6JSYUpQ00GjUMyfbrCM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=09w/CB5JzzoX2lESq81e U/hQRqo=; b=GSuJpDUt80T6sf7PIRzYnBl0ItJKyaIkrcwJCYIgJSRACPdf9yQf BrccfG3/GmYqHPW42pf1TTBgf/Epq/DRtb0D1YSmq+Ht1uLgx/ow1aq1DfJi7f+v cPImhVrbdaEIlWECIVq1oHEa9+LYdz+npG7VGHK+IWF85FjPeWhS94A=
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 169A21F007C for <tls@ietf.org>; Wed, 16 May 2012 13:30:47 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so1620912pbc.31 for <tls@ietf.org>; Wed, 16 May 2012 13:30:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.237.166 with SMTP id vd6mr19650328pbc.139.1337200246614; Wed, 16 May 2012 13:30:46 -0700 (PDT)
Received: by 10.68.5.99 with HTTP; Wed, 16 May 2012 13:30:46 -0700 (PDT)
In-Reply-To: <CABcZeBP=09qyD4Nuw_i-7yM9EPzZY_sPm8jVcjTneJPknP1Lug@mail.gmail.com>
References: <4FA401F7.5060003@extendedsubset.com> <CABcZeBP=09qyD4Nuw_i-7yM9EPzZY_sPm8jVcjTneJPknP1Lug@mail.gmail.com>
Date: Wed, 16 May 2012 15:30:46 -0500
Message-ID: <CAK3OfOjTKDRNp2iw-AY_XWF_YgEvx5DPzAihzCfJH9prtrZw5g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 16 May 2012 20:30:48 -0000

Eric,

In addition to Nikos' point I'd like to point out that it's not just
the things this approach would protect today, but also the future
extensions that it will also protect.  More importantly, I think
starting cryptographic protection as early as possible is a good
design goal in general.

It is worth asking whether these changes are worthwhile, of course.
Even if desirable, if they were to be too difficult to implement
and/or deploy then desirability might not be sufficient.  But I think
it's too soon to tell that this is too difficult to implement.  I
don't think Marsh's proposal does quite as much violence to
implementations as you seem to think, and in any case, that's a
one-time hit.  The bigger concern for me is whether refactoring can be
done so as to keep the complexity of implementation withing acceptable
limits, but I think that must be possible anyways.

Nico
--