Re: [Tcpcrypt] Initial questions

Joe Touch <touch@isi.edu> Tue, 24 June 2014 18:23 UTC

Return-Path: <touch@isi.edu>
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 9D8F71A0406 for <tcpcrypt@ietfa.amsl.com>; Tue, 24 Jun 2014 11:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 mkiqTpFK4pm6 for <tcpcrypt@ietfa.amsl.com>; Tue, 24 Jun 2014 11:23:47 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394B51A040A for <tcpcrypt@ietf.org>; Tue, 24 Jun 2014 11:22:45 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5OIMRKQ023334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 11:22:28 -0700 (PDT)
Message-ID: <53A9C1E3.5060605@isi.edu>
Date: Tue, 24 Jun 2014 11:22:27 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>, tcpcrypt@ietf.org
References: <CACXcFmmQCgTu6-QLJZdH8Q+ZST97ugoTaUWCUV0S6AWsjvCGfg@mail.gmail.com> <53A98F00.4000702@bbn.com>
In-Reply-To: <53A98F00.4000702@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/EWB5xQGIRfz02y3Uf01BSn-K7Sg
Subject: Re: [Tcpcrypt] Initial questions
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: Tue, 24 Jun 2014 18:23:48 -0000


On 6/24/2014 7:45 AM, Stephen Kent wrote:
> Sandy,
...
>> The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than
>> nothing security", which they implemented as an unauthenticated mode
>> for IPsec. That sounds much like what we are aiming at. Can we just
>> work on getting BTNS deployed, thereby protecting both TCP and other
>> protocols?
 >
> I think the folks who pursue BTNS are best-equipped to address that
> question. Ask Sam Hartman, maybe Joe would like to comment as well.

RFC5925 already describes the rationale for TCP authentication vs. 
IPsec. The same issues are relevant for TCP encryption.

The other aspect of BTNS - use of DH without authentication (which isn't 
TOFU; it's trust-on-any-use in a sense because IDs aren't retained) 
might be similar to various approaches offered here (e.g., it's the 
basis of draft-touch-tcp-ao-encrypt.

Joe