[TLS] Superficial review of draft-rescorla-tls-dtls13

Martin Thomson <martin.thomson@gmail.com> Thu, 03 November 2016 05:01 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3F12964E for <tls@ietfa.amsl.com>; Wed, 2 Nov 2016 22:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zlj2oWsaRVBh for <tls@ietfa.amsl.com>; Wed, 2 Nov 2016 22:01:01 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 2FCFD12940F for <tls@ietf.org>; Wed, 2 Nov 2016 22:01:01 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id p16so21794474qta.0 for <tls@ietf.org>; Wed, 02 Nov 2016 22:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=vS++/xWAweWYRmPj39WxE630XflURId/sJHmBIJiY5w=; b=eBkKol/vGWZrNX/DXOtAY33wclqL/st+ohaGG818UeqD4FsFNadenteMiyMp5jxyNL c9KsbLR3yLHmufFN6vEmvUD/YXfDXIywO8fI4Ck/xFTd9d9Z9Mc+QPnGr39vCqypp6CS 0gnYLKB1Uk0I1is+bWUABD6hl2WzklElzYlQtbwEASWBpLA6fp811iv0xSj1HIm91xya A7S+1oPxjO1VeTnnSM2gBv3FimouEPibmutrLe8ioZ9/3hgKNzAcg3Q5WD/vo5Mr0wav XNtaOEStbiq3hwmxjyegkNrLaFxRgAPG6RHzUY6jm/g4WNfHWVWP0X0IxA2TK7kNhmgs MVRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vS++/xWAweWYRmPj39WxE630XflURId/sJHmBIJiY5w=; b=AApawRDot5vGQC1oQQ41bQnZy6UHkf41elgzAvcGkKLYlySZnvw/xcvGR2JuM4l/H4 CE+Clao1sbI+R9PF7csNlEtXiTszO5ogRAchga6pWM7qIrOyaeRiqIRNrGzxbvwyNpDb tRuXg9O3xbAbRlrfIj1I8a5z+7Rd72b/jyDkZ7NaVIzA/UBu22ce4G0yvDnBt/ArRD8b gvSnH7YYAD9TTUdsA0OKJwGZxb51Z86oqhfSfPG4xdNik+vO7sjUhuY13UE3XhQ7vgtu MioJS2e/YdBl5pm/p5ZPwC1Hsg/XLzJT9cIFRU63TVFQ/LMBszyYk38+z+EEcHPdW+vQ 4tTQ==
X-Gm-Message-State: ABUngvcaz2hRsBvQHJFGZ6x7Eekd+0KZA6NF/3r4SaEktWY2KfNQI4KnLFIt16FSug12e7IWnSKWXsZB3LKo3g==
X-Received: by 10.237.62.27 with SMTP id l27mr6491339qtf.34.1478149260197; Wed, 02 Nov 2016 22:01:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 22:00:59 -0700 (PDT)
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 3 Nov 2016 16:00:59 +1100
Message-ID: <CABkgnnWhLbgimLN+HQWoe8unk-=ebEkVL3_-fpWBhLYruF+_AA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PhtnpKrRBRl5oCmKaRhpg0w6_1I>
Subject: [TLS] Superficial review of draft-rescorla-tls-dtls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 05:01:06 -0000

First of all, I think that this is pretty good work.  I've implemented
a version of DTLS 1.3 that you might assume based on the TLS 1.3
drafts and this is much better in several ways.

The explicit ACK is nice, but I REALLY like the epoch management
stuff, when I implemented it, it made things a lot easier all around.

The big open item here is that the record format is grossly wasteful.
Hannes and I have been discussing this offline and I have a sketch of
a plan that should maintain compatibility but it will shave off 9
octets per record.  We might be able to drop two more if we are
willing to send more packets during the handshake.  (Note that the
draft seems to not do the content-type encryption, we'd fix that at
the same time.)

Nits:

   As in TLS, implementations MUST either abandon an association or re-
   key using a KeyUpdate message prior to allowing the sequence number
   to wrap.

You also forbid use of KeyUpdate, which I think is the best answer.

I wouldn't mark key_update as reserved though, lest IANA take that as
an instruction somehow :)

(Don't fix this, but why is fragment_length a uint24?  You can't put
that much data into a single record!)

Figure 10 shows an arrow that spits off the middle of another line.
That arrow isn't labelled.  I can't see how to interpret that, nor
conceive of what might belong there.  Figure 10 should also switch
from "last flight" to "ACK" (in two places).

The change summary should reference TLS 1.3 for changes between TLS
1.2 and 1.3.  It should talk about changes that are relevant to DTLS:
the change of cookie handling, the change in record layout, the
addition of an explicit ACK, and the handling of key updates.