[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