Re: [Tcpcrypt] Initial questions
Derek Fawcus <dfawcus+lists-tcpcrypt@employees.org> Sun, 22 June 2014 13:07 UTC
Return-Path: <dfawcus@employees.org>
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 F11A71B2946 for <tcpcrypt@ietfa.amsl.com>; Sun, 22 Jun 2014 06:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level:
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 tEiLwoFoVWaR for <tcpcrypt@ietfa.amsl.com>; Sun, 22 Jun 2014 06:06:58 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EB61B2938 for <tcpcrypt@ietf.org>; Sun, 22 Jun 2014 06:06:58 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 97B8964F1 for <tcpcrypt@ietf.org>; Sun, 22 Jun 2014 06:06:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=Fq8avlYATK62z5SVuftUICQjZlo=; b=lJ PJzSnm+0Ii5ARguCEMSH42HYqliw6Uz6MpuUHyR5j/AbZm83eDhqtFTHELPgeZ5f ch1nihp6I+G5biuJ/MmZqRXpYOWd60XopUyP8wRA5oaWTx6nXgq3YYjSyhyGJl49 SeLoD+whumP/oBG/swji6zWkLoE4CYk0ebCjlcLwI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=Vd7LDH4PA7i2SjUNC/FbqAN54vUC dcmjnf3ps82/8gQfjikVWfi0paBhtdCjSlQUeVs5ZKM7BvVWYNwJ8kU2p3dPnwbb hbBStwNflf+GJRNxCgQPXnqh1BGkZvAaajIm/B2sNwy8/mBrMAt4nT8rY7NBHjd2 6W0MfQg4hqfjh5s=
Received: by banjo.employees.org (Postfix, from userid 1736) id 8366764C7; Sun, 22 Jun 2014 06:06:57 -0700 (PDT)
Date: Sun, 22 Jun 2014 06:06:57 -0700
From: Derek Fawcus <dfawcus+lists-tcpcrypt@employees.org>
To: tcpcrypt@ietf.org
Message-ID: <20140622130657.GB39625@banjo.employees.org>
References: <CACXcFmmQCgTu6-QLJZdH8Q+ZST97ugoTaUWCUV0S6AWsjvCGfg@mail.gmail.com> <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> <53A32D5A.10007@isi.edu> <53A3D122.8030501@iang.org> <53A4B462.7010106@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <53A4B462.7010106@isi.edu>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/i7RduJ7VuNQgMyZjQyub7-OJdCs
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: Sun, 22 Jun 2014 13:07:01 -0000
On Fri, Jun 20, 2014 at 03:23:30PM -0700, Joe Touch wrote: > > That's my view, and you've already disagreed with it; let's see what > others have to say. I like the idea of the initiator being able to specify the crypto algorithm, say an 8 bit value, we have 1 or 2 intially defined. If the receiver doesn't support the selected algorithm, the whole tcpcrypt option will fail and we fallback to unencrypted. Thereafter the initiator (application or host stack - not sure which) can decide to terminate the connection, and maybe retry with a different algorithm, continue unencryted, or whatever. i.e. local policy. The idea being that we deploy with one recommended algorithm which everyone supports, and if a sucessful attack is found on it, we can switch over to the next algorithm. I don't think the endpoints should negotiate the algorithm, if the initiators choice is not supported, the session is unencryted. i.e. avoid round trips to agree/negotiate an algorithm, and don't supply a list of choices in the initiation. I'm not sure of the effect with simultaneous open, but probably OK until the recommended version changes. .pdf
- [Tcpcrypt] Initial questions Sandy Harris
- Re: [Tcpcrypt] Initial questions Tony Arcieri
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions marcelo bagnulo braun
- Re: [Tcpcrypt] Initial questions marcelo bagnulo braun
- Re: [Tcpcrypt] Initial questions ianG
- Re: [Tcpcrypt] Initial questions ianG
- Re: [Tcpcrypt] Initial questions ianG
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions ianG
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions ianG
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions Tony Arcieri
- Re: [Tcpcrypt] Initial questions Derek Fawcus
- Re: [Tcpcrypt] Initial questions Derek Fawcus
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions Stephen Kent
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions ianG
- Re: [Tcpcrypt] Initial questions Sandy Harris
- Re: [Tcpcrypt] Initial questions Joe Touch
- Re: [Tcpcrypt] Initial questions Stephen Farrell
- Re: [Tcpcrypt] Initial questions Stephen Farrell
- Re: [Tcpcrypt] Initial questions Tero Kivinen