From stefan@aaa-sec.com Wed Aug 1 10:56:08 2012 Return-Path: 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 4D85211E82F8 for ; Wed, 1 Aug 2012 10:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm9u8iZ1JtD3 for ; Wed, 1 Aug 2012 10:56:07 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C911E82CA for ; Wed, 1 Aug 2012 10:56:07 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 0D2271FA68BD for ; Wed, 1 Aug 2012 19:56:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bV6ASQSL95t7 for ; Wed, 1 Aug 2012 19:56:05 +0200 (CEST) Received: from s331.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id C4A5F1CCE2ED for ; Wed, 1 Aug 2012 19:56:05 +0200 (CEST) Received: (qmail 45183 invoked from network); 1 Aug 2012 17:56:05 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.216]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Aug 2012 17:56:05 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 01 Aug 2012 10:56:01 -0700 From: Stefan Santesson To: Message-ID: Thread-Topic: Proposed cached info update In-Reply-To: <50188A16.2040604@DigiCert.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [TLS] Proposed cached info update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:56:08 -0000 I went through the cached info draft and found something in the protocol syntax that I don't believe is totally correctly expressed. I made a diff that shows my proposed update: http://tinyurl.com/cachedinfodiff The issue at hand is that we use an existing structure to send the cached info. The data being replaced is in both cases sent as a vector (single dimension array) of opaque blobs. The data being sent instead is a vector of structured cached info elements. This makes the sending of cached info syntax compatible with the original syntax as the structured cached info element is compatible with an opaque blob element. The current draft and the proposed change is bits on the wire compatible, it just assigns the vector containing cached info a more sensible name "cached_objects<1..2^24-1> instead of using the name of the old opaque vector being replaced (i.e. ASN.1Cert<1..2^24-1> and DistinguishedName<1..2^16-1>). I would like those being more experts in the TSL presentation language to double check me so I don't make a stupid error here. Thanks /Stefan From stpeter@stpeter.im Wed Aug 1 14:26:31 2012 Return-Path: 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 B6C8421F8A1C for ; Wed, 1 Aug 2012 14:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.785 X-Spam-Level: X-Spam-Status: No, score=-102.785 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLE+eT0Wijpp for ; Wed, 1 Aug 2012 14:26:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AB86B21F8A1B for ; Wed, 1 Aug 2012 14:26:30 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3E52B40075; Wed, 1 Aug 2012 15:46:18 -0600 (MDT) Message-ID: <50199F07.4020604@stpeter.im> Date: Wed, 01 Aug 2012 15:26:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Scott Rea References: <50188A16.2040604@DigiCert.com> In-Reply-To: <50188A16.2040604@DigiCert.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] RFC 6125 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:26:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/12 7:44 PM, Scott Rea wrote: > We'd like to address a few concerns with RFC 6125. Because the > relevant discussion list is not active, we contacted the authors > and TLS Chair who instructed us to post our concerns to this list. > > Our primary concern with RFC 6125 is that Wildcard certificate use > is wide-spread and has proved to be a cost-effective alternative > to multi-domain certificates. Asking for the deprecation of > wildcard certificates undermines a lot of existing infrastructure > and current establishments. RFC 6125 does not deprecate use of the wildcard character '*' in PKIX certificates. Although Jeff and I would have liked to deprecate such use, we did not go that far, based on the feedback we received while working on the document that became RFC 6125. See Section 4.1: 7. Unless a specification that reuses this one allows continued support for the wildcard character '*', the DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the description of labels and domain names in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or fo*.example.com). A more detailed discussion of so-called "wildcard certificates" is provided under Section 7.2. See also Section 6.4.3. > We feel that RFC's current recommendations fail to adequately > balance the risks and convenience of an existing practice, is based > only on theoretical problems, and does not accurately reflect > current industry practices or beliefs. Those are worthy topics of discussion. Unfortunately, I don't have the cycles for such a discussion this week. I might have the cycles next week. > We suggest the following changes to RFC 6125: Just so you know, Jeff and I do not have active plans to work on a document superseding RFC 6125, for several reasons: it was a *lot* of work the first time, we both have other tasks we need to complete, we think it needs to be used for a while and cited by other specs [1] before we can determine what changes need to be made, it probably needs to be adjusted in the light of output from the DANE WG, etc. Peter [1] http://www.arkko.com/tools/allstats/citations-rfc6125.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAZnwcACgkQNL8k5A2w/vxS3ACeJiU7zrjDeeBNJFDuOQTtvjlC 7goAnjnME4M4Q5CGICV307IgPZvhXeDq =exTG -----END PGP SIGNATURE----- From mrex@sap.com Wed Aug 1 15:26:36 2012 Return-Path: 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 0137B11E82FF for ; Wed, 1 Aug 2012 15:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lo9PM1FA1GB for ; Wed, 1 Aug 2012 15:26:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2611E8235 for ; Wed, 1 Aug 2012 15:26:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q71MQUBd027036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 00:26:31 +0200 (MEST) In-Reply-To: <50188A16.2040604@DigiCert.com> To: Scott Rea Date: Thu, 2 Aug 2012 00:26:30 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120801222630.ABD291A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] RFC 6125 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:26:36 -0000 Scott Rea wrote: > We'd like to address a few concerns with RFC 6125. Because the relevant > discussion list is not active, we contacted the authors and TLS Chair who > instructed us to post our concerns to this list. > > Our primary concern with RFC 6125 is that Wildcard certificate use is > wide-spread and has proved to be a cost-effective alternative to > multi-domain certificates. Asking for the deprecation of wildcard > certificates undermines a lot of existing infrastructure and current > establishments. We feel that RFC's current recommendations fail to > adequately balance the risks and convenience of an existing practice, is > based only on theoretical problems, and does not accurately reflect current > industry practices or beliefs. I assure you that the issue of wildcard certs, their usage has been discussed in quite detail on the cert id mailing _before_ the document now known as rfc6125 was last called and published. (Finding the mailing list archives seems non-trivial, since the discussion list itself seems to be no longer listed under "non-WG discussion lists" on www.ietf.org) http://www.ietf.org/mail-archive/web/certid/current/maillist.html (I realize I should have modified/changed the message subject more often...) A few selected (non-representative!) postings from the discussion on the certid non-WG IETF mailing list that mention wildcard matching: http://www.ietf.org/mail-archive/web/certid/current/msg00345.html http://www.ietf.org/mail-archive/web/certid/current/msg00485.html http://www.ietf.org/mail-archive/web/certid/current/msg00461.html http://www.ietf.org/mail-archive/web/certid/current/msg00471.html http://www.ietf.org/mail-archive/web/certid/current/msg00472.html http://www.ietf.org/mail-archive/web/certid/current/msg00482.html > > We suggest the following changes to RFC 6125: IETF RFCs, once published, are immutable. As Peter mentioned, the process to change a standard or BCP would be to update or obsolete it with a successor document. But that is a significant amount of work. Considering that the issue of wildcards has been discussed in significant length during the developemnt of rfc6125, I personally see little motivation for a successor effort at the moment... -Martin From ekr@rtfm.com Thu Aug 2 11:34:04 2012 Return-Path: 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 800B611E8229 for ; Thu, 2 Aug 2012 11:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srQs94dBZroo for ; Thu, 2 Aug 2012 11:34:04 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFAE11E822A for ; Thu, 2 Aug 2012 11:34:04 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9793731ggn.31 for ; Thu, 02 Aug 2012 11:34:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=ubc5BUYF61lqPYy967ildRFS2LI/d7ZUmE7iS6/6sN0=; b=E8Dzb7S2kvN1psEF4HP4vlAqMQIs1Uz1b34zJbPvHaYEN3hMszplMnT+o/lEiI1iUn huihk4onFY7NsnOL2kGU98xj8DtoNiP1oa73SNqqicuhoB9V2JSO172fhZxthfYDd16t B1OgIFlq9Unr052NSPFlqCCHxUklhIgXDzI7Y1ZQSd3dZFD9P5WeI2VcCCDvX4m2GxNQ anuv55EGznDxMLEYlRlKk5Dj9VN0WPEkeytmFnSJYAHwnsufsafqmt9LuOpwoxweQhJ6 u4s+ZkewTIKqXFuAZtov74TY3Y7X83k7/pg/vvxUDpW0eeAs2MDSe/V8yhX8oPp0a8jp SCaA== Received: by 10.50.149.225 with SMTP id ud1mr5193334igb.74.1343932442968; Thu, 02 Aug 2012 11:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.71.37 with HTTP; Thu, 2 Aug 2012 11:33:22 -0700 (PDT) X-Originating-IP: [130.129.85.212] From: Eric Rescorla Date: Thu, 2 Aug 2012 11:33:22 -0700 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm/bYy4/eGbD22Ylvk/toboIKDz5KQwQiwusxdbs3xWOv+h21I1yMGjDP5Y32kwbjNJp0Ys Cc: tls@ietf.org Subject: [TLS] TLS WG Report X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:34:04 -0000 The TLS WG met at 10:30 AM on Tuesday: - TLS-OOB is effectively done. There was discussion of the relationship to RFC 6091, which is Informational, but depended upon. Consensus is to cut-and-paste the relevant portions. Authors to prepare a new draft and WGLC. http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 - The CachedInfo draft is ready for WGLC with some minor changes. The authors will prepare a new draft. http://tools.ietf.org/html/draft-ietf-tls-cached-info-12 - The OCSP Multistapling draft needs some more review but is believed nearly done. The chairs called for more reviewers of this. http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01 - There was a discussion of rollback protection mechanisms (to compensate for broken servers). The WG agreed to proceed in this line and to discuss specific mechanisms on-list. - There was consensus for the WG to accept the TLS-PWD mechanism. We will confirm on the list. http://tools.ietf.org/id/draft-harkins-tls-pwd-02.txt - There was extensive discussion on explicit TLS proxy support (for proxies which encrypt and decrypt, not RFC 2817 proxies) but generally the WG seemed not to want to take this work on. http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 -Ekr From hannes.tschofenig@gmx.net Thu Aug 2 14:54:18 2012 Return-Path: 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 14AD211E814B for ; Thu, 2 Aug 2012 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdH3Dg0+PsZo for ; Thu, 2 Aug 2012 14:54:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id ED5E211E8144 for ; Thu, 2 Aug 2012 14:54:16 -0700 (PDT) Received: (qmail invoked by alias); 02 Aug 2012 21:54:15 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp033) with SMTP; 02 Aug 2012 23:54:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ozZ8S0vPoNZVezRAOnTNS5BpWu9LzfhNUVzc4ov FPJVGwZqW2KrDh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 2 Aug 2012 14:54:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] Proposed cached info update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:54:18 -0000 I agree that this change is useful. On Aug 1, 2012, at 10:56 AM, Stefan Santesson wrote: > I went through the cached info draft and found something in the protocol > syntax that I don't believe is totally correctly expressed. > > I made a diff that shows my proposed update: > http://tinyurl.com/cachedinfodiff > > > The issue at hand is that we use an existing structure to send the cached > info. > > The data being replaced is in both cases sent as a vector (single > dimension array) of opaque blobs. > The data being sent instead is a vector of structured cached info elements. > > This makes the sending of cached info syntax compatible with the original > syntax as the structured cached info element is compatible with an opaque > blob element. > > The current draft and the proposed change is bits on the wire compatible, > it just assigns the vector containing cached info a more sensible name > "cached_objects<1..2^24-1> instead of using the name of the old opaque > vector being replaced (i.e. ASN.1Cert<1..2^24-1> and > DistinguishedName<1..2^16-1>). > > I would like those being more experts in the TSL presentation language to > double check me so I don't make a stupid error here. > > Thanks > > /Stefan > > From n.mavrogiannopoulos@gmail.com Fri Aug 10 05:17:07 2012 Return-Path: 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 7B88021F857D for ; Fri, 10 Aug 2012 05:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlwpLLEor3hk for ; Fri, 10 Aug 2012 05:17:06 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9155621F8618 for ; Fri, 10 Aug 2012 05:17:06 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1615041ghb.31 for ; Fri, 10 Aug 2012 05:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=sdEQ0qmq3eUIWQH7jeLKUObZsrJHhXiBAElcfaqZH/w=; b=bP27yrU3EsxKWR8T6ZfyLSLn8Us64/tG3oT9dO65a2H+RypBu/lPLsUeQlKe1risz9 fWpuZT+n8qKYSBlGb4P04HiPYjUv9iZgZzpRnNNNi+FrtlU+Xo0dqexn894ihSCU4Nc5 jJFVFn2AHAFgy754QEZRLqMtSnx0YVOy3H3TX0vCCgpyMP6ZrB8oci/3FakVtMH+6PNZ 41Cvz2uEBi9zDkqDGj7LBMWJ6ZwBcPRVeffY9kUhu/JKKGYOZz7yRh0bnPxNaft2fbHP yP77l9S6/jOWiqXWnDBPsgeQFBiUTua7Ye6mNAC/aH78qG4WH7xjlO9YeFtPOIgDCNrF /yvw== MIME-Version: 1.0 Received: by 10.50.5.196 with SMTP id u4mr1510562igu.41.1344601025746; Fri, 10 Aug 2012 05:17:05 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.231.206.135 with HTTP; Fri, 10 Aug 2012 05:17:05 -0700 (PDT) Date: Fri, 10 Aug 2012 14:17:05 +0200 X-Google-Sender-Auth: fjrgKZ0AdpRwAxVeTrp5Fw1S5g0 Message-ID: From: Nikos Mavrogiannopoulos To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [TLS] preventing cross protocols attacks -01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 12:17:07 -0000 Hello, I've updated the document proposing protection against cross protocol attacks. http://tools.ietf.org/search/draft-mavrogiannopoulos-tls-cross-protocol-01 This version references a new cross-protocol attack on TLS described in: http://www.cosic.esat.kuleuven.be/publications/article-2216.pdf In that attack a client is vulnerable to a server impersonation attack, if the server implements the explicit elliptic curve TLS option. regards, Nikos From lloyd@randombit.net Wed Aug 15 14:40:58 2012 Return-Path: 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 8BD4911E808A for ; Wed, 15 Aug 2012 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhPwOWZoS5UP for ; Wed, 15 Aug 2012 14:40:58 -0700 (PDT) Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2151111E80CC for ; Wed, 15 Aug 2012 14:40:58 -0700 (PDT) Received: by chihiro.randombit.net (Postfix, from userid 1000) id 72A971248658; Wed, 15 Aug 2012 17:40:56 -0400 (EDT) Date: Wed, 15 Aug 2012 17:40:56 -0400 From: Jack Lloyd To: tls@ietf.org Message-ID: <20120815214055.GE21531@randombit.net> Mail-Followup-To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [TLS] DTLS 1.2 HelloVerifyRequest version numbers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 21:40:58 -0000 I'm having a hard time reconciling these statements in RFC 6347 (all in section 4.2.1): (a) "[...] DTLS 1.2 server implementations SHOULD use DTLS version 1.0 [in the HelloVerifyRequest] regardless of the version of TLS that is expected to be negotiated." (b) "In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2." (c) "The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. Upon receipt of the ServerHello, the client MUST verify that the server version values match." Statement (a) says servers should send server_version=1.0 in the HelloVerifyRequest even if they and the client both support DTLS 1.2, (b) seems to be saying that a client seeing a HelloVerifyRequest with server_version=1.0 should not assume the server will eventually negotiate 1.0, and (c) seems to say that the client must, after having seen a 1.0 HelloVerifyRequest, reject a ServerHello with version != 1.0 How, then, is it expected for a DTLS 1.2 connection to be negotiated? The only out I see here is servers ignoring the SHOULD of (a) and sending DTLS 1.2 in the HelloVerifyRequest if that is what it would have negotiated from the client hello. And the MUSTs of (b) and (c) seem to directly contradict each other, so I have to wonder if the check in (c) is something accidentally carried over from the 1.0 spec. Regards, Jack From jsalowey@cisco.com Sun Aug 19 22:07:39 2012 Return-Path: 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 0C89E21F857E for ; Sun, 19 Aug 2012 22:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkFfPFjIWC+r for ; Sun, 19 Aug 2012 22:07:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8321F8577 for ; Sun, 19 Aug 2012 22:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1703; q=dns/txt; s=iport; t=1345439258; x=1346648858; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PSKLdFY5BMy5jC/DPd+9WFj3tVHcHxja72JEYZ8AFyg=; b=mrNeOfHhMFbjfPc2DWevfEX6Xr+DqF74JoPplchffEqRetLcAw6rn67w 22RCv5HpWPc2CXrfW+mgPl68PLihU6RrqOmHag6IGlLPMPc/0tCWK78nZ 6JnCeNFSDcGLvpLWLyFyea+NZBSepdqTCyRNDLHh7l77kEyRBSqPFdXes 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAObEMVCtJV2d/2dsb2JhbABFukSBB4IgAQEBAwEBAQEPAScxAwsFCwIBCBgeECcLJQIEDgUih2UGC5hBnzWLC4YyYAOVUIEUjRiBZoJh X-IronPort-AV: E=Sophos;i="4.77,795,1336348800"; d="scan'208";a="113252309" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 20 Aug 2012 05:07:37 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7K57bVf004314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Aug 2012 05:07:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 00:07:36 -0500 From: "Joseph Salowey (jsalowey)" To: Hannes Tschofenig Thread-Topic: [TLS] Proposed cached info update Thread-Index: AQHNcA7x4GaRp3GtpkSC+++BFRpQO5dHZmcAgBswuIA= Date: Mon, 20 Aug 2012 05:07:36 +0000 Message-ID: <142BC916-127E-4707-84B5-4C6646B8BF31@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19126.004 x-tm-as-result: No--38.093300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Proposed cached info update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 05:07:39 -0000 I also agree with this change. Can you submit a new draft with this change= and then we can go to working group last call?=20 Thanks, Joe On Aug 2, 2012, at 2:54 PM, Hannes Tschofenig wrote: > I agree that this change is useful.=20 >=20 > On Aug 1, 2012, at 10:56 AM, Stefan Santesson wrote: >=20 >> I went through the cached info draft and found something in the protocol >> syntax that I don't believe is totally correctly expressed. >>=20 >> I made a diff that shows my proposed update: >> http://tinyurl.com/cachedinfodiff >>=20 >>=20 >> The issue at hand is that we use an existing structure to send the cache= d >> info. >>=20 >> The data being replaced is in both cases sent as a vector (single >> dimension array) of opaque blobs. >> The data being sent instead is a vector of structured cached info elemen= ts. >>=20 >> This makes the sending of cached info syntax compatible with the origina= l >> syntax as the structured cached info element is compatible with an opaqu= e >> blob element. >>=20 >> The current draft and the proposed change is bits on the wire compatible= , >> it just assigns the vector containing cached info a more sensible name >> "cached_objects<1..2^24-1> instead of using the name of the old opaque >> vector being replaced (i.e. ASN.1Cert<1..2^24-1> and >> DistinguishedName<1..2^16-1>). >>=20 >> I would like those being more experts in the TSL presentation language t= o >> double check me so I don't make a stupid error here. >>=20 >> Thanks >>=20 >> /Stefan >>=20 >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From dkg@fifthhorseman.net Wed Aug 29 12:54:21 2012 Return-Path: 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 2A7E621F8568 for ; Wed, 29 Aug 2012 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS3s9Td2h6-V for ; Wed, 29 Aug 2012 12:54:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 95E0321F8567 for ; Wed, 29 Aug 2012 12:54:20 -0700 (PDT) Received: from pip.fifthhorseman.net (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 498DBF970 for ; Wed, 29 Aug 2012 15:54:18 -0400 (EDT) Received: by pip.fifthhorseman.net (Postfix, from userid 1000) id A2839118E8; Wed, 29 Aug 2012 15:54:16 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu) Date: Wed, 29 Aug 2012 15:54:16 -0400 Message-ID: <87oblttqxj.fsf@pip.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Subject: [TLS] shared secret keys between TLS clients: specific risks? OK in certain suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:54:21 -0000 Hi TLS WG-- This is a hypothetical question about an unusual use of TLS, a scenario which goes against all my instincts about reasonable key management. I'm hoping for any insight or analysis that might help me understand the specific risks. Consider a TLS server that requires client-side key-based authentication, but doesn't actually need (or want) to know which one of a group of clients is connecting. Let's say the operator of this TLS server creates a single secret asymmetric (RSA or ECDSA or DSA) key (and corresponding X.509 certificate), and shared the same key each one of the group of several clients. I'm also fine assuming that both the server and the clients will insist on negotiating a non-NULL cipher suite (maybe even a specific one if necessary), are compliant with TLS 1.2, are extension-capable, and refuse to negotiate down to an earlier version of TLS. Is there a way that one such client (with a copy of the secret key used by the client group) could snoop on (or inject traffic into) a connection established by one of the other clients that share the key? Or would this depend on the cipher suite selected? Clearly, at least PFS in the face of client-key compromise is a pre-requisite here; i note that several of the existing PFS notes deal with the concept of the server's secret key being compromised, but don't mention if a compromised/shared client-side secret key has the same implications. And of course PFS doesn't itself address the possibility of active attacks. Alternatively, if we think the one-secret-key-per-party assumption for asymmetric keys is deep enough that we shouldn't even consider use cases that violate it: would something like RSA-PSK be possible for the same approach (multiple clients, same PSK on each client) as a way to avoid asymmetric keys on the client? Are there other risks besides client-to-client snooping/tampering associated with this scenario? Any other thoughts or observations or specific risks worth considering in this context? Regards, --dkg From agl@google.com Wed Aug 29 13:08:09 2012 Return-Path: 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 735B311E80E8 for ; Wed, 29 Aug 2012 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVeMO+VfUMEC for ; Wed, 29 Aug 2012 13:08:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA921F86C8 for ; Wed, 29 Aug 2012 13:08:08 -0700 (PDT) Received: by iabz21 with SMTP id z21so2070931iab.31 for ; Wed, 29 Aug 2012 13:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=mN4MHEv3BIu8avY692Uw3l5p8xYbqhhYRPRESG8Sa1M=; b=Cm73Neu65pVD7dwXUOJTmnPr22Z3bW8W7e3Q7u7wAN3puIEkhBBPJ4aEI0XhYr+Llz CD7Er8xYp4ESup6AaxUNxskFNb48sXuEtuKgpGIK94QP5M1lae9W005V3mfp86GiqXfm c4aDEnqlvh6cslS1hZp1hsPZjUaJqLkdLMWuLyxlKgO0t2N+3nTLD+GE04EqAetb2YV0 Jhk9eJ1mZIKHfYVY6rSH+9hbddTOAjRiIVrw+EVdISgsZfr4c6/mvOOoJWEBSoE6MgzS zi92CmeF7rBYxXuZ0B419M7nj8kd4mdLEAMlu1mgPdd4bsmYQUAgiFEERfRToYAdqz3v waBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=mN4MHEv3BIu8avY692Uw3l5p8xYbqhhYRPRESG8Sa1M=; b=jpR+rttn0A5TPcUywHCN57B/ZXR4nCFYOH4yN65ypWGNfo/9OUtfOjgHpXGC33stk3 +SI7sWpbPBcl3XTY2E2AElI3YEh4kaY1UBQ0eNHDDcEElyjdqCxk+JnIhgTd/RoXo1De o5p8n/bvTjJs1ZG7iD9cyf0WyoSG4wPnhQJiSPuWERLdThQFCqE/+hJ4KsNd9R/AfzL4 AQOtac2OOlgHlzAPMKYTTX+6YSNSn25pDnFK1BFEotoJXOFAolOvlwn0+qkEtZaJAMp3 y2eNXGRj8i0287KKTMH4694dqYkelYmgJzDTuRp8huu66bJvC+9VQAfmsHYNUTVdNQ++ INIw== Received: by 10.50.1.204 with SMTP id 12mr3118737igo.56.1346270887728; Wed, 29 Aug 2012 13:08:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.1.204 with SMTP id 12mr3118725igo.56.1346270887607; Wed, 29 Aug 2012 13:08:07 -0700 (PDT) Received: by 10.231.224.84 with HTTP; Wed, 29 Aug 2012 13:08:07 -0700 (PDT) In-Reply-To: <87oblttqxj.fsf@pip.fifthhorseman.net> References: <87oblttqxj.fsf@pip.fifthhorseman.net> Date: Wed, 29 Aug 2012 16:08:07 -0400 Message-ID: From: Adam Langley To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnvWbRxA675lvNuBui55WLv3QS2lMk95cKv35xpzZL/Hk8sDJ3ZPVQpJXrvw+5LGHk18SufI0p+H1EdlsUFlMA1y+VPrDsRyJsNJ0xKXzKpIKWbVgpeHvG5hnFn9RHsCKr2I6Szfq0WuMdA7yBMn0Ivtf5liL2BMK6Qfv0O8+4EcH5rJfbttll/uv9S5gHIPiO02nYa Cc: tls@ietf.org Subject: Re: [TLS] shared secret keys between TLS clients: specific risks? OK in certain suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:08:09 -0000 On Wed, Aug 29, 2012 at 3:54 PM, Daniel Kahn Gillmor wrote: > This is a hypothetical question about an unusual use of TLS, a scenario > which goes against all my instincts about reasonable key management. > I'm hoping for any insight or analysis that might help me understand the > specific risks. DH/ECDH certificates would allow a private key holder to decrypt other connections made with the same client certificate. I believe that a signature based (RSA/ECDSA) client certificate is `safe' as a group authentication method in that one member of the group could not intercept/decrypt a connection made by another. "Group signatures" are a problem that has been studied and has a practical solution: http://crypto.stanford.edu/~dabo/papers/groupsigs.pdf, although the bilinear group presents an implementation challenge. ("Group signatures" in that case are defined to have slightly different properties, see the paper.) Cheers AGL From mbadra@gmail.com Wed Aug 29 13:24:21 2012 Return-Path: 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 8AF8811E80EA for ; Wed, 29 Aug 2012 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvnZRKRzZAu5 for ; Wed, 29 Aug 2012 13:24:20 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5F35E21F84F9 for ; Wed, 29 Aug 2012 13:24:20 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so930799wib.13 for ; Wed, 29 Aug 2012 13:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fPxgAWXOpYaUWoTF8Z0tfotytESEnbcnUiIdEwDWO7s=; b=qJ4AZWRk2vFw5QLqv6pIE5K24c6ApTUDxivah60qc48qZ+nrJzKNvUPsupfonLzASw +fEoapnUMg0t+lSwLpBJJ+g/0b6/nJPLQgE7KVbcsaqvHZT5K0o5KutIkB3Sfp9Y6jG0 B6a3nr1QDZr9cG4bLo1SLHrLghiCX2iLOX0an0UwXDi6D0xbch1AzkYC7prh0nw+iutG MpRe8peKd7H4CCh9QIHIBaZa0QFYmx6vf27LxWUI77HlkYuEoM5/T371zdi3JFZAXjGO Z/Qst+wlPAM+vzwnvuruTf5ST1zUx1EoltzOm7kPQDgo4QC4cyJzm1xmJMBzsT3fpP+C HfZw== MIME-Version: 1.0 Received: by 10.180.109.129 with SMTP id hs1mr6075693wib.0.1346271859586; Wed, 29 Aug 2012 13:24:19 -0700 (PDT) Received: by 10.216.161.1 with HTTP; Wed, 29 Aug 2012 13:24:19 -0700 (PDT) In-Reply-To: <87oblttqxj.fsf@pip.fifthhorseman.net> References: <87oblttqxj.fsf@pip.fifthhorseman.net> Date: Wed, 29 Aug 2012 22:24:19 +0200 Message-ID: From: Mohamad Badra To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=e89a8f13ea88f6369204c86d5772 Cc: tls@ietf.org Subject: Re: [TLS] shared secret keys between TLS clients: specific risks? OK in certain suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:24:21 -0000 --e89a8f13ea88f6369204c86d5772 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 29, 2012 at 9:54 PM, Daniel Kahn Gillmor wrote: > Hi TLS WG-- > > This is a hypothetical question about an unusual use of TLS, a scenario > which goes against all my instincts about reasonable key management. > I'm hoping for any insight or analysis that might help me understand the > specific risks. > > Consider a TLS server that requires client-side key-based > authentication, but doesn't actually need (or want) to know which one of > a group of clients is connecting. > > Let's say the operator of this TLS server creates a single secret > asymmetric (RSA or ECDSA or DSA) key (and corresponding X.509 > certificate), and shared the same key each one of the group of several > clients. > > I'm also fine assuming that both the server and the clients will insist > on negotiating a non-NULL cipher suite (maybe even a specific one if > necessary), are compliant with TLS 1.2, are extension-capable, and > refuse to negotiate down to an earlier version of TLS. > > Is there a way that one such client (with a copy of the secret key used > by the client group) could snoop on (or inject traffic into) a > connection established by one of the other clients that share the key? > Yes if the client and the server negociate PSK Key Exchange Algorithm No if they negociate DHE_PSK or RSA_PSK Key Exchange Algorithms Please refer to Section 2 of RFC4279 on the premaster secret formatting. Best regards Badra --e89a8f13ea88f6369204c86d5772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 29, 2012 at 9:54 PM, Daniel = Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Hi TLS WG--

This is a hypothetical question about an unusual use of TLS, a scenario
which goes against all my instincts about reasonable key management.
I'm hoping for any insight or analysis that might help me understand th= e
specific risks.

Consider a TLS server that requires client-side key-based
authentication, but doesn't actually need (or want) to know which one o= f
a group of clients is connecting.

Let's say the operator of this TLS server creates a single secret
asymmetric (RSA or ECDSA or DSA) key (and corresponding X.509
certificate), and shared the same key each one of the group of several
clients.

I'm also fine assuming that both the server and the clients will insist=
on negotiating a non-NULL cipher suite (maybe even a specific one if
necessary), are compliant with TLS 1.2, are extension-capable, and
refuse to negotiate down to an earlier version of TLS.

Is there a way that one such client (with a copy of the secret key used
by the client group) could snoop on (or inject traffic into) a
connection established by one of the other clients that share the key?
<= /blockquote>

Yes if the client and the server negociate= =A0PSK Key Exchange Algorithm
No if they negociate DHE_PSK or RSA_PSK Key Exchange Algorithms
<= br>
Please refer to Section 2 of RFC4279 on the=A0premaster secret formatting.

Best regards
Badra
--e89a8f13ea88f6369204c86d5772--