Re: [Tcpcrypt] New version of the charter text

Tony Arcieri <bascule@gmail.com> Sun, 27 April 2014 21:08 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: tcpcrypt@ietfa.amsl.com
Delivered-To: tcpcrypt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381981A07C8 for <tcpcrypt@ietfa.amsl.com>; Sun, 27 Apr 2014 14:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 6fUTm2J2s4H0 for <tcpcrypt@ietfa.amsl.com>; Sun, 27 Apr 2014 14:08:23 -0700 (PDT)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 514201A07C0 for <tcpcrypt@ietf.org>; Sun, 27 Apr 2014 14:07:51 -0700 (PDT)
Received: by mail-ve0-f180.google.com with SMTP id jz11so6986371veb.39 for <tcpcrypt@ietf.org>; Sun, 27 Apr 2014 14:07:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JiopLpW8qKJB8T1oeuJi2q0Z4OivHOoPU+uLu2gfJJ8=; b=K6uRaEpXsV8zgfeZ15toPmREGHaurpyifcpEMdXJOy7zX9ksZLCVoVl8Ch6o7m4F/E WymN0Y9CZ2crKcMvRl5KgXRObXnRyPh1xbckdrM5Kp0IUgE8FwNqPOd1Lfeco+03lc2m lGlij+ccc51mx7j9mK/LD59Wv8ONJg2HfjkhUtGk3KJnvMxKKoSPk8Dh1WV2gNnRHiWh 8eZgHCqebkJ1Hre0w93fSiHivptO2zr39WDTdYaRT7hruAUAac9T2GhxlDF91f9I7Ojk Ur4dDULB4k7p9XIrRsdmR2RDLW1Gp5I646BFMV3gfVb9YJXxtRkBh6IcsykEKrCPS4OD QlbA==
X-Received: by 10.220.59.65 with SMTP id k1mr19780042vch.22.1398632870603; Sun, 27 Apr 2014 14:07:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.243.202 with HTTP; Sun, 27 Apr 2014 14:07:30 -0700 (PDT)
In-Reply-To: <535D701E.6030004@iang.org>
References: <53576572.5030805@it.uc3m.es> <535D636D.8050108@iang.org> <535D6BF2.6040304@it.uc3m.es> <535D701E.6030004@iang.org>
From: Tony Arcieri <bascule@gmail.com>
Date: Sun, 27 Apr 2014 14:07:30 -0700
Message-ID: <CAHOTMVKYvgkF79YgcOQtWbALvtPNU5r22jShS+zwy0kxWGL-Xw@mail.gmail.com>
To: ianG <iang@iang.org>
Content-Type: multipart/alternative; boundary="001a11c295026c716e04f80c978e"
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/5ZfjXMieV8HpdOXYevdt5jBDQrU
Cc: "tcpcrypt@ietf.org" <tcpcrypt@ietf.org>
Subject: Re: [Tcpcrypt] New version of the charter text
X-BeenThere: tcpcrypt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpcrypt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpcrypt/>
List-Post: <mailto:tcpcrypt@ietf.org>
List-Help: <mailto:tcpcrypt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Apr 2014 21:08:28 -0000

On Sun, Apr 27, 2014 at 2:01 PM, ianG <iang@iang.org> wrote:

> Well.  I think the RFC should list it as a MAY so that people who read
>  it can be alerted to the fact that they had better figure out how this
> happens and make sure it never happens on their watch.
>
> I don't think it should be a SHOULD because I've yet to see a valid
> reason for it.  All of the reasons so far presented have been handwavy,
> very edge-case or development only.
>
> And I don't see its place in the Charter.  It seems like cursing the
> baby before its been born.


I'm not even sure why it's being considered for the charter. This is not a
feature offered by, say, full disk encryption software, even though people
may wind up double encrypting files. It's also proven not to be a problem
in practice, even though the need to decrypt bypasses things like DMA.

It seems even less important for ubiquitous network encryption, where the
network is far more likely to be the bottleneck.

-- 
Tony Arcieri