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 02:50 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 D3FDF128E19 for <tcpinc@ietfa.amsl.com>; Sun, 12 Nov 2017 18:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, 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 8UltsRVZjuzP for <tcpinc@ietfa.amsl.com>; Sun, 12 Nov 2017 18:50:37 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 B92D11292CE for <tcpinc@ietf.org>; Sun, 12 Nov 2017 18:50:36 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id r186so3849763ywe.13 for <tcpinc@ietf.org>; Sun, 12 Nov 2017 18:50:36 -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=WrSwGYbdAqkfrY/0fmHJP0w+kZPWGe7CPX6h1QhsWK8=; b=nWUFGFHsxl+M1uj9JI938KAybJ+aTCGtELQcq4TgCRhf1cT1yGtrJLh8lf1A2N+Kz/ OU3sexJ7vtCAKjC7JzHKyGTqmAMcBGrFXFcUAnAH8pyMVk6+eZUbwl2d4xJAiac6wYMv JAYXKBSuCz08T8n08zHb9gH94Gx+r2GfGeP2WHRn/ldljp7vAr2uet2swEr3roUVAcX5 0WK4lyoIhWPbnxgL6GYuWLi2A17E34oeCscJMZKjOJRgmXq/won3wMfOGucMwTEKJpQC fRhLTQD55yQVwOzV6U1mWGxkVL17G8Hn9iTncX8VCKXoqPwyP5Q/cBtAOX1HTOycSn0J Et/g==
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=WrSwGYbdAqkfrY/0fmHJP0w+kZPWGe7CPX6h1QhsWK8=; b=iN2XzZEMe7XB9RLH4tExEHkftOCmreM/scQ/Y1+y+JD7VtA5AtS6fJn9b+pKsdrW1R k4yS1nnlzugJy8m2FSiV4j175EvMAvKUyFlpYwT9AxhUPlakLPTKfKoUCAt9vSrcE+4J lhUR1JHaPVy0DdnNwSO7ZFLeA1dPpM6TrDLeOlyHwOls2xSADpPXo/cDjyV4tv6t97Me 46YDu3FewPhGc8XOO6oo7s2IW02ZWBnhLQqll1OiMrOCWs/cnYT1JLrHOgZ+1nh8VMRY ba496SrkXsjgrMx4AwaGoFgE6zDNULpRSojoSVskwDqbV/+pvSXt67sJ9kb4ilvble8+ Hm4w==
X-Gm-Message-State: AJaThX6uXJI5l8PZtei9i9Gox1omG8UCVTENkIsFz/MKHr7DJp97LVNG fQK5Oyr0I18jIEEfKM8jDnvgn0bi6Dbr/fZbKl6O8GBB
X-Google-Smtp-Source: AGs4zMZArsVZ6bay5mCv9Yw/37dQFiC4BMizEVa9GpUsfV0Rkp9pvmZxlq4XskZj5z5a6wDiR8nVhH1IrHYUu0Yn+PE=
X-Received: by 10.37.119.65 with SMTP id s62mr4876763ybc.339.1510541435978; Sun, 12 Nov 2017 18:50:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sun, 12 Nov 2017 18:49:55 -0800 (PST)
In-Reply-To: <87inee6gzq.fsf@ta.scs.stanford.edu>
References: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com> <87inee6gzq.fsf@ta.scs.stanford.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 13 Nov 2017 10:49:55 +0800
Message-ID: <CABcZeBMQfsuGDc3AwTwBmMCNs+hmCmW_vUCOH4x7WqiTD6NuAQ@mail.gmail.com>
To: David Mazieres expires 2018-02-10 PST <mazieres-q2ynekgb4zac7mwackds7upea6@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="001a114ba444b5c99e055dd45549"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/AuSkInAalAzuLEyskmAr0iSONFI>
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 02:50:40 -0000

On Mon, Nov 13, 2017 at 10:37 AM, David Mazieres <dm-list-tcpcrypt@scs.
stanford.edu> wrote:

