[TLS] Commentary on the client authentication presentation slides

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 20 July 2015 14:10 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 232BB1A87BC for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 07:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 tiNcxep9Hh2I for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 07:10:39 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227481A87B9 for <tls@ietf.org>; Mon, 20 Jul 2015 07:10:39 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 44B7A9013E for <tls@ietf.org>; Mon, 20 Jul 2015 17:10:36 +0300 (EEST)
Date: Mon, 20 Jul 2015 17:10:36 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: tls@ietf.org
Message-ID: <20150720141036.GA32204@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/piExtb-IXCBo26c-1VRMy5auw1k>
Subject: [TLS] Commentary on the client authentication presentation slides
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: Mon, 20 Jul 2015 14:10:41 -0000

Some commentary on client authentication slides (there is no linked draft
nor other material yet).

- Mechanism like proposed looks dangerous when combined with HTTP/2.
  Multiplexed protocols are in general not safe to authenticate without
  application-layer signaling (which can be implicit via separate
  connections), especially if dealing with something like web
  environment.
- Regarding last point about interleaving: Assuming the scheme works
  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
  The best that can be done is to require the client to send all
  the authentication-related data in one go.
- The certificate_types field in CertificateRequest is pretty much
  useless, since all supported algorithms are of signature type.
- One can't just remove fields without breaking parse compatiblity,
  but adding field breaks parse compatiblity too, so removing
  field at the same time isn't a problem.
- How does extension_values work? If multiple values for one
  OID are allowed, then the OID/value pair is repeated, once for
  each value?



-Ilari