Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Mon, 13 November 2017 06:17 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0512949F for <tcpinc@ietfa.amsl.com>; Sun, 12 Nov 2017 22:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 LKf2_IQ2iXDa for <tcpinc@ietfa.amsl.com>; Sun, 12 Nov 2017 22:17:24 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 9620F129484 for <tcpinc@ietf.org>; Sun, 12 Nov 2017 22:17:24 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id k3so12565717ywk.8 for <tcpinc@ietf.org>; Sun, 12 Nov 2017 22:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2UcX3T7bnSnUhSDJQf4ohFaJgLEa2SSFm0CIGJeJscc=; b=a+horSvmsndTpwYe4ATNHgwuK1/B3JoHXnDPkVqcTnlbpazy8ec2ligkHflxHw7GpH kkQRYmF6R9GsVwWz3CCvF41AynkwSzsil/JcDVK2kxSvTAG8tN7PP4LQnaX6LVQdLQjs YqGDxjfH3gYOBWho0ujIyB0nGPxOWDfONsv7nsueIgWZUVeoAjNYfI5fQHGNNCmI3LsY WOSoed+4zTA+K45QvUbaPA2HSFrb6HDhw+hRCEg3F4bWIGvrMyIGky0F7CaS1NZC96Aj nc+SwN/RcBPr/S96y8/16PPwODqkNbSXOP7Gxm3hqZBP12lAHZSdkAy1zeX7diJDcrT5 BmEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2UcX3T7bnSnUhSDJQf4ohFaJgLEa2SSFm0CIGJeJscc=; b=LVV/oYPKp49NjMmhLnRIx+vQ6AuCjEvytNCeEyVKj6TjWgMONKjfW8yPrcDyEdVhIg 6wbmyEGrI5JCD/0GxxBQE/SR2x71YsQzPxPLv0b2+kJ1awCAfM9yQ31hbo5fyCjx+iNd opmFPVZ7d35eIdcQ9dZddgf6TU9kJ/hOf6/8me0eBOQHfDIt2u3xi126iTZZmgXW0m70 RlgpVHKpJrVSuMmch/m7oTgx/zw9yRcFy1TdcQVmnzbl2OHhNYSNQV7jhrSNAL/veJs6 TY/8H+mjdwyPK2EjV7gPIm//iWvL0L3h37fUyprYNHA/iCxKKaXx+7yKIJvELRAQHV8X sPOQ==
X-Gm-Message-State: AJaThX5ib83Mng6oGRys+qA42QeKH9nKlp3jvU+sK5sCIaBadPVgvk5g mMVeF7T8VqVyUMdbaVatq9nghAx66BRGx+rjgkz38A==
X-Google-Smtp-Source: AGs4zMZnAZWwTOIOf1dbb2Sf9K/DXrKZVptlGUQ9qOUyzHMCiBOgE3R0GxIt6VqlxZwpwOmxXQAyroD3nLz9ngldDIE=
X-Received: by 10.13.203.205 with SMTP id n196mr4044591ywd.280.1510553843853; Sun, 12 Nov 2017 22:17:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sun, 12 Nov 2017 22:16:43 -0800 (PST)
In-Reply-To: <87inee7lly.fsf@ta.scs.stanford.edu>
References: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com> <87inee6gzq.fsf@ta.scs.stanford.edu> <CABcZeBMQfsuGDc3AwTwBmMCNs+hmCmW_vUCOH4x7WqiTD6NuAQ@mail.gmail.com> <8760aekbcu.fsf@ta.scs.stanford.edu> <CABcZeBM1rnR=Q2Evj-Pt8TpajRXah6q0Go6NOjMk_SB-fUT0yg@mail.gmail.com> <87inee7lly.fsf@ta.scs.stanford.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 13 Nov 2017 06:16:43 +0000
Message-ID: <CABcZeBPMGBMSdVdLFvfJURH7yaQH97MmLtd3gzAKOThmoZj8cg@mail.gmail.com>
To: David Mazieres expires 2018-02-10 PST <mazieres-8kczz844u5tupynhf38ddvt7k2@temporary-address.scs.stanford.edu>
Cc: The IESG <iesg@ietf.org>, tcpinc <tcpinc@ietf.org>, "Black, David" <david.black@dell.com>, tcpinc-chairs@ietf.org, draft-ietf-tcpinc-tcpeno@ietf.org
Content-Type: multipart/alternative; boundary="001a114e43804705d2055dd739f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/JkPg2_6knOU4nOETQVcQclNFUMo>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <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: Mon, 13 Nov 2017 06:17:27 -0000

On Mon, Nov 13, 2017 at 6:12 AM, David Mazieres expires 2018-02-10 PST <
mazieres-8kczz844u5tupynhf38ddvt7k2@temporary-address.scs.stanford.edu>;
wrote:

> Eric Rescorla <ekr@rtfm.com>; writes:
>
> >> So in the first paragraph of the section, we define SYN TEP as follows:
> >>
> >>         The meaning of data in a SYN segment with an ENO option (a
> >>         SYN+ENO segment) is determined by the last TEP identifier in the
> >>         ENO option, which we term the segment's _SYN TEP_.
> >>
> >> So I think the problem here may be that the term SYN TEP is confusing,
> >> or that the definition does not stand out enough.
> >
> >
> > The problem is that "govern" is not very clear. It's clearer to link the
> > requirement
> > here to the specific feature of the packet.
>
> Okay, let me futz with the language a bit and try to get rid of or
> clearly define the term govern.
>

Thanks


>> If you still think there's a problem with the current language, can you
> >> supply a more concrete example?  It sounds like you have a specific kind
> >> of protocol in mind that you think should be legal but isn't under the
> >> current draft.
> >
> >
> > Sure. OPTLS for example. This has PFS but also is robust against
> compromise
> > of the ephemeral key.
>
> Got it, thanks.  How about the following?
>
>         TEPs MUST guarantee the confidentiality of TCP streams without
>         assuming the security of any long-lived secrets.
>

SGTM.

Thanks
-Ekr


> David
>