> Hi, Eric.  Thanks for your review.  Let me go through the discuss
> points, but then below I have just a couple of questions about your
> feedback.  Most of your points I was able to address straight-forwardly.
>
>
> Eric Rescorla <ekr@rtfm.com> writes:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> >    o  TEPs MUST NOT permit the negotiation of any encryption algorithms
> >       with significantly less than 128-bit security.
> > IMPORTANT: I don't know what "significantly means". I wouldn't be
> > making a point of this, but it's phrased as a normative requirement,
> > so I don't know what conformance means.
>
> So to be clear, the goal here is to make a normative requirement that
> prohibits something like DES or 40-bit RC4 like in the bad old days.
> However, we also don't want to rule out something like AES-128 just
> because some highly theoretical biclique attack shaves two bits off the
> security for an attacker who happens to have 2^{80} storage (or whatever
> the state of the art in AES attacks is).
>
> The other problem is that "n-bit" security is kind of inherently
> ambiguous anyway, because with circuit complexity you'd probably have a
> fairly high constant factor multiple of your key space in gate count,
> while with time you can just design an instruction set that does two
> things at once hence shaves a factor of two off your runtime.
>
> My hope was that this kind of phrasing would basically allow anyone to
> object if a weak cipher like DES is being considered, while permitting
> things like AES-128 to go through unimpeded by unanimous consent.  The
> MUST is effort to hand as powerful a weapon as possible to anyone
> legitimately arguing against the selection of a bad cipher.
>
> That said, if it's simpler we could just pick some number like 112-bit
> security or something.  We've discussed this point before and I think
> ended up returning to the slightly informal wording being best, but
> happy to entertain other suggestions.
>

See David Black's email.


> > IMPORTANT: This actually seems to be a bit confusing about how to
> > handle URG. Consider TCP-use-TLS, you would just process URG in the
> > normal way and then generate errors if URG causes reordering at the
> > TLS layer. This seems like a reasonable procedure but is at least
> > arguably prohibited by this text.
> >
> >
> >    problems, TEPs MUST compute session IDs using only well-studied and
> >    conservative hash functions.  That way, even if other parts of a TEP
> >    are vulnerable, it is still intractable for an attacker to induce
> >
> > IMPORTANT: this also does not seem to be unambiguous.
>
> The current phrasing is an attempt to walk a fine line between the
> adamant demands of some working group members that TEPs fully support
> urgent data and the desire to support TCP-use-TLS.  Basically the SHOULD
> is intended to leave you enough leeway to argue that most applications
> are known not to use urgent data so TCP-use-TLS can be on by default.
> I've added a sentence to the experiments section to say one of the
> things we might learn is whether we can relax the urgent data
> requirements further.
>
> I tweaked the phrasing to make it clear there may be other approaches
> besides the to MAYs, so the current phrasing is:
>
>       * TEPs MUST prevent corrupted packets from causing urgent data
>         to be delivered when none has been sent.  There are several
>         ways to do so.  A TEP MAY cryptographically protect the URG
>         flag and urgent pointer alongside ordinary payload data.
>         Alternatively, a TEP MAY disable urgent data functionality by
>         clearing the URG flag on all received segments and returning
>         errors in response to sender-side urgent-data API calls.
>         Implementations SHOULD avoid negotiating TEPs that disable
>         urgent data by default.  The exception is when applications
>         and protocols are known never to send urgent data.
>

This still seems to suggest that these are exclusive. Perhaps a
"For instance" before "A TEP MAY"


>
> Does that work for you?
>
> >    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,.



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





> Adding the word "solely" actually makes it more confusing to me.
> Knowing my confusion, is there some other wording you would suggest?  Or
> maybe leave as-is?
>
> >       that disable urgent data by default.  The exception is when
> >       applications and protocols are known never to send urgent data.
> >
> >              (4) B -> A:  SYN-ACK  ENO<b=1,X,Y,Z>
> >              [rest of connection encrypted according to TEP Y]
> > Can you show a=0 in line 1?
>
> Do you want me to put a=0 in ever single SYN packet?  Since none of the
> examples use the application aware bit, putting it in some segments but
> not others might be confusing.  Can you say more specifically what the
> possible confusion is?


Why am I supposed to infer that it is 0 here when the other is 1.


  Maybe one sentence saying a=0 in all examples
> would help?


I would deal with this by a note here saying that you explicitly show a=0
here for clarify, but I could live with you having the sentence you suggest
both in the first example and then a reminder here.

-Ekr