Re: [TLS] Last Call: <draft-ietf-tls-tls13-vectors-06.txt> (Example Handshake Traces for TLS 1.3) to Informational RFC

Martin Thomson <martin.thomson@gmail.com> Mon, 30 July 2018 01:02 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 262CA130EE1 for <tls@ietfa.amsl.com>; Sun, 29 Jul 2018 18:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_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 (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 XSEv4qXNQpek for <tls@ietfa.amsl.com>; Sun, 29 Jul 2018 18:02:18 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 8822F130DEA for <tls@ietf.org>; Sun, 29 Jul 2018 18:02:18 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id s198-v6so18282218oih.11 for <tls@ietf.org>; Sun, 29 Jul 2018 18:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SV3KwA77ED7+ttQKcJE33JbitDJyv81BGS2o2+QnMyc=; b=H6vBdq7++rHmMb785CHSRBTfla/asCXS/8jy7i0wvTm5Ye1kDdLxt4ljVuo9A6QWlU ejsOhdcXrm2hN+vTMG9H1kpLGRxafEIFQ7QW3busdekTaZdXvcUHv3Pkh19pS+nOktpJ g/uC1FMgJxt9Lig5ZgMmweYY16Rj5ebMHOgTUGXSiAieIXBxPfcSZNdK2h0v6DYF+UsD aDRcGOpYVqsn9DMzEnUjqQLYTuCLSZDFFZ8y9HDCnih5sP0jfl5HpoYqy7Pc1TKEmCnl oX0REePJ2NYR7VSTvUr2uq0suBqpfPurXyj1nWFWtdrKkST7mT4mIzDj7O/51viKRSuI eAbw==
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:content-transfer-encoding; bh=SV3KwA77ED7+ttQKcJE33JbitDJyv81BGS2o2+QnMyc=; b=FlZvmSh2nbuJ6YiCHjhok6h9HwsQqz4U05UatdTw6ow/c3NieVePEGPLrMgspM8SGh 29UBLTETJO/XJd6Gf6v3lz4MqEc0y7Bc5bfCYwSvZr2SRGNCB86roq+q765wthu46gn6 VxqMHbSj3xiA4CUgNxnNUKMMpOYhijdpwyreqj15+d8FZStFeprp4DiwqEMY6eTkfI3X jxF1RzIaQCqWgC8dJDiAWGNdkWSxADkpyD3O3klYco/RgnoxEE4sEnxpUumfafm16gtH cuQkMf20epTFk3y6nUokGb2a2t/gFKfpFvpJ13J2QfY5PVCi+SnQ/e6xgWc3rX01Z7vJ fInw==
X-Gm-Message-State: AOUpUlGGo1c9FNczelO/P89sIBoYbfZ0RfyIWNuMHqYqsryM8aqbYAMG IMsxP0iujpisFbCpeP6JKmRRoPg30F2seHebx6il5UYK
X-Google-Smtp-Source: AAOMgpfJqaRllMctHiqddqNTHhDHeZqHjSiNIE85gipkrdjG6zkF65xeRwAacMpdZUMmfqw13HE/ibjYVVqRYqxtPpA=
X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr14588812oib.254.1532912537672; Sun, 29 Jul 2018 18:02:17 -0700 (PDT)
MIME-Version: 1.0
References: <LOXP123MB1176437868ECB2E1FAB41C60D32A0@LOXP123MB1176.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LOXP123MB1176437868ECB2E1FAB41C60D32A0@LOXP123MB1176.GBRP123.PROD.OUTLOOK.COM>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 30 Jul 2018 11:02:05 +1000
Message-ID: <CABkgnnV02PwHPTMBnJ=XA1vTY5TnA-T+6P+YuLqsnLZsvQRMhw@mail.gmail.com>
To: Mark.O=40ncsc.gov.uk@dmarc.ietf.org
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IkGC8yGlSSXDcv9j0IpWE5zbTSM>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-vectors-06.txt> (Example Handshake Traces for TLS 1.3) to Informational RFC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 30 Jul 2018 01:02:21 -0000

Thanks Mark,

I hadn't recorded the messages individually because it was a little
tricky, but by doing so both of your concerns should be addressed (at
a modest cost of 7 extra pages of hex).

For example, this now shows:

   {server}  send a ServerHello handshake message

      ServerHello (90 octets):  02 00 00 56 03 03 77 bd a6 37 17 c6 c7
         06 9e ae bc df d0 49 d9 c9 07 ca 6c d4 7e 87 8f 4e 0c 26 86 07
         37 1d 71 4f 00 13 01 00 00 2e 00 33 00 24 00 1d 00 20 37 b6 e5
         9f 38 84 d0 51 93 52 d9 48 cb 26 20 d3 c9 2f 61 5e 8e e4 17 eb
         d0 f1 69 e4 6e fe 0b 72 00 2b 00 02 03 04

   {server}  derive secret for handshake "tls13 derived":

I haven't pushed a new revision because it is currently under review
by the IESG, but will do so at the next opportunity.  You can see a
preview here (noting that this uses the draft version identifier of
0x7f1c rather than the final 0x0304):
https://tlswg.github.io/draft-ietf-tls-tls13-vectors/draft-ietf-tls-tls13-vectors.html
On Sat, Jul 28, 2018 at 2:58 AM Mark O
<Mark.O=40ncsc.gov.uk@dmarc.ietf.org> wrote:
>
>
>
> A couple of comments on draft-ietf-tls-tls13-vectors-06:
>
> Ordering of messages:
>
> Whenever the steps ‘{server}  derive secret "tls13 c hs traffic":’ and ‘{server}  derive secret "tls13 s hs traffic":’ appear, this is corresponding to the steps in the second phase of the key schedule (section 7.1 of tls13-28)
> To complete these you need to have the encoded ServerHello message (as seen in ‘Derive-Secret(., "c hs traffic", ClientHello...ServerHello)’).
> The description of the ServerHello message doesn’t come until several steps later. Someone using the test vectors to create unit tests would need to look ahead to the ServerHello payload (after ‘{server}  send handshake record:’, starting with ‘payload (90 octets):  02 00 00’) before they can recreate the steps above.
>
> Coalescence of records:
> There are several examples where multiple messages are shown concatenated, both in their payload and ciphertext forms, which makes it much harder to test them. Concatenating them (or not) has no effect on the protocol, so it’s not a requirement. It would be helpful to split out the messages so that it’s clearer which bytes belong to which message. The first example of this is after "{server}  send a EncryptedExtensions handshake message", "{server}  send a Certificate handshake message", "{server}  send a CertificateVerify handshake message", and "{server}  send a Finished handshake message"; starting with "payload (657 octets):  08 00 00".
>
> Mark
>
>
>
> This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls