[TLS] PSK and client verify
Watson Ladd <watsonbladd@gmail.com> Fri, 19 February 2016 18:25 UTC
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A981B3340 for <tls@ietfa.amsl.com>; Fri, 19 Feb 2016 10:25:33 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 M-4UZTmt1iGY for <tls@ietfa.amsl.com>; Fri, 19 Feb 2016 10:25:31 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 EBC4F1B33E2 for <tls@ietf.org>; Fri, 19 Feb 2016 10:25:29 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id u200so74269665ywf.0 for <tls@ietf.org>; Fri, 19 Feb 2016 10:25:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gRutZzRN3QvqE4GmDQQ7Xh560GCQS04+Ovt2G/mvv3c=; b=RbZAFMLsK7CHQMMETDgvb7JtK3p1Z3bzd/XgjWXfTul2PLANRoRj4K+Dbf8Ri0DrZ/ p/ZJtDMPshi1BDTWNRzQO2hJr4bGuGek/uE79Yuqi0DJVnhyM9hdaVT9HJ1XHdthuzEJ 2eNhvJgwub3g9jGiojlB4bE9D6h4WMrajpgYZPr/xRiTNzZXLfabThYWE8+foMa/SNb5 c/Qf4QsupKqPU6ye4vqlldTWRyunV3GFciu/2CLNmwrpWKMXDL5C5qwu6nij1lYDeKhU uGzlbe4pclEd9qkahBTunp+Ccp0Q53Qn1jIx2YNE6xC1m/nlbKFe9ypZro9DcojkQN6H XE7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gRutZzRN3QvqE4GmDQQ7Xh560GCQS04+Ovt2G/mvv3c=; b=HR+pz1y5emE25SpiQOH7EK+ngT9DplGBorrVBo1nKtbLBxBbxyG0AXHp5MT53Dqgwn INBUJI5JAQpu2l0BrxzvOMNsI7XWNjcGbqPxo9IeuqX5+atpUY7aOYuvQdBZnrE+SO/j MyMNZzdRjZiVfHbaf2C5LVdGcACwBvJ9Lq12OdqqWI71iv+bVazlqIYAJP5rO1xVQ+y3 csyWjQii5SK4Q24PonRP5/iDvk5mnMFpM4Q6h1tv8NMvYCE0k3O/v7S5CJ++NigxrLk0 js7HaZA4HmpMHfjCCD35Aczu6Zz9xmR9kkywOgkJAtFwyH3EpeRuwB+zpVB1xA/bZ9fx I3BA==
X-Gm-Message-State: AG10YORoicsIq12zgWW95yVP6VKNdrDepma0RKsMw4w5jk3wjv0tkqvKUw7Kd5DLRytaHxyKryF9WfmzBQzJHQ==
MIME-Version: 1.0
X-Received: by 10.13.226.86 with SMTP id l83mr8932629ywe.239.1455906329328; Fri, 19 Feb 2016 10:25:29 -0800 (PST)
Received: by 10.13.216.138 with HTTP; Fri, 19 Feb 2016 10:25:29 -0800 (PST)
Date: Fri, 19 Feb 2016 10:25:29 -0800
Message-ID: <CACsn0ckdKvSQHpU8D5JDSdzXH-RzSiKJJ4pdoA+9S6+WL36iJQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/O7zivqZFPKBOmAJBXF-2Ztub6Wo>
Subject: [TLS] PSK and client verify
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 19 Feb 2016 18:25:33 -0000
Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message and we see that client certificate verification is allowed for some PSK exchanges and not others, and that the PSK exchanges used in resumption are ones where it is allowed. (Maybe I am reading that wrong) Right now this feels footgunny to me: you have to track where the PSK came from to decide if client auth is allowed. I'd like to see an explicit separation by indicating where the PSK came from in the ciphersuite, and then implementations reject authentication with one of them. This way someone who wants to do the wrong thing is at least forced through enough contortions they will notice, rather than seeing two features that seem to work together but don't. TRON is in 2 days, and I'm concerned that the degree of analysis of TLS 1.3 is far below where I would like to see with the timelines some people are pushing for. I think it's clear that TLS 1.3 implementations will never be as secure and as simple as QUIC or CurveCP. At the same time we've diverged from TLS 1.2 enough that implementations will be significantly complicated when supporting both, the reason given for not massively simplifying the protocol in the first place. Sincerely, Watson
- [TLS] PSK and client verify Watson Ladd
- Re: [TLS] PSK and client verify Eric Rescorla