IETF Logo Mail Archive

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

Kyle Rose <krose@krose.org> Thu, 27 August 2015 16:52 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B561B36C5 for <tcpinc@ietfa.amsl.com>; Thu, 27 Aug 2015 09:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 5CKz9fjX4xv9 for <tcpinc@ietfa.amsl.com>; Thu, 27 Aug 2015 09:52:38 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 CB7821A03C7 for <tcpinc@ietf.org>; Thu, 27 Aug 2015 09:52:38 -0700 (PDT)
Received: by iodv127 with SMTP id v127so64110693iod.3 for <tcpinc@ietf.org>; Thu, 27 Aug 2015 09:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZUiYouXRaOQM5B1fiFYUpk0nXAi41T8feGlYjVmuCd4=; b=i43SBkBLZCdOtRNzeg97WWfDdouNQSbzEH6NsF8h+vwVTBQWvjZdnQZGeYoiokvTPB /v4S1qQtnLn+rq8JidmOGGPcUPUuw8i95cEKs431mlnyCpw7czinQTxpsHbuAxoNBdJk dbRQSFQ/UMZnaBgC4FPP8wGE00LaSFGxIuZds=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZUiYouXRaOQM5B1fiFYUpk0nXAi41T8feGlYjVmuCd4=; b=Rwj8pQFXAImFY3r7jBA7CtNhLKC+z7xYOXoFxM93Hqwll7ZHaUNve/cUwMmxmk7Yx0 aNVWz84ucLre/BqJKBWZipEmgUXJK25Cuev+xh+QCn8GLuGAk9pPC+lVbNZA1XvJtDrH w8b1tNJ59x41DFKdzkih8j40vjuL6zRy2lnEYjkE7q0FFVvIv8D/tiPOfg0W9hi3660/ s7Ack8gvmbkAxKtvlVMbl7k4tkcrXlGzr0nckvfeGQz1q7cl73RdWsNZIEdbLpTz8lLu k6fu5ytSpVfK6GikVF2YhpQN5DhtWXwF4o6TwBRacq2vzvHofU/xp5GQtSJO1PWftmUH 19dg==
X-Gm-Message-State: ALoCoQmxsQEwRO1p9G5IwgVOQekdK7BNhrrIeYjyvhmz5MqwZcoF4qWvaPYQQbzT2ZN+KvJFX6Sa
MIME-Version: 1.0
X-Received: by 10.107.13.3 with SMTP id 3mr10624043ion.70.1440694358324; Thu, 27 Aug 2015 09:52:38 -0700 (PDT)
Received: by 10.79.31.197 with HTTP; Thu, 27 Aug 2015 09:52:38 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <87twrkhfpg.fsf@ta.scs.stanford.edu>
References: <CABcZeBNEFVkDi38y3G-C2nQF=dzW2mGDsj5DVK_OKVkPwK=G0g@mail.gmail.com> <878u92oadf.fsf@ta.scs.stanford.edu> <CABcZeBMfk5C4-LF0fDLKpJktV3hJyzRUNfe0gO8RYDnzcs3yMA@mail.gmail.com> <87zj1inf7n.fsf@ta.scs.stanford.edu> <CABcZeBMZCjrwpTH+CkZS_p8TYGEFsXwxGn=KfPe28hY5f=2oXw@mail.gmail.com> <87oahuta7j.fsf@ta.scs.stanford.edu> <CABcZeBPiUxByxUVJ3cb5LaeH5T1LX3iZFetP4cXM3O9avzBkCA@mail.gmail.com> <87si75jo4s.fsf@ta.scs.stanford.edu> <BDF93B3E-9DE0-4FEA-A4A7-6E6A69E4169B@tik.ee.ethz.ch> <87h9nkkcqc.fsf@ta.scs.stanford.edu> <55DF25DC.2040001@tik.ee.ethz.ch> <87twrkhfpg.fsf@ta.scs.stanford.edu>
Date: Thu, 27 Aug 2015 12:52:38 -0400
Message-ID: <CAJU8_nWktUwni0=nywx-bbHg+j_K5GWFAZD8g3ZbKx7GLk4jpQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
To: David Mazieres expires 2015-11-25 PST <mazieres-zgv6ivfv5g8jycyazv73izv65s@temporary-address.scs.stanford.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/9Q6ZiC4sl27x5iECa9wt7GTme-8>
Cc: Eric Rescorla <ekr@rtfm.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, tcpinc <tcpinc@ietf.org>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 16:52:41 -0000

I think maybe what Mirja is implying is that it's okay to break TCP
(i.e., not fall back to unencrypted) if the two peers explicitly set
their roles locally to the same thing. TCP-ENO-aware applications that
set the role are assumed to get it right and not set both to A or both
to B.

Question re: the WG goals: is it in fact okay not to always fall back
to unencrypted TCP if the applications themselves are aware of TCPINC
and relying on TCPINC-specific API calls?

Kyle


On Thu, Aug 27, 2015 at 12:13 PM, David Mazieres
<dm-list-tcpcrypt@scs.stanford.edu> wrote:
> Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> writes:
>
>> Don't you need anyway an internal interface to say that tcp-eno has to
>> set the "b" bit?
>>
>> That's simply saying to tcp-eno that this side will be the host A. Isn't this
>> sufficient? Or do I miss something?
>
> You need both a local interface to set the role, and a bit on the wire
> to verify that the remote application set is role compatibly.  Isn't
> that the minimum necessary to break the symmetry of simultaneous open?
> Anything less risks complete connection failure (not just fallback to
> plaintext) when the tie is incorrectly broken.
>
> David
>
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc

v2.23.0 | Report a Bug | By Email