[TLS] PR 508: Move downgrade sentinel to end

Eric Rescorla <ekr@rtfm.com> Sun, 03 July 2016 23:02 UTC

Return-Path: <ekr@rtfm.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 7D1D612B04A for <tls@ietfa.amsl.com>; Sun, 3 Jul 2016 16:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 efzePH-6GXB3 for <tls@ietfa.amsl.com>; Sun, 3 Jul 2016 16:02:45 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 8B52C12B025 for <tls@ietf.org>; Sun, 3 Jul 2016 16:02:45 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id v77so28069506ywg.0 for <tls@ietf.org>; Sun, 03 Jul 2016 16:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GirZi/2IVgBxG4vezChAWEOhxTxOynQS7tDh1HgWE3A=; b=ipY1mvRq91PHZMf+05RvVYDGivm55OMAEpyAJo8ZbZcb9H0E+tvDj5ndcjCNixrsEp 5F8A9YDLBp0Qroloe1EFyz9SFantkpQ8p6xMZZQz+2aXYJwgUy23dS1NBOYtYF3R3R2y MBACXX2zexzWisoL/SYvP2Pt2S4RF+zXBEiWilLMVHLq2FZowv/mrqtlR0n2AZbgB5Wc EVA6ZYSslknEeGUUICHbkfSmQoyFUX3h7bC6agxpj7Gyiczk6XDHPYuEUvhZfbOI1di/ xYHwIetphtbcq/2IclQJGINApY1nJTJD8H9rSppBkJFqsKnwdti9pqkkT7E2doCdUcsY KS6A==
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=GirZi/2IVgBxG4vezChAWEOhxTxOynQS7tDh1HgWE3A=; b=hqsRZlr3l6fISh90fi8Dnzh+Vx5sUgdUezmS27GMu9qeXV/CQjtJUHo2bdsepj5vLK XLwlADQN+jT7fz5FDoPI7jTgK5bQlQWj311R+R3ih7NNR/cvZd8tDrPLO176MVAZIWXU MNQCExAxNGRmO0kQpDGiZ/dCLthahbhwlNQHHD2LbdboCK8N0p+GNAsiglOcxO8+k9EN WnxEakv5Cxd8lb/adlJvc3a49/rjPhSanXn/R3zodlW26qP1Ywe+imrY0Nugi7GFFFHJ fo+tf6L/61a59iwyYk3X1PJ6SV/LSjcWn2omvUD5y+L8kM7RfUL60rAGmP7ZlYXkrKhr WmXg==
X-Gm-Message-State: ALyK8tL59viGO2yVc/hukyeCNf1j348Fk66sozyZ7JfPAC1+7ChWRsCICRik8msDgTOgSpBMzuSGRuyp9ZnmLg==
X-Received: by 10.129.83.3 with SMTP id h3mr5102147ywb.276.1467586964704; Sun, 03 Jul 2016 16:02:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.132.211 with HTTP; Sun, 3 Jul 2016 16:02:05 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 03 Jul 2016 16:02:05 -0700
Message-ID: <CABcZeBOzh8Pc1+z6U5kajhibg08rnWrCygjGJe4TnBL377JEoQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d7484b580f50536c337c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Iy_ELtR_Tz0983OhvVMOqZZDpkU>
Subject: [TLS] PR 508: Move downgrade sentinel to end
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: Sun, 03 Jul 2016 23:02:47 -0000

https://github.com/tlswg/tls13-spec/pull/508

David Benjamin has suggested moving the downgrade sentinel to the end of
the server random to avoid breaking tlsdate. This seems reasonable, as the
only real argument against is that conformant TLS 1.3 servers will have
only 20 bytes of entropy when doing TLS 1.2 compat (if they put the time in
the top 32 bytes), as opposed to 24 if they randomize the first 32 bytes.
OTOH, those bytes will be more unique over time (because they are
guaranteed not to repeat for a very long time after the second has passed),
so intuitively this seems like a wash.

Barring any objections I'll merge this PR on Wednesday

-Ekr