[TLS] PR#950: Unpredictable certificate_request_context values.

Eric Rescorla <ekr@rtfm.com> Sun, 16 April 2017 18:43 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 26892127775 for <tls@ietfa.amsl.com>; Sun, 16 Apr 2017 11:43:22 -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 7NcQjQnTc6ia for <tls@ietfa.amsl.com>; Sun, 16 Apr 2017 11:43:20 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 7C301124B0A for <tls@ietf.org>; Sun, 16 Apr 2017 11:43:20 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id l189so49407317ywb.0 for <tls@ietf.org>; Sun, 16 Apr 2017 11:43:20 -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=FpfzRQ7Ilr/wzIPjnMx4C7z5B5ORG0CZ8Hy4kZc99+M=; b=LgcB1Yu7yhMVv1IlJPe8Sts9+FUgWRYP+RgBWOBJV7tT0T2eHh9sDVfNW6/MlE0SB8 zlKwlpw83K6WTi/caoA7NLnNxhIhDu/zrsGo2Yzki8+kruj4rT8Kn7XhD9nQb+sHoDAS zEZnwNhh7FLQU9o3lYbW3oORw3LdcVHVRhCeaLO/DMMiA0G6kGPcUiTDx11ByvKMzjNI BfAQLSTXpwuH5ypXsTK02eeIzMWWc1fkJslZHfgEPRn1NLzrJleOkvsN4nOz4eNoBUI4 zQOvOH6Cos5ZW5QL9JqllVoE7QPFk6ldAz3bsRHvyHy/wPejBkxklhZmxjSQsYtLV7gj mh+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FpfzRQ7Ilr/wzIPjnMx4C7z5B5ORG0CZ8Hy4kZc99+M=; b=ZS3g8ghhT1ChDAUAjrhy+1xqHjaUk/3v7i7woREINKkCQPOSSby+pc98dVp8pb6L9c OsYT6KLQCEtvLHwFp81YuFkTlvYR7McKfLLAi3BWHFh5UuHilynS49w/eZbPR9RiuDNa ohIb5dVwdBErDkcY7kWkDzbA7bKTyp6N81YDRY3hwCkCuj4VNrDxceV62uxtV8julrmq khvd9q1jvpqI6qBqHKXJkzfQb1E0w29lgqLrPbdxGeotVLYpNrErvQh/3g7S4Jcyt7yK T/hAcU7/JyyMdgsZan0XGFAHcKsZfgyk8YYIZUzCWHjrrvkirhdkoGPzeZhA31JoXDjg g9dQ==
X-Gm-Message-State: AN3rC/7p76ZXfO0PcTXWX2hLLGfLAyDxvgg/3kbgCivGNWq7/ugDLA4y D9qkN+X6L9nj1VGz9AfjQp+M2K76JB6eSZs=
X-Received: by 10.129.51.131 with SMTP id z125mr14297668ywz.87.1492368199582; Sun, 16 Apr 2017 11:43:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.113.7 with HTTP; Sun, 16 Apr 2017 11:42:39 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 16 Apr 2017 11:42:39 -0700
Message-ID: <CABcZeBPnLZq7PHmpGOBAX4Lw=U6e2eyKZeCEy-MzOZeGs_3WjQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142165c691e99054d4d0c19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mH7M_svBax4UFndNnBRBXVrrD2I>
Subject: [TLS] PR#950: Unpredictable certificate_request_context values.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Apr 2017 18:43:22 -0000

https://github.com/tlswg/tls13-spec/pull/950
Target merge date: Tuesday

I have just posted PR#950, which recommends that servers generate
unpredictable
context values for CertificateRequest in post-handshake client
authentication. This
prevents attacks in which an attacker who has temporary access to the
client's
private key can forge valid CertificateVerify messages.

Note that this is not an enormously large improvement because an attacker
who
has temporary access the private key can do a bunch of other stuff, like
forging
a complete handshake message, but I can imagine some artificial scenarios
where it might be useful, for instance if the user's private key is an HSM
and
so the attacker has permanent control of the user's machine but can't get
him
to generate an arbitrary number of private key operations without detection.

Unless I have missed something, this seems like harmless advice, so I tend
to think we should add it. Comments welcome

-Ekr