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

Eric Rescorla <> Mon, 13 November 2017 05:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF82A12948A for <>; Sun, 12 Nov 2017 21:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6posEKS3VNPm for <>; Sun, 12 Nov 2017 21:30:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8160212948B for <>; Sun, 12 Nov 2017 21:29:54 -0800 (PST)
Received: by with SMTP id q126so12510117ywq.10 for <>; Sun, 12 Nov 2017 21:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JS2vLvbfMkJ1QX6CLWHGYL5+TQTMjmKI/t+wjwpgcL4=; b=l3Hqn5uI3MGVM2U6AzEai0iadMXxNPUgIDN5fchJG8E7GphggHO7dWBjpf0nyKLNZ2 oqMEmu5SszzB/OFpuoVG5c/ZMcj5YOpyjdqiU0jJnjtIVjLiqkfSxwjHZu3KMX2+wki0 T/B58V0PBMroFcd34nPEbSffK25uXK4TnxymF+nwv1Bbfq87zvQPShuyeWAsM5wUUwDC D7HRtVPBr/RbEMw8qBgXXc5Q3H8CBytcYC+lLxumxQyhCOQZh3AHmHn+W0XGFMYLwnE6 +d/GlW4C+4Nc10fMhnVUVbeJRV33Y8pIQBd7SPy5nn2sX+EpNfseQJaaOpApt4hKuNGK tS8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JS2vLvbfMkJ1QX6CLWHGYL5+TQTMjmKI/t+wjwpgcL4=; b=WDCDyl1BEfUy61ueql/OLATEV63vFTU2qCH3ZUhmNxC73mtyhv1AgasKrQk3ZX9HF1 3EMEPYiDEmWKdoSx0ewLaznIrufSrQ/mU7S8WeT63g0ZeEudHbmm4+QSH5PC3ZpWG8pP o8KrOgIMGZb+SdQPzYgRSNSxthJecVkko4mDT28VjE25a3OsL9fbpEdSCEwAyT7In43i L6WVs+xsZbOmbG4Ez6nCvatJLeJZ0sU6XQeRABiSj7ePKdfNpqbD+0ZJe8nRDUGZJzCh hE9/fvVFw1EXI7mrSaIMZ3Szkyf5sEoBsBJTrfc7Z36aAMUfywrdcwCaQarqU5qa7R59 zR3A==
X-Gm-Message-State: AJaThX4TmMWVeVSLGqsiC1I4yeVEXvgILc3p1UiSay3zQpm495I2jcBx C0XLJq0/PJdV+Q+HAfTdXC0c1Q+jgwJplr+ilcg6nqvZ
X-Google-Smtp-Source: AGs4zMae49z8H3BBxusRo5KnBV6DVYbAKP7dQnl7R+3Be+H+5xRlWh5jO7HUUvkZyUlO1w+cHKhRUxac9gM4XAYez5s=
X-Received: by with SMTP id v200mr2035540ybe.348.1510550993742; Sun, 12 Nov 2017 21:29:53 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 12 Nov 2017 21:29:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 13 Nov 2017 05:29:12 +0000
Message-ID: <>
To: David Mazieres expires 2018-02-10 PST <>
Cc: The IESG <>, tcpinc <>, "Black, David" <>,,
Content-Type: multipart/alternative; boundary="94eb2c146f6265c07c055dd68f57"
Archived-At: <>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 05:30:06 -0000

On Mon, Nov 13, 2017 at 5:15 AM, David Mazieres <> wrote:

> Eric Rescorla <> writes:
> >> >    connection or when there is any ambiguity over the meaning of the
> >> >    data.  This requirement applies to hosts that implement ENO even
> when
> >> >    ENO has been disabled by configuration.  However, note that
> >> > I think you may mean to say "when the last SYN TEP is not eventually
> >> negotiated"
> >>
> >> No, we definitely mean *any* ambiguity, including other unrelated RFCs.
> >> Like if the segment contains a non-empty TFO option, for example.  This
> >> is clarified again below, with:
> >>
> >> * The SYN segment contains a non-empty TFO option or any other TCP
> >>   option implying a conflicting definition of SYN data.
> >>
> >> So does this need a clarification, or is the existing wording okay?
> >>
> >
> > Sorry, I meant to replace "When the SYN TEP does not govern the
> > connection", not the point about ambiguity,.
> 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
here to the specific feature of the packet.

If that's the case, then rather than fix the sentence you highlighted, I
> think we need a better term/and or better definition.  What about
> "SYN-data TEP", since it's the TEP governing data in the SYN segment?

i don't really understand what you are proposing here.

> >> >    o  TEPs MUST NOT depend on long-lived secrets for data
> >> >       confidentiality, as implementations SHOULD provide forward
> secrecy
> >> >       some bounded, short time after the close of a TCP connection.
> >> > Maybe "depend solely" because one might want to use a DH mode where a
> >> static DH
> >> > key is mixed in with an ephemeral.
> >>
> >> I'm confused by this comment.  Either you depend on a long-lived secret
> >> for data confidentiality or you don't.  In your example, would
> >> compromising the long-lived DH key also break past connections?  If so,
> >> then you have a bad TEP.  If not, then you don't depend on a long-lived
> >> secret for confidentiality, so your TEP is permissible.
> >>
> >
> > Well, as Cas Cremers keeps pointing out, if you also had a weak PRNG,
> > then you would in fact be depending on the static DH key. I think my
> problem
> > is the word "depend" which seems imprecise.
> >
> > It' s clumsy but perhaps
> > "TEPs MUST NOT be designed so that compromise of a long-lived secret
> > compromises confidentiality"
> The security considerations section already makes having an adequate
> source of randomness a MUST, so indeed we categorically want to rule out
> a weak PRNG in the normative language!

I don't disagree with that. But implementations have defects sometimes and
see my point about pinning below

Remember, the "MUST" in question is a requirements for TEPs, not for TEP
> implementations.  We deliberately made forward secrecy of the
> implementation only a SHOULD.  However, the TEP itself MUST be designed
> to avoid dependence on long-lived secrets for data confidentiality.  I
> believe the existing language correctly prohibits TEPs from requiring
> long-lived static DH keys, even if certain *implementations* wind up
> keeping keys around longer than indicated by the TEP specification.
> 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.

> However, I can't figure out what that is because I don't
> see how to make long-lived static DH parameters useful in a TEP.
Long-lived static DH parameters seem more useful for some kind of
> higher-layer application protocol that authenticates session IDs...

They are useful in two ways:

1. If you wanted to do TOFU on the remote key.
2. If you were concerned about the ephemeral PRNG (even if you intended
it to be strong) but you believed your initial PRNG to be strong.


> Thanks,
> David