[websec] Service auto-configuration and certificate pinning

Marten Gajda <marten@dmfs.org> Wed, 22 June 2016 21:39 UTC

Return-Path: <marten@dmfs.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0588512DD38 for <websec@ietfa.amsl.com>; Wed, 22 Jun 2016 14:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org
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 ncUeCFCS8wqH for <websec@ietfa.amsl.com>; Wed, 22 Jun 2016 14:39:28 -0700 (PDT)
Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B6E12D991 for <websec@ietf.org>; Wed, 22 Jun 2016 14:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding; bh=QDku8qyU6QCHf1+Amimch4CQdEGTN1HPas4xOomtoxA=; b=YtnxqDnLhcwkCXGy+pu3UAJ/hjhjO7PKopcrrdunfQYvQ8HCwRCRAmeywZOo809sd+B93OQY++zbZ zXgUYo6MVGD839UKexL7Eo7EUlxDeqUD/ncckkUFuLQypqhTc27j1PC67DUw6HPErOd6CkEtTAQBam ZToI14vCpTIq7KRQ=
X-HalOne-Cookie: 5ca078c0160d77276743912f44628a3bc43f3df4
X-HalOne-ID: 9d8e55cf-38c1-11e6-9f37-b82a72d06996
Received: from smtp.dmfs.org (unknown [217.234.107.6]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA for <websec@ietf.org>; Wed, 22 Jun 2016 21:38:10 +0000 (UTC)
Received: from localhost.localdomain (p5DDABB85.dip0.t-ipconnect.de [93.218.187.133]) by smtp.dmfs.org (Postfix) with ESMTPSA id 987B52F5 for <websec@ietf.org>; Wed, 22 Jun 2016 23:32:36 +0200 (CEST)
Message-ID: <576B0541.7040708@dmfs.org>
Date: Wed, 22 Jun 2016 23:38:09 +0200
From: Marten Gajda <marten@dmfs.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: websec@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/lVB0L1p7wr5grZIPOqKvyEftEZg>
Subject: [websec] Service auto-configuration and certificate pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 21:39:31 -0000

Hi list,

I'm currently working on an update of a draft that specifies a way for
clients to configure themselves with a minimum of user-provided
information. The current draft is available at
https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03
(it's a bit outdated, but we're working on it).
This draft specifies a member to contain a server certificate, which
presumably was meant to support some sort of certificate pinning.

During my research on how to improve this I came across RFC 7469 and
https://tools.ietf.org/html/draft-hallambaker-webseccaa-00

I'd like to ask the members of this list whether they think that
"bootstrapping" certificate pinning for individual services (like so:
https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982)
would be useful to have in a service configuration document or if they
have any concerns or other comments about this.

I'd also like to hear about opinions if this could be an acceptable
solution for certificate pinning with non-HTTP based protocols, i.e. for
protocols that don't have an in-band pinning mechanism the client would
reload the service configuration document whenever the cached pinning
information is outdated (i.e. <max-age> seconds have passed since it was
downloaded).

Any comments (whether in response to this post or at GitHub) are very
welcome.

Regards,

Marten Gajda

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743