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

Eric Rescorla <ekr@rtfm.com> Thu, 01 November 2018 21:10 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 BC905128A6E for <tcpinc@ietfa.amsl.com>; Thu, 1 Nov 2018 14:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 d0N-D7S9wgFO for <tcpinc@ietfa.amsl.com>; Thu, 1 Nov 2018 14:10:27 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 6653312D4EB for <tcpinc@ietf.org>; Thu, 1 Nov 2018 14:10:24 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id u6-v6so3014596ljd.1 for <tcpinc@ietf.org>; Thu, 01 Nov 2018 14:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KiNylRg9VpKdFd201uUVhw+lFqxDD/EcMpl3Sq1qgMQ=; b=ly+fxmxSNX0/gR62o0N2XGAoH5QAZ7CRhXDfNkEiS899U10WJ5qVeHf6ESsejHBvu2 olATI4Pt87o94jaMT8KycPSLAmPpFHoXPBJYXp1bpMR++UgJPhToim618nnxD+OyIbZ6 PT9ioZN3Ydjk6KeTOfA+9mICTNhYbqeG8dSxMcCDcWpQWTLuMLuYedZJzmScMPVRsso6 WwbIFI8AuGv08Cr+9q4usXWodjbZ6cQZN/Xhau+N17wjKE4xNHRHqPMsMOt5XfRY9eJW cnWa8N+tTSEuztXYj16iaPYD+py8u5QZgkUJ3f0sT7OO6tbVdEWjk+Goz+laUPzsMoaz iLzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KiNylRg9VpKdFd201uUVhw+lFqxDD/EcMpl3Sq1qgMQ=; b=Rwgtlk2y4T71bwfAXsmIZXN2vgwKK+5U0vor+HczY2LnIAjthokKR3L/s18o6QcFVV yFxGYQpnyQ/8TkHk0v+dn/VgvkEKkexrByfeR0JpdjgCehpUqZOSJfeFPq6IBPpwjptW xkNhzcSVLYeLXVin0uXlmFZ3AztloYmEWaeaoDZNYWSFkE7MbDEtqCpI0KpeJkCrQyYk OlBnKqfr2yeeDB6eStIgCysVD9gxkfPrHfL00qdeehIjzA5/fYPoHXy+GcViHpamSE6I 0bfDxuZEkMpLrDFWxbEGFb8P4pHj19VABc1keeuGgpGUPFKemc0l1Mvg0t7zyv1sB1++ I1yg==
X-Gm-Message-State: AGRZ1gJp/6sE+snX/PmbZ9sFdk3/N8jnhqu0JXPyCIdUdlH73yIyBHXj qiNpT+Iqgi3DoWibGVn4pDrPQ7+7l/5OjtMqFYZazw==
X-Google-Smtp-Source: AJdET5dVeSH1b0DiiD/36HFtGyJsz95QETiL7TaIxS5pVWj0SQNr0vkknMxbwxx6M5bFSVaHSLic4gkKnVd/TN3u3IM=
X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr6415741ljb.51.1541106622519; Thu, 01 Nov 2018 14:10:22 -0700 (PDT)
MIME-Version: 1.0
References: <20171124182842.GA80062@scs.stanford.edu> <CABcZeBORGhsgWem3P6GS=1qfkwBEZxX=CBGCOoU3R_+MsO4FrQ@mail.gmail.com> <CAJU8_nXA_1L_XVJAMGj+L4JY-so+LO79pxt_s=BTLWj_g47f_Q@mail.gmail.com> <CABcZeBNQEs6BKnxzQOuN4A4qvEDsk8kGQLt6S9Wy0OXsJ3u5cw@mail.gmail.com> <CAJU8_nWMn0_SSLUH+reS5La4J7t0uEN5u2zC8XFRXDMOffc1Qg@mail.gmail.com> <CABcZeBP2mN-Y3GFda3mqawFuFFqtzpwpsceseE5FNMH1iSpFPQ@mail.gmail.com> <CAJU8_nWk_Opuj+m4jv79qwFMUGqi5=JMk3S_3QfJLahOjL+77g@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD89888@MX307CL04.corp.emc.com> <20171128041124.GA42654@scs.stanford.edu> <CAJU8_nUx=k-nKLcrY0iVeSL7THCVARanZymWbTHaNbR+FKavPw@mail.gmail.com> <20171128223855.GE42654@scs.stanford.edu> <CAJU8_nUeTj2fwr4PAJ1T34uACHK=OnX1_OC3+UB9DomcvvcPMw@mail.gmail.com>
In-Reply-To: <CAJU8_nUeTj2fwr4PAJ1T34uACHK=OnX1_OC3+UB9DomcvvcPMw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 01 Nov 2018 14:09:45 -0700
Message-ID: <CABcZeBPe5_UhhmhiSBMGqYTfT7pyVhaeWXBOkw7CHRumghN57Q@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: Daniel B Giffin <dbg@scs.stanford.edu>, "Black, David" <David.Black@dell.com>, tcpinc <tcpinc@ietf.org>, tcpinc-chairs@ietf.org, IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org, mazieres-ddragqirgwht7ezx2d39a3jw72@temporary-address.scs.stanford.edu
Content-Type: multipart/alternative; boundary="000000000000cbe72e0579a0d8b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/RAsm7UdAiEeCP4tC8t9GleFyny8>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 01 Nov 2018 21:10:30 -0000

