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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Mon, 13 November 2017 05:15 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
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 5D1F312778E; Sun, 12 Nov 2017 21:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 YXARao4Z90nj; Sun, 12 Nov 2017 21:15:46 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D601270A0; Sun, 12 Nov 2017 21:15:46 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vAD5Fj1Q064638; Sun, 12 Nov 2017 21:15:45 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAD5Fjhc022310; Sun, 12 Nov 2017 21:15:45 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Eric Rescorla <ekr@rtfm.com>
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
In-Reply-To: <CABcZeBMQfsuGDc3AwTwBmMCNs+hmCmW_vUCOH4x7WqiTD6NuAQ@mail.gmail.com>
References: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com> <87inee6gzq.fsf@ta.scs.stanford.edu> <CABcZeBMQfsuGDc3AwTwBmMCNs+hmCmW_vUCOH4x7WqiTD6NuAQ@mail.gmail.com>
Reply-To: David Mazieres expires 2018-02-10 PST <mazieres-zse86chdgimdjidwu6yu8xgz56@temporary-address.scs.stanford.edu>
Date: Sun, 12 Nov 2017 21:15:45 -0800
Message-ID: <8760aekbcu.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/o6oP8brj_HJRm73BEFzy8RuZLBs>
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 05:15:47 -0000

Eric Rescorla <ekr@rtfm.com> writes:

>> >    connection or when there is any ambiguity over the meaning of the SYN
>> >    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.  Am I correct that you
may just not have picked up the definition in the first paragraph and
that given the definition the rest of the section makes sense?

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?

>> >    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!

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.  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...

Thanks,
David