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

Kyle Rose <krose@krose.org> Wed, 15 November 2017 01:47 UTC

Return-Path: <krose@krose.org>
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 BD9B812947F for <tcpinc@ietfa.amsl.com>; Tue, 14 Nov 2017 17:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 Vt2w8qvDiUTL for <tcpinc@ietfa.amsl.com>; Tue, 14 Nov 2017 17:47:14 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 3C3A0129482 for <tcpinc@ietf.org>; Tue, 14 Nov 2017 17:47:13 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id f8so31019317qta.5 for <tcpinc@ietf.org>; Tue, 14 Nov 2017 17:47:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6gpmnPTzg2+mLMqnMg4WA50IswJx6T/wJfCGCcnylfA=; b=Y4pdzZPoqPlj8UVIlH0xhF/RSdek7ImZRkizMFbwuVDUdcV8xa7gPJaly7TQLZYYRc nuawjrwuvhyMaC1iDrrsm/l2FW+3+g1WJ4A6P1DZaugQ+PeQUcsEfI1h/oUy+XSRItFL EC6PEPtl4NGbnW0tidq0tQ2kQPx+P8MdC4Roo=
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=6gpmnPTzg2+mLMqnMg4WA50IswJx6T/wJfCGCcnylfA=; b=sIsaFuvd4p3bRhGYRfMQx49ilINRfQeJeBfQ/dBO9tzLpE5rNjIHPXoRLYyeG2sYcH 1X0Fxn9qvRiTmUPblgulkqdoRxPniYD0Eh4znivPvB0xTKuAQMuvX/j3VIGJ/JJnu/sx 7pGnsv9xHTxXizrk/WTxuj/nBTlePnT2eyuhrtqZGTcUdZ9fV8qoAKlKscxxTQE6TFkC EYENsxqCbJ76m0Myam05AA7VGTN8IN8HeYpptGXZL3bvl0pyzskDXoIz6V3EXY1sPrN4 vTeNOWz1z8OqMYpfv6+Wx5l+JNRYngtNi0TekKIqWppCHlkW+0CbNbxVEye9hRjCKpO6 ADAg==
X-Gm-Message-State: AJaThX4LjNXrLOyLvKLQuf1z5OvbjEfC64g+n1vpSVJ9+/RLfzGP6n3G 0b0fWCvJafGlvaUVU4o+O22KGZhyboZZDw8z4s8sqBs5
X-Google-Smtp-Source: AGs4zMahPJyshWPUDLsXztPgAMaZ/AVqcYYaNGgn3no5pb3YgwqRhdwMGDXpqxYLiEZgKWU8qFNk09yJyMk7bc6PTj4=
X-Received: by 10.200.35.55 with SMTP id a52mr22735956qta.148.1510710432109; Tue, 14 Nov 2017 17:47:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.204.17 with HTTP; Tue, 14 Nov 2017 17:47:11 -0800 (PST)
X-Originating-IP: [2001:67c:370:128:9071:bb4e:1555:ddaa]
In-Reply-To: <CABcZeBM1UpWCtbv82ZJngSz-k=ZiQfqELAv+BgZ=A8=8r_0AXA@mail.gmail.com>
References: <151036992713.398.18032326140786383584.idtracker@ietfa.amsl.com> <CAJU8_nXKpEgvWEZtEPw=wyDmrVteOJaDvmXsDwbUdueMUcaRhA@mail.gmail.com> <CABcZeBPaLwD++SPPNwx3Qd9ydOM46h1PwVyiOcw=S-Hif=CO5w@mail.gmail.com> <CAJU8_nVfXum1JnU6KYEsTBJiQmXaah5iYfTCmdrerWPNKcdYKw@mail.gmail.com> <CABcZeBM1UpWCtbv82ZJngSz-k=ZiQfqELAv+BgZ=A8=8r_0AXA@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 15 Nov 2017 09:47:11 +0800
Message-ID: <CAJU8_nWnG8WuOsGP-UZ5bUtfWohTUaoKm6kjbFdvfVxuUsyLfA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, dbg@scs.stanford.edu
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org, tcpinc-chairs@ietf.org, tcpinc <tcpinc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/WZ5YWU2OQo7D4gsuYNCMH4-r-1U>
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.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: Wed, 15 Nov 2017 01:47:17 -0000

On Mon, Nov 13, 2017 at 3:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> Interesting. I don't have a strong opinion about this one, but if
>> there are no (or cheap) tradeoffs, it seems reasonable to use this
>> construction.
>
> The countermeasure that TLS uses seems pretty cheap.

SGTM. Daniel can chime in here in case he strongly disagrees.

> Now that you've reminded me of this, it's worth noting that the following
> text
> probably could use some expansion:
>
>    When a frame is received, tcpcrypt reconstructs the associated data
>    and frame nonce values (the former contains only data sent in the
>    clear, and the latter is implicit in the TCP stream), and provides
>    these and the ciphertext value to the 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 MUST
>    either drop the TCP segment(s) containing the frame or abort the
>    connection; but if it aborts, the implementation MUST raise an error
>    condition distinct from the end-of-file condition.
>
> Presumably the theory here is that there is some sort of benign damage
> to the packets that nevertheless passed the TCP checksum, and the retransmit
> might succeed. However, in order for this to work properly, you have to
> withhold
> ACKs for those segments until you have verified them (or if you are using
> SACK, renege on the segments once they become in-order and you determine
> they are bogus). Otherwise, the sender will not retransmit, and you'll never
> be
> able to recover. This probably needs to be covered in this spec.

Good call. This is a good illustration that tcpcrypt actually operates
at the transport layer, or that there is an intrinsic/unavoidable
layer violation, if the intent of an implementation is to discard a
bad packet rather than abort the connection.

>> I like the idea of added defense-in-depth against faulty
>> implementations, but it's not clear to me what tradeoffs this involves
>> re: (e.g.) SYN data on resumption, or on number of round trips, or on
>> the latency-to-first-payload-byte. I'd like Daniel to chime in here.
>
> I suspect that latency is in fact the issue here, but there's probably
> *some* way around this. Half-baked probably broken idea: what if each side
> sent
> a nonce before it started encrypting and mixed that into its *sending*
> keys. Then at least you would have diversity for the keys, though no
> anti-replay.

I like that this involves no tradeoffs other than some bytes for the
nonce. I don't think I'd want any changes at this point that
complicate the protocol or add round trips or latency, especially
since SYN data is not currently an issue for any TEP.

Do you think we need any additional language in security considerations?

Kyle