I have reviewed the latest version of this document.

This appears to address most of the points in my discuss. A few more
comments below.


   When a frame is received, tcpcrypt reconstructs the associated data
   and frame ID values (the former contains only data sent in the clear,
   and the latter is implicit in the TCP stream), computes the nonce "N"
   as above, and provides these and the ciphertext value to the AEAD
   decryption operation.  The output of this operation is either a
   plaintext value "P" or the special symbol FAIL.  In the latter case,
   the implementation SHOULD abort the connection and raise an error
   condition distinct from the end-of-file condition.  But if none of
   the TCP segment(s) containing the frame have been acknowledged and
   retransmission could potentially result in a valid frame, an
   implementation MAY instead drop these segments (and "renege" if they
   have been SACKed, according to [RFC2018] Section 8).

Looking through this again, why is this the right guidance? It seems
like:

1. You shouldn't ACK data that you can't verify, because it's confusing
to the other side. This seems like one of the arguments for tcpcrypt
rather than protocols that run over top of TCP.
2. You would get better resistance to connection failure if you instead
decrypted packets and then ACKed.

Is the situation that sometimes you have to ACK? I haven't thought
this through. Perhaps you should recommend against ACKing if you
don't have to.


I also notice you don't require checking that the result of the
X25519 function is nonzero. We hve been requiring this in other
IETF protocols.



   the number of past connections that are vulnerable.  Of course,
   placing private keys in persistent storage introduces severe risks
   that they will not be destroyed reliably and in a timely fashion, and
   SHOULD be avoided at all costs.

This seems a bit over the top. Either it's this serious and you need
a MUST, or it's not this serious, and you should tone it down.

   To meet that ideal, it might appear natural to also mandate ECDHE
   using P-256, as this scheme is well-studied, widely implemented, and
   sufficiently different from the Curve25519-based scheme that it is
   unlikely they will both suffer from a single (non-quantum)
   cryptanalytic advance.

I'm not sure how persuasive this argument is. Wouldn't an efficient
discrete log algorithm in generic groups affect both of these functions.
As far as I know, it's not known that no such algorithm exists.

-Ekr


On Tue, Nov 28, 2017 at 2:55 PM Kyle Rose <krose@krose.org> wrote:

> On Tue, Nov 28, 2017 at 5:38 PM, Daniel B Giffin <dbg@scs.stanford.edu>
> wrote:
> > Yes.  It makes sense that whenever you send a TEP identifier
> > (by itself or for resumption, even if you use some
> > yet-unspecified resumption-request format), you are willing
> > to do fresh key exchange with that TEP.  Thus I have added
> > this to section 3.5. Session Resumption:
> >
> >    If a passive opener receives an ENO suboption with a TEP identifier
> >    and "v = 1", but the suboption data does not have length 9 bytes, it
> >    MUST behave as if the same TEP had been sent with "v = 0".  That is,
> >    the suboption MUST be interpreted as an offer to negotiate fresh key
> >    exchange with that TEP.
>
> Right, I was just pointing out that we want to keep this change even
> if we decide not to make further changes to resumption at this time.
>
> >> Do we want an extra frame in/after the INIT
> >> messages for sending version-specific data on the first flight that
> >> old receiver versions will simply ignore (beyond including it in the
> >> handshake transcript), to avoid an extra RTT for version negotiation?
> >
> > Because the new "version" byte would be the first byte sent
> > in each direction, it can be used to negotiate any future
> > protocol behavior to follow that byte.
>
> You need both because you need to know that the INIT message you send
> will be accepted by the receiver before you know which version(s) it
> supports (i.e., on the first flight). That said, I had forgotten that
> the protocol already has this property, as you pointed out:
>
> > Even without the version byte, the Init1/Init2 messages
> > already reserve trailing space for future uses, which
> > implementations of the current protocol are instructed to
> > ignore (although it is always part of the transcript).
>
> If we decide to make use of that space in a future version, we'll need
> to come up with a structure with intrinsic backward compatibility for
> version fallback... but that's a conversation for another time. :-)
>
> Kyle
>