From tls-bounces@ietf.org Wed Apr 2 07:15:03 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32E33A6A9D; Wed, 2 Apr 2008 07:15:03 -0700 (PDT) X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 662BB3A6A8D; Wed, 2 Apr 2008 07:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080402141502.662BB3A6A8D@core3.amsl.com> Date: Wed, 2 Apr 2008 07:15:02 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-ecdhe-psk-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECDHE_PSK Ciphersuites for Transport Layer Security (TLS) Author(s) : M. Badra Filename : draft-ietf-tls-ecdhe-psk-01.txt Pages : 7 Date : 2008-04-02 This document extends RFC 4279, RFC 4492 and RFC 4785, and specifies a set of ciphersuites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange (ECDH). These ciphersuites provide Perfect Forward Secrecy (PFS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-ecdhe-psk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-02071358.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Wed Apr 2 07:22:20 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134333A6DB0; Wed, 2 Apr 2008 07:22:20 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862B93A6D66 for ; Wed, 2 Apr 2008 07:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk3RSntbdR8A for ; Wed, 2 Apr 2008 07:22:17 -0700 (PDT) Received: from smtpde03.sap-ag.de (unknown [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 00CA53A6C24 for ; Wed, 2 Apr 2008 07:22:16 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m32ELiw2002555 for ; Wed, 2 Apr 2008 16:21:54 +0200 (MEST) From: Martin Rex Message-Id: <200804021421.m32ELfx5001291@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 2 Apr 2008 16:21:41 +0200 (MEST) MIME-Version: 1.0 X-Scanner: Virus Scanner virwal07 X-SAP: out Subject: [TLS] ServerCertificate and intermediate CA certs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org I just received a request for help with an SSL interopability problem that a colleague encountered. He observed that the server certificate validation failed, reporting an incomplete certificate chain when he tried to connect to an (apparently Apache) Web-Server. He had configured the "Verisign Class 3 Public Primary CA" as trusted, and the Server only sends the Server cert, but fails to include the intermediate CA cert (VeriSign Class 3 Secure Server CA). In my reading of SSLv3->TLSv1.1 that is an obvious and serious violation of the protocol spec. Omitting the self-signed root certificate and the end of the servers certificate chain from the ServerCertificate message is OK/allowed, but omitting intermediate CAs is definitely NOT allowed by the spec. IMHO, the SSL/TLS stack ought to enforce that the certificate chain in the ServerCertificate message is correct, i.e. omits at most a self-signed root certificate, but NEVER any intermediate CAs and not even start an SSL handshake if that prerequisite can not be determined. Does anyone, by chance, know how/whether that problem can be fixed by configuration in Apache and how (i.e. how to configure Apache so that OpenSSL sends out a correct certification path in the ServerCertificate message, including all necessary intermediate CA certificates)? -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 2 07:47:11 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABFD3A6DD7; Wed, 2 Apr 2008 07:47:11 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A437B3A6F17 for ; Wed, 2 Apr 2008 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUqLWI-3z5ul for ; Wed, 2 Apr 2008 07:47:09 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 390B23A680E for ; Wed, 2 Apr 2008 07:45:03 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id m32EXwin003898; Wed, 2 Apr 2008 10:33:58 -0400 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 15:45:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 10:45:03 -0400 Message-ID: <1CD009E1F15C294C933AE84184EBD8D6027C9CDB@DUL1WNEXMB05.vcorp.ad.vrsn.com> In-Reply-To: <200804021421.m32ELfx5001291@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] ServerCertificate and intermediate CA certs Thread-Index: AciUzPvieTACPgePTeGSnoR9NoNHAwAAdu/Q From: "Bentkofsky, Michael" To: , X-OriginalArrivalTime: 02 Apr 2008 14:45:03.0111 (UTC) FILETIME=[22637170:01C894D0] Subject: Re: [TLS] ServerCertificate and intermediate CA certs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Martin, I believe the instructions you seek are posted on VeriSign's web site, specifically on how to configure Apache: https://knowledge.verisign.com/support/ssl-certificates-support/index?pa ge=content&id=AR193 and https://knowledge.verisign.com/support/ssl-certificates-support/index?pa ge=content&id=AR158. I'd also direct you to the VeriSign information on the recent use of an Intermediate CA: https://knowledge.verisign.com/support/ssl-certificates-support/index?pa ge=content&id=AR212. Mike > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of Martin Rex > Sent: Wednesday, April 02, 2008 10:22 AM > To: tls@ietf.org > Subject: [TLS] ServerCertificate and intermediate CA certs > > I just received a request for help with an SSL interopability > problem that a colleague encountered. He observed that the > server certificate validation failed, reporting an incomplete > certificate chain when he tried to connect to an (apparently > Apache) Web-Server. > > He had configured the "Verisign Class 3 Public Primary CA" as > trusted, and the Server only sends the Server cert, but fails > to include the intermediate CA cert (VeriSign Class 3 Secure > Server CA). > > In my reading of SSLv3->TLSv1.1 that is an obvious and > serious violation of the protocol spec. Omitting the > self-signed root certificate and the end of the servers > certificate chain from the ServerCertificate message is > OK/allowed, but omitting intermediate CAs is definitely NOT > allowed by the spec. > > IMHO, the SSL/TLS stack ought to enforce that the certificate > chain in the ServerCertificate message is correct, i.e. omits > at most a self-signed root certificate, but NEVER any > intermediate CAs and not even start an SSL handshake if that > prerequisite can not be determined. > > Does anyone, by chance, know how/whether that problem can be > fixed by configuration in Apache and how (i.e. how to > configure Apache so that OpenSSL sends out a correct > certification path in the ServerCertificate message, > including all necessary intermediate CA certificates)? > > > -Martin > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 3 09:12:29 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6284728C696; Thu, 3 Apr 2008 09:12:29 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06E228C6D0 for ; Thu, 3 Apr 2008 09:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I1Ea1ZHK7oM for ; Thu, 3 Apr 2008 09:12:21 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 738C328C6B1 for ; Thu, 3 Apr 2008 09:10:50 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m33GAVm2028652; Thu, 3 Apr 2008 18:10:36 +0200 (MEST) From: Martin Rex Message-Id: <200804031610.m33GAJ6V004192@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Thu, 3 Apr 2008 18:10:19 +0200 (MEST) In-Reply-To: <1696498986EFEC4D9153717DA325CB7223A82C@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Mar 18, 8 01:39:49 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org If you read the news, you probably noticed the following paper today or these days: https://www.cynops.de/techzone/http_over_x509.html Although this Papers describes a serious design flaw in the rfc3280 suggestion to put URLs of intermediate CAs into X.509v3 cert extensions and have peers use them in order to be able to build a certification path, the very same problem will apply to every concept that a communication peer can be coerced to access one or more arbitrary URLs prior to authentication, and the Client Certificate URL extension appears to suffer the same vulnerabilities and security problems. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 3 17:05:41 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140E93A6C5B; Thu, 3 Apr 2008 17:05:41 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA433A68A7 for ; Thu, 3 Apr 2008 17:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfBdp-guEeX8 for ; Thu, 3 Apr 2008 17:05:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2348228C357 for ; Thu, 3 Apr 2008 17:05:30 -0700 (PDT) Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id m3405Wkq024188 for ; Fri, 4 Apr 2008 01:05:33 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1207267533; bh=n+E/7RRJLkycw80hWeWhdD0a60I=; h=DomainKey-Signature:Message-ID:Date:From:Sender:To:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Google-Sender-Auth; b=kbDSLWNWNIWueANPNByfE8 3xecJgqB5AR3tS7GzyV+E0dyWkkYkJCZEsK76wi8hBmz2RaSUBROhYWgYp7O2x3Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject: mime-version:content-type:content-transfer-encoding: content-disposition:x-google-sender-auth; b=Utit+1DzSGnNYn5rgIAOrMmUrxWtra/d6ZbFCvWM1WFT1iEPvo3+Uo+MeaOQOW8fp rXCC3vD0kcT/y8P5d9J9g== Received: from an-out-0708.google.com (anab21.prod.google.com [10.100.53.21]) by zps35.corp.google.com with ESMTP id m3405Vhh029753 for ; Thu, 3 Apr 2008 17:05:32 -0700 Received: by an-out-0708.google.com with SMTP id b21so924687ana.71 for ; Thu, 03 Apr 2008 17:05:31 -0700 (PDT) Received: by 10.100.105.15 with SMTP id d15mr1128496anc.32.1207267531210; Thu, 03 Apr 2008 17:05:31 -0700 (PDT) Received: by 10.100.4.17 with HTTP; Thu, 3 Apr 2008 17:05:31 -0700 (PDT) Message-ID: <28425e380804031705w36c081f0t478b47445e7fe00c@mail.gmail.com> Date: Thu, 3 Apr 2008 17:05:31 -0700 From: "Nagendra Modadugu" To: tls@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: c1d98f80a3830497 Subject: [TLS] Stateless Session Resumption support in Firefox 3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org I'd like to announce support for Stateless Session Resumption (rfc 5077, previously rfc 4507bis) in Firefox Beta 5. This extension is enabled by default. If anyone would like to help with interop testing please let me know. Thanks, nagendra _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 3 22:42:36 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08C93A69CB; Thu, 3 Apr 2008 22:42:36 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFB83A69CB for ; Thu, 3 Apr 2008 22:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HX+-nIQwH4j for ; Thu, 3 Apr 2008 22:42:35 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id F13BA3A67AC for ; Thu, 3 Apr 2008 22:42:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6EAB24808A6; Fri, 4 Apr 2008 18:42:38 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5HIk8W-r5Mx; Fri, 4 Apr 2008 18:42:38 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 556EA4808A3; Fri, 4 Apr 2008 18:42:38 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D84AE19EC0B9; Fri, 4 Apr 2008 18:42:31 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jheh5-0007lu-O7; Fri, 04 Apr 2008 18:42:31 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com In-Reply-To: <200804031610.m33GAJ6V004192@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 04 Apr 2008 18:42:31 +1300 Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Martin Rex writes: >Although this Papers describes a serious design flaw in the rfc3280 >suggestion to put URLs of intermediate CAs into X.509v3 cert extensions and >have peers use them in order to be able to build a certification path, the >very same problem will apply to every concept that a communication peer can >be coerced to access one or more arbitrary URLs prior to authentication, and >the Client Certificate URL extension appears to suffer the same >vulnerabilities and security problems. This has been known for a long time, and is even worse in protocols like OCSP where you can use this facility to scan and penetrate corporate networks, use machines as attack amplifiers, and so on. The PKIX response in the past has been "not our problem". I don't know if the TLS WG wants to make it their problem or not. It's always seemed a very obvious flaw, my code deliberately doesn't support any of these "turn a host into an attacker-controlled proxy" extensions. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 4 01:24:51 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD053A6D24; Fri, 4 Apr 2008 01:24:51 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B8F3A69E9 for ; Fri, 4 Apr 2008 01:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.873 X-Spam-Level: X-Spam-Status: No, score=-4.873 tagged_above=-999 required=5 tests=[AWL=1.726, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEiawp2vKpoj for ; Fri, 4 Apr 2008 01:24:49 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 57CE53A6D02 for ; Fri, 4 Apr 2008 01:24:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m348OYqi007635; Fri, 4 Apr 2008 11:24:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:24:30 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:24:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:24:30 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7247EFE3@vaebe104.NOE.Nokia.com> In-Reply-To: <200804031610.m33GAJ6V004192@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Implementation survey: Client Certificate URL extension thread-index: AciVpVMD+zIFfXfFS5WikbJavKK4TwAhvE1w References: <1696498986EFEC4D9153717DA325CB7223A82C@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Mar 18, 8 01:39:49 pm <200804031610.m33GAJ6V004192@fs4113.wdf.sap.corp> From: To: X-OriginalArrivalTime: 04 Apr 2008 08:24:30.0447 (UTC) FILETIME=[4DE2E7F0:01C8962D] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org This vulnerability of Client Certificate URL is already described in the Security Considerations text in RFC 4366, so it isn't anything particularly new. In the context of web browsing over TLS, it isn't really different than, say, the ability to include IMG URLs pointing to arbitrary hosts (not just the one the HTML page came from). I can see that this could be more of a problem in other contexts: e.g., email clients don't usually fetch image URLs (since that would reveal that the address works, when the email was read, approximate network location of the client, etc.) -- but if they fetch URLs during S/MIME certification path validation, it would have roughly the same result. Best regards, Pasi > -----Original Message----- > From: ext Martin Rex [mailto:Martin.Rex@sap.com] > Sent: 03 April, 2008 19:10 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: tls@ietf.org > Subject: Re: [TLS] Implementation survey: Client Certificate > URL extension > > If you read the news, you probably noticed the following paper > today or these days: > > https://www.cynops.de/techzone/http_over_x509.html > > Although this Papers describes a serious design flaw in the > rfc3280 suggestion to put URLs of intermediate CAs into X.509v3 > cert extensions and have peers use them in order to be able > to build a certification path, the very same problem will > apply to every concept that a communication peer can be > coerced to access one or more arbitrary URLs prior to > authentication, and the Client Certificate URL extension > appears to suffer the same vulnerabilities and security > problems. > > -Martin > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 4 05:54:11 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0843A6AC6; Fri, 4 Apr 2008 05:54:11 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044153A6D61 for ; Fri, 4 Apr 2008 05:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUjpSDKSn3FG for ; Fri, 4 Apr 2008 05:54:09 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E37023A69AB for ; Fri, 4 Apr 2008 05:54:08 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m34Crg6a004289; Fri, 4 Apr 2008 14:53:52 +0200 (MEST) From: Martin Rex Message-Id: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Fri, 4 Apr 2008 14:53:39 +0200 (MEST) In-Reply-To: <1696498986EFEC4D9153717DA325CB7247EFE3@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Apr 4, 8 11:24:30 am MIME-Version: 1.0 X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Pasi.Eronen@nokia.com wrote: > > This vulnerability of Client Certificate URL is already described in > the Security Considerations text in RFC 4366, so it isn't anything > particularly new. > > In the context of web browsing over TLS, it isn't really different > than, say, the ability to include IMG URLs pointing to arbitrary hosts > (not just the one the HTML page came from). It is completely different! The regular HTTP/HTML based attacks attack the client/browser. The certificate extensions and the client-cert-URL extension for TLS attack the server, and there is no "must visit a hostile website" involved at all, the server is guaranteed to fall prey to every attack automatically if it supports/implements such a feature (or "inherits" this feature from the underlying middleware). > > I can see that this could be more of a problem in other contexts: > e.g., email clients don't usually fetch image URLs (since that would > reveal that the address works, when the email was read, approximate > network location of the client, etc.) -- but if they fetch URLs during > S/MIME certification path validation, it would have roughly the same > result. For some firewalls it is sufficient to call a particular URL from the inside (with parameters tacked at the end of the URL) in order to open a hole that can be entered from the outside. Generating advertising "clicks" might be another abuse. Being able to coerce a server to access an arbitrary URL from the inside of his network is IMHO a pretty serious security problem. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 4 06:16:47 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C0B3A6B47; Fri, 4 Apr 2008 06:16:47 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D953A6D9D for ; Fri, 4 Apr 2008 06:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-6b2TdYdRuy for ; Fri, 4 Apr 2008 06:16:44 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 7B1A128C603 for ; Fri, 4 Apr 2008 06:16:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BCBFE9C6F7; Sat, 5 Apr 2008 02:16:47 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTcLqy6M4U0P; Sat, 5 Apr 2008 02:16:47 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 704289C6EF; Sat, 5 Apr 2008 02:16:47 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 38D9D19EC0B9; Sat, 5 Apr 2008 02:16:47 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jhlmh-0003u2-2x; Sat, 05 Apr 2008 02:16:47 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com In-Reply-To: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp> Message-Id: Date: Sat, 05 Apr 2008 02:16:47 +1300 Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Martin Rex writes: >For some firewalls it is sufficient to call a particular URL from the inside >(with parameters tacked at the end of the URL) in order to open a hole that >can be entered from the outside. > >Generating advertising "clicks" might be another abuse. > >Being able to coerce a server to access an arbitrary URL from the inside of >his network is IMHO a pretty serious security problem. It's even worse than that, it's turning the server into an attacker-controlled proxy inside the firewall. For example I can perform port scans of an organisation's internal network (and in general attack its internal servers) using this "feature". I'll see if I can dig up the postings about this, although since the discussion was up to 10 years ago I'm not sure if I still have them. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 4 18:22:50 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89BB3A69C9; Fri, 4 Apr 2008 18:22:50 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D273A69C9 for ; Fri, 4 Apr 2008 18:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_50=0.001, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs+pMcMYCJiA for ; Fri, 4 Apr 2008 18:22:47 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by core3.amsl.com (Postfix) with ESMTP id 00B233A67FE for ; Fri, 4 Apr 2008 18:22:46 -0700 (PDT) Received: from emd2-omf04.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id C4A25F2D02 for ; Sat, 5 Apr 2008 01:22:52 +0000 (UTC) X-SpamScore: 30 X-Spamcatcher-Summary: 30, 2, 0, f0592bbd52fcd08e, 8f52778dc8a64581, nelson@bolyard.com, -, RULES_HIT:152:355:379:599:601:946:978:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1537:1560:1593:1594:1676:1711:1714:1730:1747:1766:1792:2393:2559:2562:3027:3865:3867:3870:4206:4250:4321:4647:5007:6119:7652, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: (100%) BODY: contains "porno" obfuscated; Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by emd2-omf04.hostedemail.com (Postfix) with ESMTP for ; Sat, 5 Apr 2008 01:22:52 +0000 (UTC) Message-ID: <47F6D4EA.307@bolyard.com> Date: Fri, 04 Apr 2008 18:24:58 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b5pre) Gecko/2008031700 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: tls@ietf.org References: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp> In-Reply-To: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp> Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Martin Rex wrote, On 2008-04-04 05:53: > Generating advertising "clicks" might be another abuse. Generating "clicks" on child porno sites might be enough to bring the FBI to visit the victim site's sys admins, in the USA. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Apr 7 00:35:56 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F6128C2F9; Mon, 7 Apr 2008 00:35:56 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC4728C3B1 for ; Mon, 7 Apr 2008 00:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.085 X-Spam-Level: X-Spam-Status: No, score=-5.085 tagged_above=-999 required=5 tests=[AWL=1.514, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk9BKw50HlL3 for ; Mon, 7 Apr 2008 00:35:54 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1D51A28C2F8 for ; Mon, 7 Apr 2008 00:34:58 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m377YwvO019178; Mon, 7 Apr 2008 10:35:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:35:06 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:35:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 10:35:07 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com> In-Reply-To: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Implementation survey: Client Certificate URL extension thread-index: AciWUwAVQQUeJB9vTBmkZIhYwJ0XKgCLn6Qg References: <1696498986EFEC4D9153717DA325CB7247EFE3@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Apr 4, 8 11:24:30 am <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp> From: To: X-OriginalArrivalTime: 07 Apr 2008 07:35:06.0544 (UTC) FILETIME=[E6807300:01C89881] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Martin Rex wrote: > Pasi.Eronen@nokia.com wrote: > > > > This vulnerability of Client Certificate URL is already described in > > the Security Considerations text in RFC 4366, so it isn't anything > > particularly new. > > > > In the context of web browsing over TLS, it isn't really different > > than, say, the ability to include IMG URLs pointing to arbitrary > > hosts (not just the one the HTML page came from). > > It is completely different! > > The regular HTTP/HTML based attacks attack the client/browser. > > The certificate extensions and the client-cert-URL extension for TLS > attack the server, and there is no "must visit a hostile website" > involved at all, the server is guaranteed to fall prey to every > attack automatically if it supports/implements such a feature (or > "inherits" this feature from the underlying middleware). You're quite right, I wasn't thinking clearly -- this is indeed quite different, since it targets the server. Nevertheless, it is described in RFC 4366 already; do you think there's something more we should add in 4366bis? Best regards, Pasi _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 9 10:05:58 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5323A6C1A; Wed, 9 Apr 2008 10:05:58 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E637F3A6D6C for ; Wed, 9 Apr 2008 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.144 X-Spam-Level: X-Spam-Status: No, score=0.144 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi06YbBas+El for ; Wed, 9 Apr 2008 10:05:55 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id ADA1C28C4E3 for ; Wed, 9 Apr 2008 10:05:27 -0700 (PDT) X-Trace: 2636459/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.254 X-SBRS: None X-RemoteIP: 62.188.122.254 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAN6T/Ec+vHr+/2dsb2JhbABCinuhHAQ X-IP-Direction: IN Received: from 1cust254.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.254]) by smtp.pipex.tiscali.co.uk with SMTP; 09 Apr 2008 18:05:43 +0100 Message-ID: <005801c89a5b$0f28e960$0601a8c0@allison> From: "tom.petch" To: "Eric Rescorla" , References: <20080319053351.B47D41B9480@kilo.rtfm.com> Date: Wed, 9 Apr 2008 11:51:24 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] DTLS 1.2: Call for spec ambiguities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Not an ambiguity - RFC4347 is very clear - but I have struggled to understand whether or not updates to base TLS apply to DTLS or not (eg new cipher suites such as draft-ietf-tls-ecdhe-psk-01.txt , RFC4366). RFC4347 does say that new cipher suites should specify if and how they apply, but in practice, that does not seem to have happened. And I echo the point about PMTU; I have seen DTLS criticised as being wholy unrealistic about PMTU, on some very unexpected mailing lists. Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: Sent: Wednesday, March 19, 2008 3:24 AM Subject: [TLS] DTLS 1.2: Call for spec ambiguities > The plan I proposed in Philadelphia for DTLS 1.2 includes > clarification of any issues that weren't clear in RFC 4347. > I intend to collect a list of those issues and then > have discussion/propose resolutions on the mailing list. > I'm already aware of three such issues: > > - Inclusion of the first ClientHello and HelloVerifyRequest > in CertificateVerify > - Handshake header inclusion in message hashes > - Whether PMTU discovery makes sense > > The first two seem to be pretty simple and have obvious > answers. The third requires talking to the TSV area. > > If WG members are aware of other issues, can you mail them > to me or the list by the end of April? I'll then summarize > on the list and start threads to discuss them. > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 9 12:13:03 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E858A3A6C41; Wed, 9 Apr 2008 12:13:03 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE23C3A6C14 for ; Wed, 9 Apr 2008 12:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NNGjvkKSGy1 for ; Wed, 9 Apr 2008 12:13:02 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 096203A6B4E for ; Wed, 9 Apr 2008 12:13:02 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 49CD95081A; Wed, 9 Apr 2008 12:15:11 -0700 (PDT) Date: Wed, 09 Apr 2008 12:15:11 -0700 From: Eric Rescorla To: "tom.petch" In-Reply-To: <005801c89a5b$0f28e960$0601a8c0@allison> References: <20080319053351.B47D41B9480@kilo.rtfm.com> <005801c89a5b$0f28e960$0601a8c0@allison> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080409191511.49CD95081A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] DTLS 1.2: Call for spec ambiguities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Wed, 9 Apr 2008 11:51:24 +0200, tom.petch wrote: > > Not an ambiguity - RFC4347 is very clear - but I have struggled to understand > whether or not updates to base TLS apply to DTLS or not (eg new cipher suites > such as draft-ietf-tls-ecdhe-psk-01.txt , > RFC4366). RFC4347 does say that new cipher suites should specify if and how > they apply, but in practice, that does not seem to have happened. Right. That is a bug in those specs. :) I'll add some guidelines in the main text about hwhat would be suitable. > And I echo the point about PMTU; I have seen DTLS criticised as being wholy > unrealistic about PMTU, on some very unexpected mailing lists. That could totally be. We tried to get this right base on what we thought we understood about the transport issues, but quite likely we didn't. I'll take another pass on reading up people's comments and getting with the TSV people. If anyone wants to point me at discussions they know about and save me some time, I wouldn't complain :) -Ekr > Tom Petch > > ----- Original Message ----- > From: "Eric Rescorla" > To: > Sent: Wednesday, March 19, 2008 3:24 AM > Subject: [TLS] DTLS 1.2: Call for spec ambiguities > > > > The plan I proposed in Philadelphia for DTLS 1.2 includes > > clarification of any issues that weren't clear in RFC 4347. > > I intend to collect a list of those issues and then > > have discussion/propose resolutions on the mailing list. > > I'm already aware of three such issues: > > > > - Inclusion of the first ClientHello and HelloVerifyRequest > > in CertificateVerify > > - Handshake header inclusion in message hashes > > - Whether PMTU discovery makes sense > > > > The first two seem to be pretty simple and have obvious > > answers. The third requires talking to the TSV area. > > > > If WG members are aware of other issues, can you mail them > > to me or the list by the end of April? I'll then summarize > > on the list and start threads to discuss them. > > > > -Ekr > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 08:49:43 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC813A6C75; Thu, 10 Apr 2008 08:49:43 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E993A6B2A for ; Thu, 10 Apr 2008 08:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWyjAre5qED7 for ; Thu, 10 Apr 2008 08:49:39 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 400C13A6C75 for ; Thu, 10 Apr 2008 08:49:37 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m3AFnIo6005651; Thu, 10 Apr 2008 17:49:23 +0200 (MEST) From: Martin Rex Message-Id: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Thu, 10 Apr 2008 17:49:17 +0200 (MEST) In-Reply-To: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Apr 7, 8 10:35:07 am MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Pasi.Eronen@nokia.com wrote: > > Martin Rex wrote: > > Pasi.Eronen@nokia.com wrote: > > > > > > This vulnerability of Client Certificate URL is already described in > > > the Security Considerations text in RFC 4366, so it isn't anything > > > particularly new. > > > > > > In the context of web browsing over TLS, it isn't really different > > > than, say, the ability to include IMG URLs pointing to arbitrary > > > hosts (not just the one the HTML page came from). > > > > It is completely different! > > > > The regular HTTP/HTML based attacks attack the client/browser. > > > > The certificate extensions and the client-cert-URL extension for TLS > > attack the server, and there is no "must visit a hostile website" > > involved at all, the server is guaranteed to fall prey to every > > attack automatically if it supports/implements such a feature (or > > "inherits" this feature from the underlying middleware). > > You're quite right, I wasn't thinking clearly -- this is indeed > quite different, since it targets the server. > > Nevertheless, it is described in RFC 4366 already; do you think > there's something more we should add in 4366bis? Security Considerations, section 6.3 of rfc4366 already describes the problems and implications in quite detail (I wasn't aware of that). But maybe that isn't scary enough? Personally, I feel quite uncomfortable with such a dangerous extension in an IETF standard. *I* can NOT think of a safe mode of operation for the client certificate URL extension. As soon as the admins enables it, his server is toast. Do we really need to standardize something that is so extremely dangerous? Btw. why should rfc4346bis (TLS 1.2) obsolete rfc4366 (TLS extensions)? draft-ietf-tls-rfc4346-bis-09.txt has this in the second line: Obsoletes (if approved): RFC 3268, 4346, 4366 None of the vital Security Considerations from rfc4366 was merged into rfc4346bis, so this appears to be an error. There is a fairly fresh rfc4366bis I-D claiming to obsolete rfc4366. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 09:01:38 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D483A6D87; Thu, 10 Apr 2008 09:01:38 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EA83A6D3A for ; Thu, 10 Apr 2008 09:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LtuhHIYgfyX for ; Thu, 10 Apr 2008 09:01:37 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id E7C7D3A6C2D for ; Thu, 10 Apr 2008 09:01:35 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 4FC7A2471 for ; Thu, 10 Apr 2008 12:01:55 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id CB4AB2470 for ; Thu, 10 Apr 2008 12:01:52 -0400 (EDT) Message-ID: <47FE39E7.2020209@pobox.com> Date: Thu, 10 Apr 2008 09:01:43 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> In-Reply-To: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >>>> This vulnerability of Client Certificate URL is already described in >>>> the Security Considerations text in RFC 4366, so it isn't anything >>>> particularly new. > > Security Considerations, section 6.3 of rfc4366 already describes the > problems and implications in quite detail (I wasn't aware of that). > But maybe that isn't scary enough? Personally, I feel quite uncomfortable > with such a dangerous extension in an IETF standard. *I* can NOT think > of a safe mode of operation for the client certificate URL extension. > As soon as the admins enables it, his server is toast. Do we really need > to standardize something that is so extremely dangerous? This could be made safe with some help from PKIX (if X.509 doesn't already support it -- I haven't read RFC 3280 or -bis in a while). If root certificates listed constraints on what constitutes a valid URL for retrieving issued certificates, then a server could scan the combined list from each trusted root to determine if it is safe to fetch a client certificate. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 09:04:33 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688CC3A6D17; Thu, 10 Apr 2008 09:04:33 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C993A6D3A for ; Thu, 10 Apr 2008 09:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHdY4ixE2XVp for ; Thu, 10 Apr 2008 09:04:25 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 74F613A6D82 for ; Thu, 10 Apr 2008 09:04:25 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E330C5085A; Thu, 10 Apr 2008 09:06:36 -0700 (PDT) Date: Thu, 10 Apr 2008 09:06:36 -0700 From: Eric Rescorla To: martin.rex@sap.com In-Reply-To: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> References: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080410160636.E330C5085A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Thu, 10 Apr 2008 17:49:17 +0200 (MEST), Martin Rex wrote: > > Pasi.Eronen@nokia.com wrote: > > > > Martin Rex wrote: > > > Pasi.Eronen@nokia.com wrote: > > > > > > > > This vulnerability of Client Certificate URL is already described in > > > > the Security Considerations text in RFC 4366, so it isn't anything > > > > particularly new. > > > > > > > > In the context of web browsing over TLS, it isn't really different > > > > than, say, the ability to include IMG URLs pointing to arbitrary > > > > hosts (not just the one the HTML page came from). > > > > > > It is completely different! > > > > > > The regular HTTP/HTML based attacks attack the client/browser. > > > > > > The certificate extensions and the client-cert-URL extension for TLS > > > attack the server, and there is no "must visit a hostile website" > > > involved at all, the server is guaranteed to fall prey to every > > > attack automatically if it supports/implements such a feature (or > > > "inherits" this feature from the underlying middleware). > > > > You're quite right, I wasn't thinking clearly -- this is indeed > > quite different, since it targets the server. > > > > Nevertheless, it is described in RFC 4366 already; do you think > > there's something more we should add in 4366bis? > > Security Considerations, section 6.3 of rfc4366 already describes the > problems and implications in quite detail (I wasn't aware of that). > But maybe that isn't scary enough? Personally, I feel quite uncomfortable > with such a dangerous extension in an IETF standard. *I* can NOT think > of a safe mode of operation for the client certificate URL extension. > As soon as the admins enables it, his server is toast. Do we really need > to standardize something that is so extremely dangerous? Too late for that. Plus, it's not like this is the only place this kind of thing is standardized. Cf. web pages. > Btw. why should rfc4346bis (TLS 1.2) obsolete rfc4366 (TLS extensions)? > draft-ietf-tls-rfc4346-bis-09.txt has this in the second line: > Obsoletes (if approved): RFC 3268, 4346, 4366 > > None of the vital Security Considerations from rfc4366 was merged into > rfc4346bis, so this appears to be an error. > There is a fairly fresh rfc4366bis I-D claiming to obsolete rfc4366. Together 4346-bis and 4366 bis obsolete 4366. As far as I know the security considerations in 4346-bis do cover the security considerations for the extensions mechanism itself and the extensions described in the document. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 17:46:55 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC573A6B2D; Thu, 10 Apr 2008 17:46:55 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F41F3A6B2D for ; Thu, 10 Apr 2008 17:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA03wXxIIHtH for ; Thu, 10 Apr 2008 17:46:54 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by core3.amsl.com (Postfix) with ESMTP id CBDED3A6ADA for ; Thu, 10 Apr 2008 17:46:53 -0700 (PDT) Received: from emd2-omf01.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id B9B8DBA6EC; Fri, 11 Apr 2008 00:47:14 +0000 (UTC) X-SpamScore: 50 X-Spamcatcher-Summary: 50, 0, 0, e14e6112c10b1158, 4d03dd85d1d55713, nelson@bolyard.com, -, RULES_HIT:152:355:379:601:967:973:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1539:1593:1594:1676:1711:1730:1747:1766:1792:2194:2199:2393:2525:2552:2560:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3622:3865:3866:3867:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4321:5007:6117:6119:6121:6122:7652:7679, 0, RBL:none, CacheIP: none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by emd2-omf01.hostedemail.com (Postfix) with ESMTP; Fri, 11 Apr 2008 00:47:14 +0000 (UTC) Message-ID: <47FEB492.6020209@bolyard.com> Date: Thu, 10 Apr 2008 17:45:06 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008040302 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: tls@ietf.org References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> In-Reply-To: <47FE39E7.2020209@pobox.com> Subject: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mike wrote, On 2008-04-10 09:01: > This could be made safe with some help from PKIX (if X.509 doesn't > already support it -- I haven't read RFC 3280 or -bis in a while). > If root certificates listed constraints on what constitutes a valid > URL for retrieving issued certificates, then a server could scan > the combined list from each trusted root to determine if it is safe > to fetch a client certificate. Are you all aware of this paper, now making a stir? https://www.cynops.de/techzone/http_over_x509.html It claims that fetching CA certs from URLs found in AIA extensions in certs that have not yet been validated is a vulnerability. At least one browser organization known to me agrees. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 18:06:15 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7E63A6B06; Thu, 10 Apr 2008 18:06:15 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092FE3A6ADA for ; Thu, 10 Apr 2008 18:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9xvxrj6DL0p for ; Thu, 10 Apr 2008 18:06:13 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1F9E03A69DC for ; Thu, 10 Apr 2008 18:06:13 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8E41750854; Thu, 10 Apr 2008 18:08:25 -0700 (PDT) Date: Thu, 10 Apr 2008 18:08:25 -0700 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <47FEB492.6020209@bolyard.com> References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080411010825.8E41750854@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Thu, 10 Apr 2008 17:45:06 -0700, Nelson B Bolyard wrote: > > Mike wrote, On 2008-04-10 09:01: > > > This could be made safe with some help from PKIX (if X.509 doesn't > > already support it -- I haven't read RFC 3280 or -bis in a while). > > If root certificates listed constraints on what constitutes a valid > > URL for retrieving issued certificates, then a server could scan > > the combined list from each trusted root to determine if it is safe > > to fetch a client certificate. > > Are you all aware of this paper, now making a stir? > > https://www.cynops.de/techzone/http_over_x509.html Yes, Martin cited this paper a few weeks ago. > It claims that fetching CA certs from URLs found in AIA extensions in certs > that have not yet been validated is a vulnerability. At least one browser > organization known to me agrees. How does that organization feel about inline images in HTML pages? -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 18:30:46 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B193A6BD0; Thu, 10 Apr 2008 18:30:46 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BE33A6AD7 for ; Thu, 10 Apr 2008 18:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT-+f2azhVdK for ; Thu, 10 Apr 2008 18:30:38 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by core3.amsl.com (Postfix) with ESMTP id 716313A6B54 for ; Thu, 10 Apr 2008 18:30:38 -0700 (PDT) Received: from emd2-omf07.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 46D5FD0964; Fri, 11 Apr 2008 01:30:59 +0000 (UTC) X-SpamScore: 50 X-Spamcatcher-Summary: 50, 0, 0, cadea4ef45d4f4bf, 4f4e0b77b7fdf9f9, nelson@bolyard.com, -, RULES_HIT:152:355:379:599:601:945:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1676:1711:1730:1747:1766:1792:2194:2199:2393:2525:2552:2553:2560:2563:2682:2685:2857:2859:2915:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4321:5007:6117:6119:6121:6122: 7652:7679:7904, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by emd2-omf07.hostedemail.com (Postfix) with ESMTP; Fri, 11 Apr 2008 01:30:59 +0000 (UTC) Message-ID: <47FEBED6.7040105@bolyard.com> Date: Thu, 10 Apr 2008 18:28:54 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008040302 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: Eric Rescorla References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <20080411010825.8E41750854@romeo.rtfm.com> In-Reply-To: <20080411010825.8E41750854@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Eric Rescorla wrote, On 2008-04-10 18:08: > At Thu, 10 Apr 2008 17:45:06 -0700, > Nelson B Bolyard wrote: >> Mike wrote, On 2008-04-10 09:01: >> >>> This could be made safe with some help from PKIX (if X.509 doesn't >>> already support it -- I haven't read RFC 3280 or -bis in a while). >>> If root certificates listed constraints on what constitutes a valid >>> URL for retrieving issued certificates, then a server could scan >>> the combined list from each trusted root to determine if it is safe >>> to fetch a client certificate. >> Are you all aware of this paper, now making a stir? >> >> https://www.cynops.de/techzone/http_over_x509.html > > Yes, Martin cited this paper a few weeks ago. > > >> It claims that fetching CA certs from URLs found in AIA extensions in certs >> that have not yet been validated is a vulnerability. At least one browser >> organization known to me agrees. > > How does that organization feel about inline images in HTML pages? The problem isn't so much when browsers initiate fetches for certs from servers. The major concerns are: a) servers fetching URLs from unvetted client auth certs, and b) mail clients fetching certs to verify signatures in emails from strangers. Some email clients, in particular, are good at not fetching remote content from html emails, which confirms email addresses to spammers. AIA cert fetching weakens their ability to defend against such attempts to validate email addresses. Servers see them selves as similarly weakened. I'm receiving inquiries about white listing CA URLs for AIA fetching. :( _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 19:13:26 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54803A6A66; Thu, 10 Apr 2008 19:13:26 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDBA3A69FB for ; Thu, 10 Apr 2008 19:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOBVsCZSJqnx for ; Thu, 10 Apr 2008 19:13:24 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id AF38D28C138 for ; Thu, 10 Apr 2008 19:13:24 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7C6B55085A; Thu, 10 Apr 2008 19:15:37 -0700 (PDT) Date: Thu, 10 Apr 2008 19:15:37 -0700 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <47FEBED6.7040105@bolyard.com> References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <20080411010825.8E41750854@romeo.rtfm.com> <47FEBED6.7040105@bolyard.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080411021537.7C6B55085A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Thu, 10 Apr 2008 18:28:54 -0700, Nelson B Bolyard wrote: > > Eric Rescorla wrote, On 2008-04-10 18:08: > > At Thu, 10 Apr 2008 17:45:06 -0700, > > Nelson B Bolyard wrote: > >> Mike wrote, On 2008-04-10 09:01: > >> > >>> This could be made safe with some help from PKIX (if X.509 doesn't > >>> already support it -- I haven't read RFC 3280 or -bis in a while). > >>> If root certificates listed constraints on what constitutes a valid > >>> URL for retrieving issued certificates, then a server could scan > >>> the combined list from each trusted root to determine if it is safe > >>> to fetch a client certificate. > >> Are you all aware of this paper, now making a stir? > >> > >> https://www.cynops.de/techzone/http_over_x509.html > > > > Yes, Martin cited this paper a few weeks ago. > > > > > >> It claims that fetching CA certs from URLs found in AIA extensions in certs > >> that have not yet been validated is a vulnerability. At least one browser > >> organization known to me agrees. > > > > How does that organization feel about inline images in HTML pages? > > The problem isn't so much when browsers initiate fetches for certs from > servers. The major concerns are: > a) servers fetching URLs from unvetted client auth certs, and > b) mail clients fetching certs to verify signatures in emails from strangers. > > Some email clients, in particular, are good at not fetching remote content > from html emails, which confirms email addresses to spammers. AIA cert > fetching weakens their ability to defend against such attempts to validate > email addresses. > > Servers see them selves as similarly weakened. > > I'm receiving inquiries about white listing CA URLs for AIA fetching. :( I assume these people are up in arms about DKIM, then? -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 10 20:20:48 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015AF3A69EE; Thu, 10 Apr 2008 20:20:48 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565C43A6BF5 for ; Thu, 10 Apr 2008 20:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAvbRdc-x4z8 for ; Thu, 10 Apr 2008 20:20:43 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 5F8EC3A6A11 for ; Thu, 10 Apr 2008 20:20:42 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id A0EA91CBE for ; Thu, 10 Apr 2008 23:21:03 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 3A0FA1CBD for ; Thu, 10 Apr 2008 23:21:01 -0400 (EDT) Message-ID: <47FED914.7050609@pobox.com> Date: Thu, 10 Apr 2008 20:20:52 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> In-Reply-To: <47FEB492.6020209@bolyard.com> Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >> This could be made safe with some help from PKIX (if X.509 doesn't >> already support it -- I haven't read RFC 3280 or -bis in a while). >> If root certificates listed constraints on what constitutes a valid >> URL for retrieving issued certificates, then a server could scan >> the combined list from each trusted root to determine if it is safe >> to fetch a client certificate. > > Are you all aware of this paper, now making a stir? > > https://www.cynops.de/techzone/http_over_x509.html > > It claims that fetching CA certs from URLs found in AIA extensions in certs > that have not yet been validated is a vulnerability. At least one browser > organization known to me agrees. What I suggested is that the information about which URL's are safe for the client certificate URL extension could be embedded in the -root- certificate, which you trust. When a client sends you a URL in place of a certificate, you would compare it to the information in each of your root certificates. If the URL matches one of them, you know it's safe to retrieve it; otherwise you best not. Also, theoretically it would be wasted effort since you would not be able to build a complete certificate chain. So this could also improve performance in cases where client authentication will fail. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 11 05:15:27 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D333A6F22; Fri, 11 Apr 2008 05:15:27 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480913A6F22 for ; Fri, 11 Apr 2008 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUm31t6wBRTQ for ; Fri, 11 Apr 2008 05:15:25 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id B40473A695C for ; Fri, 11 Apr 2008 05:14:56 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JkI9v-0000QX-VH; Fri, 11 Apr 2008 14:15:11 +0200 Received: from fweimer by bfk.de with local id 1JkI9y-0002YR-I5; Fri, 11 Apr 2008 14:15:14 +0200 To: Eric Rescorla References: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com> <20080410160636.E330C5085A@romeo.rtfm.com> From: Florian Weimer Date: Fri, 11 Apr 2008 14:15:14 +0200 In-Reply-To: <20080410160636.E330C5085A@romeo.rtfm.com> (Eric Rescorla's message of "Thu, 10 Apr 2008 09:06:36 -0700") Message-ID: <8263uotwod.fsf@mid.bfk.de> MIME-Version: 1.0 Cc: tls@ietf.org Subject: Re: [TLS] Implementation survey: Client Certificate URL extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org * Eric Rescorla: > Too late for that. Plus, it's not like this is the only place this > kind of thing is standardized. Cf. web pages. The more relevant example seems to be DTD fetching for XML documents (which can be triggered by automated document submission to a web server). It turns out that it's difficult to switch that off in many processing environments. -- = Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 11 11:40:39 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92ED63A6AC4; Fri, 11 Apr 2008 11:40:39 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9B33A6B42 for ; Fri, 11 Apr 2008 11:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQoSa++g-qnI for ; Fri, 11 Apr 2008 11:40:37 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by core3.amsl.com (Postfix) with ESMTP id 96BFE28C135 for ; Fri, 11 Apr 2008 11:40:10 -0700 (PDT) Received: from emd2-omf01.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id D0888463EF; Fri, 11 Apr 2008 18:40:32 +0000 (UTC) X-SpamScore: 50 X-Spamcatcher-Summary: 50, 0, 0, b309ea4b61a795d5, 4f4e0b77b7fdf9f9, nelson@bolyard.com, -, RULES_HIT:152:355:379:599:601:945:967:973:980:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1676:1711:1730:1747:1766:1792:2194:2199:2378:2393:2525:2552:2553:2560:2563:2682:2685:2857:2859:2915:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3354:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4321:5007:6117:6119:6121: 6122:7652:7679:7904:7974, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by emd2-omf01.hostedemail.com (Postfix) with ESMTP; Fri, 11 Apr 2008 18:40:32 +0000 (UTC) Message-ID: <47FFB01E.1050502@bolyard.com> Date: Fri, 11 Apr 2008 11:38:22 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008041001 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: Eric Rescorla References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <20080411010825.8E41750854@romeo.rtfm.com> <47FEBED6.7040105@bolyard.com> <20080411021537.7C6B55085A@romeo.rtfm.com> In-Reply-To: <20080411021537.7C6B55085A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Eric Rescorla wrote, On 2008-04-10 19:15: > At Thu, 10 Apr 2008 18:28:54 -0700, > Nelson B Bolyard wrote: >> Eric Rescorla wrote, On 2008-04-10 18:08: >>> At Thu, 10 Apr 2008 17:45:06 -0700, >>> Nelson B Bolyard wrote: >>>> Mike wrote, On 2008-04-10 09:01: >>>> >>>>> This could be made safe with some help from PKIX (if X.509 doesn't >>>>> already support it -- I haven't read RFC 3280 or -bis in a while). >>>>> If root certificates listed constraints on what constitutes a valid >>>>> URL for retrieving issued certificates, then a server could scan >>>>> the combined list from each trusted root to determine if it is safe >>>>> to fetch a client certificate. >>>> Are you all aware of this paper, now making a stir? >>>> >>>> https://www.cynops.de/techzone/http_over_x509.html >>> Yes, Martin cited this paper a few weeks ago. >>> >>>> It claims that fetching CA certs from URLs found in AIA extensions in certs >>>> that have not yet been validated is a vulnerability. At least one browser >>>> organization known to me agrees. >>> How does that organization feel about inline images in HTML pages? >> The problem isn't so much when browsers initiate fetches for certs from >> servers. The major concerns are: >> a) servers fetching URLs from unvetted client auth certs, and >> b) mail clients fetching certs to verify signatures in emails from strangers. >> >> Some email clients, in particular, are good at not fetching remote content >> from html emails, which confirms email addresses to spammers. AIA cert >> fetching weakens their ability to defend against such attempts to validate >> email addresses. >> >> Servers see them selves as similarly weakened. >> >> I'm receiving inquiries about white listing CA URLs for AIA fetching. :( > > I assume these people are up in arms about DKIM, then? No, they're just not doing DKIM. Otherwise they might be. :) With respect to email, their concern is presently limited to S/MIME v3. Their concern is: take an existing S/MIME v3 MUA and upgrade the cert verification library to one that can do AIA cert fetching: vulnerable. But of course, this email concern is a bit off topic for this list. :) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 11 12:32:53 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F863A6881; Fri, 11 Apr 2008 12:32:53 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42533A6A16 for ; Fri, 11 Apr 2008 12:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGrWSYA4Ypkg for ; Fri, 11 Apr 2008 12:32:50 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by core3.amsl.com (Postfix) with ESMTP id A48F43A682D for ; Fri, 11 Apr 2008 12:32:50 -0700 (PDT) Received: from emd2-omf05.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id E15BF106CC3; Fri, 11 Apr 2008 19:33:12 +0000 (UTC) X-SpamScore: 50 X-Spamcatcher-Summary: 50, 0, 0, 09d4754af306cb85, 4f4e0b77b7fdf9f9, nelson@bolyard.com, -, RULES_HIT:152:355:379:599:601:945:967:973:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1676:1711:1730:1747:1766:1792:2194:2199:2393:2525:2560:2563:2682:2685:2857:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3622:3743:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4321:4361:5007:6117:6119:6121:6122: 7652:7679:7875, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by emd2-omf05.hostedemail.com (Postfix) with ESMTP; Fri, 11 Apr 2008 19:33:12 +0000 (UTC) Message-ID: <47FFBC7B.1050600@bolyard.com> Date: Fri, 11 Apr 2008 12:31:07 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008041001 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: Mike References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <47FED914.7050609@pobox.com> In-Reply-To: <47FED914.7050609@pobox.com> Cc: tls@ietf.org Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mike wrote, On 2008-04-10 20:20: >>> This could be made safe with some help from PKIX (if X.509 doesn't >>> already support it -- I haven't read RFC 3280 or -bis in a while). >>> If root certificates listed constraints on what constitutes a valid >>> URL for retrieving issued certificates, then a server could scan >>> the combined list from each trusted root to determine if it is safe >>> to fetch a client certificate. >> Are you all aware of this paper, now making a stir? >> >> https://www.cynops.de/techzone/http_over_x509.html >> >> It claims that fetching CA certs from URLs found in AIA extensions in certs >> that have not yet been validated is a vulnerability. At least one browser >> organization known to me agrees. > > What I suggested is that the information about which URL's are safe > for the client certificate URL extension could be embedded in the > -root- certificate, which you trust. When a client sends you a URL > in place of a certificate, you would compare it to the information > in each of your root certificates. If the URL matches one of them, > you know it's safe to retrieve it; otherwise you best not. Please look at a diagram of the US Federal Bridge CA PKI, or the equivalent bridged PKI in Japan or South Korea, and tell us how your proposal would work in those environments. Regards, /Nelson _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 11 19:59:31 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F0E3A6AA4; Fri, 11 Apr 2008 19:59:31 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC623A68C4 for ; Fri, 11 Apr 2008 19:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4y0huU23EJv for ; Fri, 11 Apr 2008 19:59:27 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 417E63A6AA4 for ; Fri, 11 Apr 2008 19:59:26 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id EACED2618 for ; Fri, 11 Apr 2008 22:59:49 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 9290D2617 for ; Fri, 11 Apr 2008 22:59:49 -0400 (EDT) Message-ID: <48002592.3010802@pobox.com> Date: Fri, 11 Apr 2008 19:59:30 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <47FED914.7050609@pobox.com> <47FFBC7B.1050600@bolyard.com> In-Reply-To: <47FFBC7B.1050600@bolyard.com> Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > Please look at a diagram of the US Federal Bridge CA PKI, or the equivalent > bridged PKI in Japan or South Korea, and tell us how your proposal would > work in those environments. I don't know the specifics of any PKI, but I think the answer is the same for any one of them. A server can not blindly retrieve any URL presented by a client, so it needs to be configured as to what URL's are acceptable. One way to accomplish that is to put the information in the CA certificates as I suggested. If your question was meant to say that this would be difficult to do for those PKI's because servers don't know all of the intermediate CA's and don't have all of their certificates, then the answer is that they either need to be configured with those missing certificates, or they can't safely support the client certificate URL extension for those clients. This seems to be a case where you can't have your cake and eat it too. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From peebles@fujitsu.com Sat Apr 12 05:58:59 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB8C28C106 for ; Sat, 12 Apr 2008 05:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_CASINO=10.357, HTML_MESSAGE=0.001, MANGLED_CASINO=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_OBFU_CASINO_SUB=1.028, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRTHxtSW0nmQ for ; Sat, 12 Apr 2008 05:58:58 -0700 (PDT) Received: from 253-139.plus.kerch.net (253-139.plus.kerch.net [195.66.139.253]) by core3.amsl.com (Postfix) with ESMTP id 3CE8E28C167 for ; Sat, 12 Apr 2008 05:58:58 -0700 (PDT) Message-ID: <000701c89c9d$02570a95$d2dd8aa8@jahyuid> From: "angeli fielding" To: Subject: we have a cas1n0 that suits you Date: Sat, 12 Apr 2008 11:12:27 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C89C9D.02528407" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C89C9D.02528407 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Join me and over 2.000.000 players playing the casino and receive 3OO = Euros free on your first deposit. 1. Click on the link makebucks.biz 2. Get gaming software 3. Install and get your account. 4. Deposit up to 300 Euros and receive a match bonus up to 300 Euros! ------=_NextPart_000_0004_01C89C9D.02528407 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Join me and over 2.000.000 players playing the casino and receive 3OO = Euros free on your first deposit.

1. Click on the link makebucks.biz

2. Get gaming software

3. Install and get your account.

4. Deposit up to 300 Euros and receive a match bonus up to 300 = Euros!

------=_NextPart_000_0004_01C89C9D.02528407-- From tls-bounces@ietf.org Mon Apr 14 06:35:45 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82043A6D4F; Mon, 14 Apr 2008 06:35:45 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C1F3A6BD2 for ; Mon, 14 Apr 2008 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD0BcI4i0N8b for ; Mon, 14 Apr 2008 06:35:44 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 7DBEF3A6E95 for ; Mon, 14 Apr 2008 06:35:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9079F186DC for ; Tue, 15 Apr 2008 01:35:42 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oi-MOpyl5CV for ; Tue, 15 Apr 2008 01:35:42 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 77B95186D6 for ; Tue, 15 Apr 2008 01:35:42 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2471E19EC0B9 for ; Tue, 15 Apr 2008 01:35:42 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JlOqU-000695-1U for tls@ietf.org; Tue, 15 Apr 2008 01:35:42 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tls@ietf.org Message-Id: Date: Tue, 15 Apr 2008 01:35:42 +1200 Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mike writes: >What I suggested is that the information about which URL's are safe for the >client certificate URL extension could be embedded in the -root- certificate, >which you trust. And then you look up that URL in your trusted DNS... oops. (This also ignores the fact that you have to reissue your root cert every time some random server moves around, which I can't see any CA doing. Root certs are issued once, given a lifetime of 20-40 years, and then never touched again for fear of breaking things). The real problem here is that a server should never, ever initiate outgoing connections under the control of an external agent, which is what a lot of the PKIX protocols expect them to do. Other examples (just off the top of my head) are the logotypes and qualified certs/biometrics RFCs, which define an extension containing a URI that you're supposed to go to for further information. So a server, when seeing one of these certs, is supposed to go to whatever arbitrary location and port is specified and poke around there (I'm not sure what would happen if you entered, for example, an SSH URI instead of the more obvious HTTP one, but if the implementation is general enough you could use it for password-guessing attacks on internal SSH servers). It's just a really, really bad idea to build a capability for HTTP bounce scans into a (supposedly) passive protocol mechanism, and in particular turning a system that's supposed to provide security into a security hole just doesn't seem a winning long-term strategy to me. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Apr 14 07:52:01 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672383A687A; Mon, 14 Apr 2008 07:52:01 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D543A687A for ; Mon, 14 Apr 2008 07:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i4UQMDSXLiP for ; Mon, 14 Apr 2008 07:51:59 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 1FB373A67AE for ; Mon, 14 Apr 2008 07:51:54 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 7EA4F2F2D for ; Mon, 14 Apr 2008 10:52:23 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 32CD22F2B for ; Mon, 14 Apr 2008 10:52:23 -0400 (EDT) Message-ID: <48036F9A.1020900@pobox.com> Date: Mon, 14 Apr 2008 07:52:10 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >> What I suggested is that the information about which URL's are safe for the >> client certificate URL extension could be embedded in the -root- certificate, >> which you trust. > > And then you look up that URL in your trusted DNS... oops. Sure it's a potential attack, but consider the relative difficulty. If you do nothing and use the client certificate URL extension as it is today, all an attacker has to do is follow the protocol and specify a bogus URL in the client hello. Such a program could be written in a matter of hours and widely distributed for the amusement of script kiddies the world over. With the addition of URL constraints embedded in CA certificates, an attacker would have to actively modify DNS packets or mess with routes or whatever to launch an attack. This is a risk that some server operators are probably willing to take, while they would probably not accept the problems without the constraints, except in tightly controlled environments. > (This also ignores the fact that you have to reissue your root cert every time > some random server moves around, which I can't see any CA doing. Root certs > are issued once, given a lifetime of 20-40 years, and then never touched again > for fear of breaking things). You can plan for change by putting something like: http://*.client-cert-url-repo.some-ca.com in the root certificate and then assigning subdomains for each intermediate CA. The DNS would point to the particular machine with the certificates. If a server moves, you just change the DNS record. Of course with this an attacker can proxy attack the repository machines, so that needs to be considered. > The real problem here is that a server should never, ever initiate outgoing > connections under the control of an external agent, which is what a lot of the > PKIX protocols expect them to do. I have no stake in it, so I don't care one way or the other if the client certificate URL extension is removed. I just had an idea for how to improve the situation. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Apr 14 07:58:55 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F873A682C; Mon, 14 Apr 2008 07:58:55 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB923A67D0 for ; Mon, 14 Apr 2008 07:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRdx-OXxjYA8 for ; Mon, 14 Apr 2008 07:58:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 5F8063A682C for ; Mon, 14 Apr 2008 07:58:49 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id A52281069 for ; Mon, 14 Apr 2008 10:59:19 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 3EFC71067 for ; Mon, 14 Apr 2008 10:59:17 -0400 (EDT) Message-ID: <48037133.8070708@pobox.com> Date: Mon, 14 Apr 2008 07:58:59 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <48036F9A.1020900@pobox.com> In-Reply-To: <48036F9A.1020900@pobox.com> Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > today, all an attacker has to do is follow the protocol and specify a > bogus URL in the client hello. Sorry, I meant the CertificateURL message. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Apr 14 08:12:06 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341923A6AFF; Mon, 14 Apr 2008 08:12:06 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288703A6B53 for ; Mon, 14 Apr 2008 08:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdAmiTR5xuPO for ; Mon, 14 Apr 2008 08:12:01 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id CE1843A6AFF for ; Mon, 14 Apr 2008 08:12:00 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3EFCVch028743 for ; Mon, 14 Apr 2008 15:12:31 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3EFCVJF039033 for ; Mon, 14 Apr 2008 09:12:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3EFCRUl011741; Mon, 14 Apr 2008 10:12:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3EFCNM6011740; Mon, 14 Apr 2008 10:12:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Apr 2008 10:12:23 -0500 From: Nicolas Williams To: Peter Gutmann Message-ID: <20080414151222.GR8027@Sun.COM> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org On Tue, Apr 15, 2008 at 01:35:42AM +1200, Peter Gutmann wrote: > [...]. So a server, when seeing one of these certs, is supposed to go > to whatever arbitrary location and port is specified and poke around there > (I'm not sure what would happen if you entered, for example, an SSH URI > instead of the more obvious HTTP one, but if the implementation is general > enough you could use it for password-guessing attacks on internal SSH > servers). It's just a really, really bad idea to build a capability for HTTP > bounce scans into a (supposedly) passive protocol mechanism, and in particular > turning a system that's supposed to provide security into a security hole just > doesn't seem a winning long-term strategy to me. I agree. I think AIA can be useful -- to the client. Servers should ignore AIA, and clients should always send enough of their certificate chain to servers, and/or PKIX-based protocols should allow for additional round-trips when a client didn't send enough of its chain initially. I think that allowing for multiple round-trips here (e.g., in TLS) is the better answer, but I suspect that's also hard to pull off now, which leaves us with clients sending their whole chains (to some TA selected by the client, which hopefully will be good enough for the server to build its view of the client's cert validation path). Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Apr 14 11:00:03 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9042F3A6EDD; Mon, 14 Apr 2008 11:00:03 -0700 (PDT) X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 842233A6EB2; Mon, 14 Apr 2008 11:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080414180001.842233A6EB2@core3.amsl.com> Date: Mon, 14 Apr 2008 11:00:01 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-ecc-new-mac-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode Author(s) : E. Rescorla Filename : draft-ietf-tls-ecc-new-mac-05.txt Pages : 8 Date : 2008-04-14 RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes sixteen new CipherSuites for TLS/DTLS which specify stronger digest algorithms. Eight use HMAC with SHA-256 or SHA-384 and eight use AES in Galois Counter Mode (GCM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-new-mac-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-ecc-new-mac-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14104552.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Mon Apr 14 13:57:47 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54193A6933; Mon, 14 Apr 2008 13:57:47 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB5D3A6B23 for ; Mon, 14 Apr 2008 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.209 X-Spam-Level: ** X-Spam-Status: No, score=2.209 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKH5sVNrwABg for ; Mon, 14 Apr 2008 13:57:42 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id F21433A6991 for ; Mon, 14 Apr 2008 13:57:40 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA061906670; Mon, 14 Apr 2008 22:57:50 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA06571; Mon, 14 Apr 2008 22:57:48 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200804142057.WAA06571@TR-Sys.de> To: ekr@rtfm.com Date: Mon, 14 Apr 2008 22:57:48 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: tls@ietf.org Subject: [TLS] draft-ietf-tls-ecc-new-mac-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Hi all, I welcome the "compactification" / expansion of coverage of the spec's for ECC with TLS done in draft-ietf-tls-ecc-new-mac-05, but the middle paragraph of Section 2.1 has become rather arduous to read now, and the last "are" is improper and potentially misleading as well (should be "use"). Thus, please consider to change: OLD: These eight cipher suites are the same as the corresponding cipher | suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, and | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA) except for the hash and PRF | algorithms, which are SHA-256 and SHA-384 [SHS] as follows. ^^^ NEW: These eight cipher suites are the same as the corresponding cipher | suites in RFC 4492 (with names ending in "_SHA" in place of "_SHA256" | or "_SHA384"), except for the hash and PRF algorithms, which use SHA-256 and SHA-384 [SHS] as follows. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Apr 14 22:00:05 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2592128C36B; Mon, 14 Apr 2008 22:00:05 -0700 (PDT) X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 106DB28C34A; Mon, 14 Apr 2008 22:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080415050002.106DB28C34A@core3.amsl.com> Date: Mon, 14 Apr 2008 22:00:02 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-rsa-aes-gcm-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES-GCM Cipher Suites for TLS Author(s) : J. Salowey, et al. Filename : draft-ietf-tls-rsa-aes-gcm-03.txt Pages : 9 Date : 2008-04-14 This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSS and Diffie-Hellman based key exchange mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rsa-aes-gcm-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-rsa-aes-gcm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14215848.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Mon Apr 14 23:49:24 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083003A6A91; Mon, 14 Apr 2008 23:49:24 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012323A6B2F for ; Mon, 14 Apr 2008 23:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nTRotPrzFBd for ; Mon, 14 Apr 2008 23:49:20 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 7B64F3A6A27 for ; Mon, 14 Apr 2008 23:49:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3C3EB189D7; Tue, 15 Apr 2008 18:49:50 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7jxhQbAe3gv; Tue, 15 Apr 2008 18:49:50 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BCA35189BA; Tue, 15 Apr 2008 18:49:49 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3411D19EC0B9; Tue, 15 Apr 2008 18:49:47 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JlezD-0004w3-2I; Tue, 15 Apr 2008 18:49:47 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: mike-list@pobox.com, tls@ietf.org In-Reply-To: <48036F9A.1020900@pobox.com> Message-Id: Date: Tue, 15 Apr 2008 18:49:47 +1200 Subject: Re: [TLS] AIA cert fetching seen as harmful X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mike writes: >With the addition of URL constraints embedded in CA certificates, an attacker >would have to actively modify DNS packets or mess with routes or whatever to >launch an attack. This may be worth the effort though. Someone pointed out (off-list) something I hadn't thought about much, that internal servers are patched/updated a lot less often than web-facing ones (after all, they're behind the firewall so there's no need to risk breaking things with constant patching). So you could end up with a network full of older Red Hat machines that are out of subscription and no longer get updates, or masses of flaky internal-use-only web scripts and whatnot which are OK to use because they're beind the firewall (in fact has anyone who's ever worked at any sort of sizeable organisation *not* run into flaky hacked-together web scripts/apps for internal use only?). So your AIA contains a location of: http://192.168.1.1:8080/timesheet.asp?userid=1234;DROP%20TABLE%20USERS I'll bet there are a lot of people out there who'd be willing to poke with the DNS for a chance to do that to . We know, from years of experience, that it's hard enough to filter/whitelist/protect hardened web-facing servers, what AIA does is expose totally vulnerable, unpatched, poorly-written apps and internal servers to the same level of attack. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 15 14:37:03 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E149F3A68B1; Tue, 15 Apr 2008 14:37:03 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61CD3A69DC for ; Tue, 15 Apr 2008 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfNvxmBjOKFT for ; Tue, 15 Apr 2008 14:37:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA8F43A68B1 for ; Tue, 15 Apr 2008 14:37:01 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2008 14:37:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3FLbaiV012217 for ; Tue, 15 Apr 2008 14:37:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3FLbZvw013526 for ; Tue, 15 Apr 2008 21:37:36 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 14:37:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 14:38:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-ietf-tls-rsa-aes-gcm and draft-ietf-tls-ecc-new-mac Thread-Index: AcifQQlKif7nykJkSV6RmCc9KDW3IA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Apr 2008 21:37:35.0862 (UTC) FILETIME=[EB8C4160:01C89F40] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=862; t=1208295456; x=1209159456; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20New=20version=20of=20draft-ietf-tls-rsa-aes-gcm =20and=20draft-ietf-tls-ecc-new-mac |Sender:=20; bh=x5vusNn7nlm4g6KeYBXiwBiDrdgvPvxiQaZ8jlYjcIM=; b=UUkj0isZ+xQDdjxOuAuvw8diheslGRPx6dtKh501HyHEriND1kCUY5HGZl k4SK9SCfguJ4uXMP40l0YoYgiGnmrSva/FKyXioBpJjEUSHQjV39yJHipwJm 4XU2qhogAXu3Lx8Q5B9BEjYkMUF8AkmhhY8RWtRHHNdoI1jIswSYg=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [TLS] New version of draft-ietf-tls-rsa-aes-gcm and draft-ietf-tls-ecc-new-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org I posted draft-ietf-tls-rsa-aes-gcm-03 last night, I think it address the issues raised in WG last call. Here is a summary of resolutions and changes: + Added text to mandate use of bad_record_mac alert in case of AES-GCM failure (Issue 91) + Removed references to DTLS - Cipher suites will be discussed in DTLS update + Editorial changes - cleaned up introduction - align terminology with TLS 1.2 - fixed up references Eric also posted a revision to draft-ietf-tls-ecc-new-mac, here are the major changes I know of (Eric can send an update if there are others): + Document now points to draft-ietf-tls-rsa-aes-gcm for AES GCM details and security considerations + ECDH-RSA and ECDHE-RSA cipher suites added (Issue 93) Please take a final look at the documents before they go on to AD evaluations. Thanks, Joe _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 24 11:08:59 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A863A6B87; Thu, 24 Apr 2008 11:08:59 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47DE3A67A7 for ; Thu, 24 Apr 2008 10:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KZ1PfvfVC0c for ; Thu, 24 Apr 2008 10:49:59 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 3060B3A6BD4 for ; Thu, 24 Apr 2008 10:49:59 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so164290ywb.49 for ; Thu, 24 Apr 2008 10:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=WEZjexq11uRkYjbUyzZ2s/zJtU7ufW3U08UTs9grrcI=; b=NS3VQjp9SkhzDvdmKGI0V3zrWNCAlJOFnf/j7+ryou15FKbVsKBAxRxyXzVobL93WQP29S3n3zzMkEb8PZqxTapYd/bzKZO5SoQpiiY8MG5s4jD491osej51YxX3Grr9Jucl6CZAKRLYsJkb0pCHWfGZg+414F/HKp921FfpC74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=EK/1dXszCiTIXCctHLPglk4nKC2LScYDsf0BqGbtp9PWL/5AS4Z0bgNAl+Bcr95l+ZXJoHjq177rhmm257KFNtGzjx65lC6tWAObNKwlujg8a42SVM66AgpDtThmcbyf59BDiBwGJyunIf4Ta09bwH0BhpwuAS99pcvvw9UxAjE= Received: by 10.150.72.11 with SMTP id u11mr244832yba.116.1209059403683; Thu, 24 Apr 2008 10:50:03 -0700 (PDT) Received: by 10.70.117.6 with HTTP; Thu, 24 Apr 2008 10:50:03 -0700 (PDT) Message-ID: <49f8fec0804241050m66faec42h745dc95078563424@mail.gmail.com> Date: Thu, 24 Apr 2008 23:20:03 +0530 From: "pra$h Online!!!! !!" To: tls@ietf.org In-Reply-To: <49f8fec0804240526p10e7b432y21fd46be7a2d76d6@mail.gmail.com> MIME-Version: 1.0 References: <49f8fec0804240526p10e7b432y21fd46be7a2d76d6@mail.gmail.com> X-Mailman-Approved-At: Thu, 24 Apr 2008 11:08:58 -0700 Subject: [TLS] Reject=403 4.7.0 encryption too weak 0 less than 128 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0800696341==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org --===============0800696341== Content-Type: multipart/alternative; boundary="----=_Part_776_7198481.1209059403696" ------=_Part_776_7198481.1209059403696 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Please any body Help me on This. I am using send mail Version 8.13.6+Sun and implemented TLS with our client ( version=TLSv1/SSLv3 ) The mail from our domain is receiving to the client we are not receiving the mails from client. When i checked in my send mail i found the logs "Reject=403 4.7.0 encryption too weak 0 less than 128".There was no changes done both sides. We are not facing the problem with any other client . Acces file Configuration Below. TLS_Clt:domain.com ENCR:128 TLS_Rcpt: domain.com VERIFY:128+CN Thanks and Regards Prashanth.P Nair ------=_Part_776_7198481.1209059403696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi

Please any body Help me on This.

 

I am using send mail Version 8.13.6+Sun and implemented  TLS with our client ( version=TLSv1/SSLv3 )

The mail from our domain is receiving to the client we are not receiving the mails from client.

When i checked in my send mail i found the logs "Reject=403 4.7.0 encryption too weak 0 less than 128".There was no changes done both sides.

 

We are not facing the problem with any other client .

 

Acces file Configuration Below.

TLS_Clt:domain.com     ENCR:128

TLS_Rcpt: domain.com     VERIFY:128+CN

 

 

Thanks and Regards

Prashanth.P Nair

------=_Part_776_7198481.1209059403696-- --===============0800696341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============0800696341==-- From tls-bounces@ietf.org Thu Apr 24 11:42:38 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67DBE3A67F1; Thu, 24 Apr 2008 11:42:38 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDDE28C11D for ; Thu, 24 Apr 2008 11:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.251 X-Spam-Level: * X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdqUtWwt3-EL for ; Thu, 24 Apr 2008 11:42:36 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id F03DA3A67A7 for ; Thu, 24 Apr 2008 11:42:34 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA119332530; Thu, 24 Apr 2008 20:42:10 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA28493; Thu, 24 Apr 2008 20:42:07 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200804241842.UAA28493@TR-Sys.de> To: yaronf@checkpoint.com, Hannes.Tschofenig@siemens.com, ynir@checkpoint.com, pgut001@cs.auckland.ac.nz Date: Thu, 24 Apr 2008 20:42:07 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: tls@ietf.org Subject: [TLS] draft-nir-tls-eap-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org SGVsbG8sCkkgd291bGQgbGlrZSB0byBzdWJtaXQgYSBmZXcgY29tbWVudHMgb24geW91ciBJbnRl cm5ldC1EcmFmdCwKZHJhZnQtbmlyLXRscy1lYXAtMDMuCgooMSkgIFNlY3Rpb24gMQoKU2VjdGlv biAxIElNSE8gaXMgdG9vIHNpbGVudCBhYm91dCB0aGUgYmVuZWZpdHMgb2J0YWluZWQgZnJvbQp0 aGlzIHByb3Bvc2FsLgoKQXJndWFibHksIHRoZXJlJ3MgdG9vIG11Y2ggc3R1ZmYgaW4gdGhlIEFi c3RyYWN0IHRoYXQgYXQgbGVhc3QKc2hvdWxkIGJlIHJlc3RhdGVkIG9yIGVsYWJvcmF0ZWQgdXBv biBlYXJseSBpbiBTZWN0aW9uIDEsIGUuZy4sCm5lYXIgdGhlIGVuZCBvZiB0aGUgc2Vjb25kIHBh cmFncmFwaCB0aGVyZS4KCigyKSAgU2VjdGlvbiAyCgpUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBT ZWN0aW9uIDIgc2F5czoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsuLi5d LiAgVHlwaWNhbGx5IHRoZSBBQUEgc2VydmVyCiAgIGNvbW11bmljYXRlcyB1c2luZyB0aGUgUkFE SVVTIHByb3RvY29sIHdpdGggRUFQIChbUkFESVVTXSBhbmQKICAgW1JBRC1FQVBdKSwgb3IgdGhl IERpYW1ldGVyIHByb3RvY29sIChbRGlhbWV0ZXJdIGFuZCBbRGlhLUVBUF0pLgoKSXQgc2hvdWxk IGJldHRlciBzYXk6CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbLi4uXS4g IFR5cGljYWxseSB0aGUgQUFBIHNlcnZlcgp8ICBjb21tdW5pY2F0ZXMgdXNpbmcgdGhlIFJBRElV UyBwcm90b2NvbCB3aXRoIEVBUCBleHRlbnNpb25zIChbUkFESVVTXQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXgogICBhbmQgW1JB RC1FQVBdKSwgb3IgdGhlIERpYW1ldGVyIHByb3RvY29sIChbRGlhbWV0ZXJdIGFuZCBbRGlhLUVB UF0pLgoKKDMpICBTZWN0aW9uIDMuMQoKVGhlIFRMUyBleHRlbnNpb24gZnJhbWV3b3JrIG5vdyBp cyBwYXJ0IG9mIHJmYzQzNDZiaXMgKGFscmVhZHkKYmVpbmcgb3BlcmF0ZWQgdXBvbiBieSB0aGUg UkZDIEVkaXRvciksIHdoZXJlYXMgNDM2NmJpcyBvbmx5CnNwZWNpZmllcyBhIGZldyB1c2VmdWwg VExTIEV4dGVuc2lvbnMgdXNpbmcgdGhpcyBmcmFtZXdvcmsuCgpXaGVuIGl0IGNvbWVzIHRvIHVw ZGF0aW5nIHRoZSByZWZlcmVuY2VzLCB0aGlzIG1ha2VzIHRoaW5ncyBhIGJpdApjb21wbGljYXRl ZC4gIFBlcmhhcHMgdGhlIGRyYWZ0IHNob3VsZCBjbGVhcmx5IGRpc3Rpbmd1aXNoIFRMUyAxLjEK YW5kIFRMUyAxLjIgLS0gb3IgaXQgc2hvdWxkIHJlc3RyaWN0IGl0cyBzY29wZSB0byBUTFMgMS4y LgoKKDQpICBTZWN0aW9uIDMuNAoKVGhlIGFzc2lnbm1lbnQgb3BlcmF0b3IgaXMgbWlzc2luZyBp biB0aGUgZm9ybXVsYSBmb3IgYHZlcmlmeV9kYXRhYDsKaXQgc2hvdWxkIGJlOgoKICAgICB2ZXJp ZnlfZGF0YSA9IFBSRiAoTVNLLCAuLi4pIFswLi4xMV0gOwogICAgICAgICAgICAgICAgIF4KClRo ZSBzZWNvbmQtdG8tbmV4dCBwYXJhZ3JhcGggYXBwYXJlbnRseSBhbHNvIHNob3VsZCByZWZlciB0 byB0aGlzCmZpZWxkOgogICAgICAgdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2CnwgIFRoZSBoYW5kc2hha2Vf bWVzc2FnZXMgZmllbGQsIHVubGlrZSByZWd1bGFyIFRMUywgZG9lcyBub3Qgc2lnbiBhbGwKICAg dGhlIGRhdGEgaW4gdGhlIGhhbmRzaGFrZS4gIFsuLi5dCi0tLSAgICB2dnZ2dnZ2dnZ2dgp8ICBU aGUgdmVyaWZ5X2RhdGEgZmllbGQsIHVubGlrZSByZWd1bGFyIFRMUywgZG9lcyBub3Qgc2lnbiBh bGwgdGhlIGRhdGEKICAgaW4gdGhlIGhhbmRzaGFrZS4gIFsuLi5dCgpBbHNvLCBhdCB0aGUgZW5k IG9mIHRoYXQgcGFyYWdyYXBoLCAgICBzL1tUTFNdYW5kL1tUTFNdIGFuZC8gIC4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4KKDUpICAgU2Vj dGlvbiA0LjMsIGFsdGVybmF0aXZlIDIuCgpEb2Vzbid0IHRoaXMgdmFyaWFudCBzdWZmZXIgZnJv bSBhIE1JVE0gdnVsbmVyYWJpbGl0eT8KVGhpcyB3b3VsZCB0b3RhbGx5IGludmFsaWRhdGUgdGhl IG1vc3Qgc2lnbmlmaWNhbnQgY29udHJpYnV0aW9uCm9mIHRoaXMgcHJvcG9zYWwsIElEIHByb3Rl Y3Rpb24gIQpJZiBJIGRvIG5vdCBlcnIgdy5yLnQuIHRoaXMgdGhyZWF0LCB0aGUgZHJhZnQgc2hv dWxkIGZ1cnRoZXIKZWxhYm9yYXRlIG9uIHRoaXMgaXNzdWUuCgoKKDYpICBTZWN0aW9uIDEwCgoo NmEpICBzL3Jldmlld3JzL3Jldmlld2Vycy8gICAgICgyeCkKCig2YikgIFJlICJGaW5pc2hlZCIg LyAiRWFwRmluaXNoZWQiIC8gIkludGVyaW1BdXRoIgogCkEgcG9zc2libGUgYWx0ZXJuYXRpdmUg d291bGQgaGF2ZSBiZWVuIHRvIGFtZW5kIHRoZSBGaW5pc2hlZAptZXNzYWdlIGZvcm1hdCB3aXRo IGFuIG9wdGlvbmFsIGZpZWxkIGluZGljYXRpbmcgdGhlIG5hdHVyZSAvCnNlbWFudGljcyBvZiB0 aGUgcGFydGljdWxhciBpbnN0YW5jZSBvZiB0aGUgbWVzc2FnZSwgYW5kCmZvcm1hbGx5IHVzZSB0 aGUgc2FtZSBoYW5kc2hha2UgbWVzc2FnZSBmb3IgYm90aCBwdXJwb3Nlcwooc3ViamVjdCB0byBz dWNjZXNzZnVsIG5lZ290aWF0aW9uIG9mIHRlZV9zdXBwb3J0ZWQpLApidXQgdGhpcyB2YXJpYW50 IHdvdWxkIHBlcmhhcHMgaGF2ZSBiZWVuIG1vcmUgY29tcGxpY2F0ZWQKdG8gc3BlY2lmeSB3aXRo aW4gdGhlIGV4dGVuc2liaWxpdHkgcnVsZXMgb2YgVExTOyBzaW5jZQp0aGVyZSdzIG5vIGRhbmdl ciBvZiBuYW1lc3BhY2UgZXhoYXVzdGlvbiBmb3IgaGFuZHNoYWtlCm1lc3NhZ2UgdHlwZXMsIHRo ZSBzZWxlY3RlZCBkZXNpZ24gc2VlbXMgdG8gYmUgcmVhc29uYWJsZS4KCig2YykgIFJlIEVBUCBl eHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwKCkRvbid0IG1ha2UgdGhpbmdzIG92ZXJseSBjb21wbGlj YXRlZC4KClRoZSBzdWJqZWN0IG9mIHRoZSBleHRlbnNpb24gaXMgVExTIGNsaWVudCBhdXRoZW50 aWNhdGlvbi4KSGVuY2UsIHRoZSBleHBlY3RlZCBvdXRwdXQgaXMgQm9vbGVhbiAtLSBvayB0byBw cm9jZWVkLCBvcgphYm9ydCB0aGUgVExTIGhhbmRzaGFrZS4KCig2ZCkgIFJlIGlkZW50aXR5IHBy b3RlY3Rpb24KClRoYXQncyBhIGZlYXR1cmUgdGhhdCB3aWxsIGJlY29tZSBldmVuIG1vcmUgaW1w b3J0YW50IGluIHRoZQpmdXR1cmUuICAgVGhlcmUgYXJlIGFscmVhZHkgc28gbWFueSBsZWFrcyBm b3IgaW5mb3JtYXRpb24KcGFzc2VkIGFyb3VuZCBpbiB0aGUgaW50ZXJuZXQsIGFuZCBpbmZvcm1h dGlvbiBwcml2YWN5IGlzCm9uZSBvZiB0aGUgbW9zdCB2YWx1YWJsZSBhc3NldHMgd2UgaGF2ZSwg dGhhdCBpZGVudGl0eQpwcm90ZWN0aW9uIHdpbGwgYmUgbmVjZXNzYXJ5IG1vcmUgYW5kIG1vcmUs IGFuZCBpdCdzIHdlbGwKd29ydGggYSBzaW5nbGUgYWRkaXRpb25hbCByb3VuZC10cmlwIQoKCktp bmQgcmVnYXJkcywKICBBbGZyZWQgSM5uZXMuCgotLSAKCistLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnwgVFItU3lz IEFsZnJlZCBIb2VuZXMgICB8ICBBbGZyZWQgSG9lbmVzICAgRGlwbC4tTWF0aC4sIERpcGwuLVBo eXMuICB8CnwgR2VybGluZ2VyIFN0cmFzc2UgMTIgICB8ICBQaG9uZTogKCs0OSk3MTU2Lzk2MzUt MCwgRmF4OiAtMTggICAgICAgICB8CnwgRC03MTI1NCAgRGl0emluZ2VuICAgICB8ICBFLU1haWw6 ICBhaEBUUi1TeXMuZGUgICAgICAgICAgICAgICAgICAgICB8CistLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUTFMgbWFpbGluZyBs aXN0ClRMU0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs cwo= From tls-bounces@ietf.org Fri Apr 25 22:02:13 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1273A6D06; Fri, 25 Apr 2008 22:02:13 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22EB3A6D06 for ; Fri, 25 Apr 2008 22:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuZ7xrLvyFFM for ; Fri, 25 Apr 2008 22:02:11 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id D477E3A6BCA for ; Fri, 25 Apr 2008 22:02:10 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 863E233C7 for ; Sat, 26 Apr 2008 01:02:14 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 3127A33C1 for ; Sat, 26 Apr 2008 01:02:14 -0400 (EDT) Message-ID: <4812B7CD.8020500@pobox.com> Date: Fri, 25 Apr 2008 22:04:13 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org Subject: [TLS] SSL and SHA-256 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org I realize that this list doesn't really care about SSLv3, but I'm adding the SHA-256 cipher suites to my code and since I also support SSL, I'd prefer to have them work with that as well. The only problem I see is that there is no definition for pad1 or pad2 for the MAC calculation. The original design was to have the pad stretch the MAC secret to 64 bytes, so extending this to SHA-256 would mean that the two pads would need to be 32 bytes of 0x36 and 0x5C respectively. Am I missing something, or is that all that would be necessary to support these new cipher suites in SSLv3? Is anyone else planning to add them to their SSL code? Thanks, Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 05:19:03 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D173A6C8A; Tue, 29 Apr 2008 05:19:03 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF183A6C8A for ; Tue, 29 Apr 2008 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWoLnI3o8KiK for ; Tue, 29 Apr 2008 05:19:00 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9AD133A6B0B for ; Tue, 29 Apr 2008 05:18:59 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3TCIijE004706 for ; Tue, 29 Apr 2008 15:18:59 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 15:18:34 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 15:18:34 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 15:18:31 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS document status update Thread-index: Acip8yNt6L5VvsL/RjS9hbtVA/Vq4A== From: To: X-OriginalArrivalTime: 29 Apr 2008 12:18:34.0292 (UTC) FILETIME=[24FF5740:01C8A9F3] X-Nokia-AV: Clean Subject: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Here's a short status update on TLS WG documents: draft-ietf-tls-rfc4346-bis This is in RFC Editor final AUTH48 stage, so it should be out as RFC 5246 soon. draft-ietf-tls-rsa-aes-gcm: The draft went through WGLC, and Joe posted version -03 which seems to address the WGLC comments. Unless there are objections, this will be sent to AD evaluation once the chairs get the Document Shepherd Write-Up written. draft-ietf-tls-ecc-new-mac The draft also went through WGLC; version -05 seems to address the WGLC comments, but has some editorial nits. Once Eric submits version -06, this will be sent to AD evaluation. draft-ietf-tls-rfc4366-bis The only technical issue is whether (and how) to mandate including the hash in certificate_url message. Everyone except Nelson has supported making the hash mandatory. If I understand Nelson's view correctly, he considers the original use case for omitting the hash (CA automatically posts renewed certificates at certain URL, and the client does not necessarily have a copy of the latest cert) more important than the (rather theoretical) attacks that omitting the hash might have. Nelson, would this be a fair summary of your objection? draft-ietf-tls-extractor The draft is basically ready for WGLC -- hopefully starts soon. draft-ietf-tls-des-idea The draft is basically ready for WGLC, but has been waiting until the other documents progress. draft-ietf-tls-ecdhe-psk The draft is basically ready for WGLC, but has been waiting until the other documents progress. Best regards, Pasi _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 06:20:06 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C16F3A6782; Tue, 29 Apr 2008 06:20:06 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74513A6D7A for ; Tue, 29 Apr 2008 06:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Y7oaPkIthc for ; Tue, 29 Apr 2008 06:20:03 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id BB8CE3A6782 for ; Tue, 29 Apr 2008 06:20:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B76B929400E; Tue, 29 Apr 2008 16:20:04 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DF806294011; Tue, 29 Apr 2008 16:19:59 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m3TDJxfX025659; Tue, 29 Apr 2008 16:19:59 +0300 (IDT) Message-Id: <07041089-61BC-4102-8061-100E7D1BC69D@checkpoint.com> From: Yoav Nir To: =?ISO-8859-1?Q?Alfred_H=CEnes?= , tls mailing list In-Reply-To: <200804241842.UAA28493@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 29 Apr 2008 16:19:51 +0300 References: <200804241842.UAA28493@TR-Sys.de> X-Mailer: Apple Mail (2.919.2) Cc: Hannes Tschofenig , Yaron Sheffer Subject: Re: [TLS] draft-nir-tls-eap-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Hello, Thank you for reviewing our draft and for your helpful comments. With regard to section 1 and the abstract, I agree that the abstract = is too long and a lot of the stuff that's in the abstract would be = more appropriate in section 1. We will rewrite them along those lines = in the next iteration. Regarding section 3, we will make the distinction in the text between = TLS 1.1 and 1.2. We certainly do not wish to restrict our draft to TLS = 1.2. Regarding section 4.2 (comment (5)) I also believe that identity = protection is important, but that belief is not universally shared. = For example, the TLS-PSK protocol does not provide it. I'm not sure = what I can do to elaborate more on this, except to say (as we have) = that "we believe that identity protection is a worthy enough goal, so = as to justify the extra round-trip.". Can you suggest anything = stronger? In comment (6) you seem to agree with the choices we have made so = far. We will also of course fix the typos that you have pointed out. Thanks again for taking the time to review our draft. Yoav On Apr 24, 2008, at 9:42 PM, Alfred H=CEnes wrote: > Hello, > I would like to submit a few comments on your Internet-Draft, > draft-nir-tls-eap-03. > > (1) Section 1 > > Section 1 IMHO is too silent about the benefits obtained from > this proposal. > > Arguably, there's too much stuff in the Abstract that at least > should be restated or elaborated upon early in Section 1, e.g., > near the end of the second paragraph there. > > (2) Section 2 > > The second paragraph of Section 2 says: > > [...]. Typically the AAA server > communicates using the RADIUS protocol with EAP ([RADIUS] and > [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). > > It should better say: > > [...]. Typically the AAA server > | communicates using the RADIUS protocol with EAP extensions = > ([RADIUS] > ^^^^^^^^^^^ > and [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). > > (3) Section 3.1 > > The TLS extension framework now is part of rfc4346bis (already > being operated upon by the RFC Editor), whereas 4366bis only > specifies a few useful TLS Extensions using this framework. > > When it comes to updating the references, this makes things a bit > complicated. Perhaps the draft should clearly distinguish TLS 1.1 > and TLS 1.2 -- or it should restrict its scope to TLS 1.2. > > (4) Section 3.4 > > The assignment operator is missing in the formula for `verify_data`; > it should be: > > verify_data =3D PRF (MSK, ...) [0..11] ; > ^ > > The second-to-next paragraph apparently also should refer to this > field: > vvvvvvvvvvvvvvvvvv > | The handshake_messages field, unlike regular TLS, does not sign all > the data in the handshake. [...] > --- vvvvvvvvvvv > | The verify_data field, unlike regular TLS, does not sign all the = > data > in the handshake. [...] > > Also, at the end of that paragraph, s/[TLS]and/[TLS] and/ . > ^ > (5) Section 4.3, alternative 2. > > Doesn't this variant suffer from a MITM vulnerability? > This would totally invalidate the most significant contribution > of this proposal, ID protection ! > If I do not err w.r.t. this threat, the draft should further > elaborate on this issue. > > > (6) Section 10 > > (6a) s/reviewrs/reviewers/ (2x) > > (6b) Re "Finished" / "EapFinished" / "InterimAuth" > > A possible alternative would have been to amend the Finished > message format with an optional field indicating the nature / > semantics of the particular instance of the message, and > formally use the same handshake message for both purposes > (subject to successful negotiation of tee_supported), > but this variant would perhaps have been more complicated > to specify within the extensibility rules of TLS; since > there's no danger of namespace exhaustion for handshake > message types, the selected design seems to be reasonable. > > (6c) Re EAP exported keying material > > Don't make things overly complicated. > > The subject of the extension is TLS client authentication. > Hence, the expected output is Boolean -- ok to proceed, or > abort the TLS handshake. > > (6d) Re identity protection > > That's a feature that will become even more important in the > future. There are already so many leaks for information > passed around in the internet, and information privacy is > one of the most valuable assets we have, that identity > protection will be necessary more and more, and it's well > worth a single additional round-trip! > > > Kind regards, > Alfred H=CEnes. > > -- = > > +------------------------ = > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- = > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: = > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR- = > Sys.de | > +------------------------ = > +--------------------------------------------+ > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 08:14:16 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC2F28C277; Tue, 29 Apr 2008 08:14:16 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D70A3A69D1 for ; Tue, 29 Apr 2008 08:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilxrBn8DlAFU for ; Tue, 29 Apr 2008 08:14:12 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by core3.amsl.com (Postfix) with ESMTP id CFF423A6920 for ; Tue, 29 Apr 2008 08:14:12 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 9A449CC3DA for ; Tue, 29 Apr 2008 15:14:15 +0000 (UTC) X-SpamScore: 1 Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by omf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Apr 2008 15:14:15 +0000 (UTC) Message-ID: <48173B41.5000401@bolyard.com> Date: Tue, 29 Apr 2008 08:14:09 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b3pre) Gecko/2008020302 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: tls@ietf.org References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> X-Spam-Summary: 2, 0, 0, 17e31afe4bd6398f, c1f0be6ca7734e96, nelson@bolyard.com, , RULES_HIT:152:355:379:599:601:800:973:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1676:1711:1730:1747:1766:1792:2393:2552:2559:2562:2692:2895:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4321:4362:5007:6119:6120:7652, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-session-marker: 6E656C736F6E40626F6C796172642E636F6D Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Pasi.Eronen@nokia.com wrote, On 2008-04-29 05:18: > Here's a short status update on TLS WG documents: > draft-ietf-tls-rfc4366-bis > > The only technical issue is whether (and how) to mandate > including the hash in certificate_url message. Everyone except > Nelson has supported making the hash mandatory. > > If I understand Nelson's view correctly, he considers the > original use case for omitting the hash (CA automatically posts > renewed certificates at certain URL, and the client does not > necessarily have a copy of the latest cert) more important than > the (rather theoretical) attacks that omitting the hash might > have. Nelson, would this be a fair summary of your objection? Yes. The client doesn't necessarily have ANY copy of its own cert. The proposed requirement that the client MUST include a hash of the cert it does not have presents a new problem for such implementations. White-listing of hosts from which the server is willing to fetch those client cert URLs effectively solves the other problems without necessitating any mandatory hashes. Thanks for your document status summary. /Nelson _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 08:22:54 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BB93A6920; Tue, 29 Apr 2008 08:22:54 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B153F3A6992 for ; Tue, 29 Apr 2008 08:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzi04H9FOHhr for ; Tue, 29 Apr 2008 08:22:44 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 024483A685D for ; Tue, 29 Apr 2008 08:22:44 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B25AD5081A; Tue, 29 Apr 2008 08:26:18 -0700 (PDT) Date: Tue, 29 Apr 2008 08:26:18 -0700 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <48173B41.5000401@bolyard.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080429152618.B25AD5081A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Tue, 29 Apr 2008 08:14:09 -0700, Nelson B Bolyard wrote: > > Pasi.Eronen@nokia.com wrote, On 2008-04-29 05:18: > > Here's a short status update on TLS WG documents: > > > draft-ietf-tls-rfc4366-bis > > > > The only technical issue is whether (and how) to mandate > > including the hash in certificate_url message. Everyone except > > Nelson has supported making the hash mandatory. > > > > If I understand Nelson's view correctly, he considers the > > original use case for omitting the hash (CA automatically posts > > renewed certificates at certain URL, and the client does not > > necessarily have a copy of the latest cert) more important than > > the (rather theoretical) attacks that omitting the hash might > > have. Nelson, would this be a fair summary of your objection? > > Yes. The client doesn't necessarily have ANY copy of its own cert. > The proposed requirement that the client MUST include a hash of the > cert it does not have presents a new problem for such implementations. Given that the client is about to ask the server to download a copy, I don't really see why there's a problem with the client getting a copy first and sending the hash over. > White-listing of hosts from which the server is willing to fetch those > client cert URLs effectively solves the other problems without > necessitating any mandatory hashes. No, it doen't solve the substitution attack. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 09:15:02 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632AD3A6DD4; Tue, 29 Apr 2008 09:15:02 -0700 (PDT) X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A40A83A6DE0; Tue, 29 Apr 2008 09:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080429161501.A40A83A6DE0@core3.amsl.com> Date: Tue, 29 Apr 2008 09:15:01 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-ecc-new-mac-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode Author(s) : E. Rescorla Filename : draft-ietf-tls-ecc-new-mac-06.txt Pages : 7 Date : 2008-04-29 RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes sixteen new CipherSuites for TLS/DTLS which specify stronger digest algorithms. Eight use HMAC with SHA-256 or SHA-384 and eight use AES in Galois Counter Mode (GCM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-new-mac-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-ecc-new-mac-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-29090756.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Tue Apr 29 09:22:44 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161A83A6E4C; Tue, 29 Apr 2008 09:22:44 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1622A28C347 for ; Tue, 29 Apr 2008 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CV7gqpU0yua for ; Tue, 29 Apr 2008 09:22:39 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 1B7FE3A68ED for ; Tue, 29 Apr 2008 09:22:38 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 3F24B353F for ; Tue, 29 Apr 2008 12:22:40 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id D47FB353E for ; Tue, 29 Apr 2008 12:22:37 -0400 (EDT) Message-ID: <48174BB8.7080009@pobox.com> Date: Tue, 29 Apr 2008 09:24:24 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> In-Reply-To: <20080429152618.B25AD5081A@romeo.rtfm.com> X-Pobox-Relay-ID: 7CED645C-1608-11DD-8FDB-80001473D85F-38729857!a-sasl-fastnet.pobox.com Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >>> draft-ietf-tls-rfc4366-bis >>> >>> The only technical issue is whether (and how) to mandate >>> including the hash in certificate_url message. Everyone except >>> Nelson has supported making the hash mandatory. >> >> The client doesn't necessarily have ANY copy of its own cert. >> The proposed requirement that the client MUST include a hash of the >> cert it does not have presents a new problem for such implementations. > > Given that the client is about to ask the server to download a copy, > I don't really see why there's a problem with the client getting > a copy first and sending the hash over. There is the problem of the client knowing when its certificate is updated and that it should retrieve a new copy to recalculate the hash. It could keep track of its own validity period, but that complicates things, and wouldn't work if the CA decides to reissue a certificate early. >> White-listing of hosts from which the server is willing to fetch those >> client cert URLs effectively solves the other problems without >> necessitating any mandatory hashes. > > No, it doen't solve the substitution attack. But how could the substitution attack even succeed? You would need to create a valid CA signature on the replacement certificate, which should not be possible. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 13:12:07 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FB43A6B18; Tue, 29 Apr 2008 13:12:07 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA52A3A6B18 for ; Tue, 29 Apr 2008 13:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL2Ywqh-7qOr for ; Tue, 29 Apr 2008 13:11:56 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id E72753A6B27 for ; Tue, 29 Apr 2008 13:11:55 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so115985fgg.41 for ; Tue, 29 Apr 2008 13:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:sender; bh=9JNGPhGW3PUm50ol+2EH044kguOkSkd8awSBkUQefPE=; b=D7y4pidOrgHkDJ7qZHgt7KxE/OWh+MxL0fbX+XeDBpjEZPh+bx/te+Df9noq43aWF3C0kixo6wrj358JyUVE+/eRnftDyJPyEZMAt4vTk88mb6ciPV2u1EOh4Y+OxXgGLJWdDDc9mWqk64pB6Rxj26LVKAX808EeFcvhQ7CpYmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:sender; b=lUdRdxiR2kiuV9ro+TTZZnQY8V1jd+VdjVNvsBsE2OwRg9mkV/YeegJR4IAQCTHv2qw3D8DGHMYnSZyhkaP88LUgXkKD8PQifkOcXhckb60IV5juEaHKhAPX8Ky5TG08qaJIpEK3ROaw2Hg4WXu83iD2oN0/J/OBJKc5sdf1BK0= Received: by 10.86.92.7 with SMTP id p7mr252559fgb.32.1209499917999; Tue, 29 Apr 2008 13:11:57 -0700 (PDT) Received: from ?10.100.1.196? ( [212.54.193.90]) by mx.google.com with ESMTPS id e32sm48064fke.18.2008.04.29.13.11.56 (version=SSLv3 cipher=RC4-MD5); Tue, 29 Apr 2008 13:11:57 -0700 (PDT) Message-ID: <4817810B.6010104@gnutls.org> Date: Tue, 29 Apr 2008 23:11:55 +0300 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Mike References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> In-Reply-To: <48174BB8.7080009@pobox.com> X-Enigmail-Version: 0.95.0 Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mike wrote: >>> White-listing of hosts from which the server is willing to fetch those >>> client cert URLs effectively solves the other problems without >>> necessitating any mandatory hashes. >> No, it doen't solve the substitution attack. > > But how could the substitution attack even succeed? You would need > to create a valid CA signature on the replacement certificate, which > should not be possible. The fact that you cannot present an attack doesn't mean there is no attack, or that a combination of such weaknesses might be exploitable. The TLS handshake finished message hashes protect the certificate by including it. If the certificate is not exchanged during the handshake then this protection is no longer available. So: 1. If this protection is not really required, then it can also be removed it from the original TLS handshake. 2. If this protection is required, then it should be present in the abbreviated handshake with the certificate URL (in the form of certificate hash), so equivalent security is offered by equivalent ciphersuites. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 13:17:08 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04613A6B52; Tue, 29 Apr 2008 13:17:08 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687023A6B52 for ; Tue, 29 Apr 2008 13:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abnlxi-HXkt7 for ; Tue, 29 Apr 2008 13:17:07 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B292C3A6A47 for ; Tue, 29 Apr 2008 13:17:07 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3E54E5081A; Tue, 29 Apr 2008 13:20:42 -0700 (PDT) Date: Tue, 29 Apr 2008 13:20:41 -0700 From: Eric Rescorla To: Mike In-Reply-To: <48174BB8.7080009@pobox.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080429202042.3E54E5081A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Tue, 29 Apr 2008 09:24:24 -0700, Mike wrote: > > >>> draft-ietf-tls-rfc4366-bis > >>> > >>> The only technical issue is whether (and how) to mandate > >>> including the hash in certificate_url message. Everyone except > >>> Nelson has supported making the hash mandatory. > >> > >> The client doesn't necessarily have ANY copy of its own cert. > >> The proposed requirement that the client MUST include a hash of the > >> cert it does not have presents a new problem for such implementations. > > > > Given that the client is about to ask the server to download a copy, > > I don't really see why there's a problem with the client getting > > a copy first and sending the hash over. > > There is the problem of the client knowing when its certificate is > updated and that it should retrieve a new copy to recalculate the > hash. It could keep track of its own validity period, but that > complicates things, and wouldn't work if the CA decides to reissue > a certificate early. Polling occasionally hardly seems like an insuperable barrier. > >> White-listing of hosts from which the server is willing to fetch those > >> client cert URLs effectively solves the other problems without > >> necessitating any mandatory hashes. > > > > No, it doen't solve the substitution attack. > > But how could the substitution attack even succeed? You would need > to create a valid CA signature on the replacement certificate, which > should not be possible. Why not? All you need is a CA which doesn't require technical Proof of Possession of the private key. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 13:40:18 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E7B28C346; Tue, 29 Apr 2008 13:40:18 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92B528C34A for ; Tue, 29 Apr 2008 13:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFCZyKhoIVjh for ; Tue, 29 Apr 2008 13:40:17 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 2248628C346 for ; Tue, 29 Apr 2008 13:40:16 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 30ADE3243 for ; Tue, 29 Apr 2008 16:40:19 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id D85593242 for ; Tue, 29 Apr 2008 16:40:18 -0400 (EDT) Message-ID: <4817881D.9080605@pobox.com> Date: Tue, 29 Apr 2008 13:42:05 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> In-Reply-To: <20080429202042.3E54E5081A@romeo.rtfm.com> X-Pobox-Relay-ID: 7B2C8AB6-162C-11DD-9CF7-80001473D85F-38729857!a-sasl-fastnet.pobox.com Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >> But how could the substitution attack even succeed? You would need >> to create a valid CA signature on the replacement certificate, which >> should not be possible. > > Why not? All you need is a CA which doesn't require technical > Proof of Possession of the private key. If you can't trust your own CA, then by all means send the hash. The discussion is about whether a client MUST send the hash. So far it seems like SHOULD is the most appropriate, with relevant comments in Security Considerations. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 14:03:19 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEDD3A6BDE; Tue, 29 Apr 2008 14:03:19 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECE43A6BDE for ; Tue, 29 Apr 2008 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQDemEpPKfOd for ; Tue, 29 Apr 2008 14:03:14 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 28F713A68DB for ; Tue, 29 Apr 2008 14:03:14 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id F2F075081A; Tue, 29 Apr 2008 14:06:48 -0700 (PDT) Date: Tue, 29 Apr 2008 14:06:48 -0700 From: Eric Rescorla To: Mike In-Reply-To: <4817881D.9080605@pobox.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> <4817881D.9080605@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080429210648.F2F075081A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Tue, 29 Apr 2008 13:42:05 -0700, Mike wrote: > > >> But how could the substitution attack even succeed? You would need > >> to create a valid CA signature on the replacement certificate, which > >> should not be possible. > > > > Why not? All you need is a CA which doesn't require technical > > Proof of Possession of the private key. > > If you can't trust your own CA, then by all means send the hash. This is not about trusting your own CA, because a CA which issues certificates without requiring PoP is not acting in an untrustworthy fashion. To recap, the attack looks like this: 1. Alice gets a certificate with key pair K_pub, K_priv. 2. The attacker gets his own certificate with K_pub, K_priv under his own name. 3. Alice connects to the server and offers to authenticate using certificate_url. 4. The attacker intercepts the server's connection to the URL provided by Alice and substitutes his own certificate. 5. The server now thinks that any data sent by Alice was actually sent by the attacker. So, first of all, whatever CA the attacker used has not done anything wrong. Second, the CA can be totally different from the client. Third, the client has no way of knowing what policies the CAs trusted by the server enforce. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 15:17:00 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17A33A68DB; Tue, 29 Apr 2008 15:16:59 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07BD3A682E for ; Tue, 29 Apr 2008 15:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6x9n55tfbsX for ; Tue, 29 Apr 2008 15:16:55 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2293C3A69AD for ; Tue, 29 Apr 2008 15:16:54 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id m3TMGkeY009124 for ; Wed, 30 Apr 2008 00:16:47 +0200 (MEST) From: Martin Rex Message-Id: <200804292216.m3TMGimL010768@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 30 Apr 2008 00:16:44 +0200 (MEST) In-Reply-To: <4817881D.9080605@pobox.com> from "Mike" at Apr 29, 8 01:42:05 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org The "vulnerabilities" in the client-cert-URL extension without certificate hash are IMHO somewhat subtle. It definitely not a regular MITM type of attack. The thing that *I* don't like is the following: IMHO, the client should always consciously assert an identity when performing an authentication. The private key & certificate are only a means to prove ownership of that identity. Normally, this is done by including a specific certificate in the authentication that contains a binding of a public key to an identity. The server is, in general, going to grant access based on the identity (or authorizations bound to the identity), and *NOT* based on the public key -- otherwise the use of a certificate instead of a naked public key would be a huge wasted effort. If the client does not assert an identity during authentication, but instead passes an URL, then it is no longer asserting the identity (in a protected fashion). Personally, I consider that a (security) problem. If an attacker could get a certificate issued with the clients public key and someone elses identity, then he might have a means to cause trouble for the client by subtituting the certificate (when the server tries to download it). I would not feel comfortable with an authentication protocol where only a password is sent, and the server is supposed to figure out by himself to which account the authentication should be mapped. And maybe you could abuse this to have the server check whether someone('s certificate) someones account exists, depending on the servers error message... -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 17:14:38 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B513A6BFD; Tue, 29 Apr 2008 17:14:38 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A79E3A6C9D for ; Tue, 29 Apr 2008 17:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9vX+OA3XULU for ; Tue, 29 Apr 2008 17:14:35 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 32A003A6C75 for ; Tue, 29 Apr 2008 17:14:34 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 045AA363C for ; Tue, 29 Apr 2008 20:14:37 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 917B0363B for ; Tue, 29 Apr 2008 20:14:36 -0400 (EDT) Message-ID: <4817BA5E.5010402@pobox.com> Date: Tue, 29 Apr 2008 17:16:30 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> <4817881D.9080605@pobox.com> <20080429210648.F2F075081A@romeo.rtfm.com> In-Reply-To: <20080429210648.F2F075081A@romeo.rtfm.com> X-Pobox-Relay-ID: 6B079B8A-164A-11DD-AEC6-80001473D85F-38729857!a-sasl-fastnet.pobox.com Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > To recap, the attack looks like this: > > 1. Alice gets a certificate with key pair K_pub, K_priv. > 2. The attacker gets his own certificate with K_pub, K_priv > under his own name. > 3. Alice connects to the server and offers to authenticate > using certificate_url. > 4. The attacker intercepts the server's connection to the > URL provided by Alice and substitutes his own certificate. > 5. The server now thinks that any data sent by Alice was > actually sent by the attacker. But won't the CertificateVerify message fail since the attacker has a different private key than Alice? In any case, maybe the data that needs to be sent is not the hash of the certificate, but rather the identity the client wants to authenticate as. This could be the subject DN, or SAN from the certificate. An advantage of using that is that it is invariant even as the actual certificate is periodically reissued. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 17:23:08 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F0928C28C; Tue, 29 Apr 2008 17:23:08 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA3428C30E for ; Tue, 29 Apr 2008 17:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-iYiKUJPLFx for ; Tue, 29 Apr 2008 17:23:06 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 60ED628C28C for ; Tue, 29 Apr 2008 17:23:06 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id C88873AA5 for ; Tue, 29 Apr 2008 20:23:08 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 7D8C83AA4 for ; Tue, 29 Apr 2008 20:23:08 -0400 (EDT) Message-ID: <4817BC5E.5000209@pobox.com> Date: Tue, 29 Apr 2008 17:25:02 -0700 From: Mike User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tls@ietf.org References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> In-Reply-To: <20080429202042.3E54E5081A@romeo.rtfm.com> X-Pobox-Relay-ID: 9C16F79C-164B-11DD-BA08-80001473D85F-38729857!a-sasl-fastnet.pobox.com Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >> There is the problem of the client knowing when its certificate is >> updated and that it should retrieve a new copy to recalculate the >> hash. It could keep track of its own validity period, but that >> complicates things, and wouldn't work if the CA decides to reissue >> a certificate early. > > Polling occasionally hardly seems like an insuperable barrier. Another problem is if the client merely polls the URL to obtain the certificate to calculate the hash without verifying that the cert. is correct. And how can it know if the certificate is correct w/o having its own copy? This extension could just be a big can of worms. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 17:33:50 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89813A6895; Tue, 29 Apr 2008 17:33:50 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E202E3A68C7 for ; Tue, 29 Apr 2008 17:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPHntsZ+YhPC for ; Tue, 29 Apr 2008 17:33:48 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 32BC53A6784 for ; Tue, 29 Apr 2008 17:33:48 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A3AE65081A; Tue, 29 Apr 2008 17:37:22 -0700 (PDT) Date: Tue, 29 Apr 2008 17:37:22 -0700 From: Eric Rescorla To: Mike In-Reply-To: <4817BA5E.5010402@pobox.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> <4817881D.9080605@pobox.com> <20080429210648.F2F075081A@romeo.rtfm.com> <4817BA5E.5010402@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080430003722.A3AE65081A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Tue, 29 Apr 2008 17:16:30 -0700, Mike wrote: > > > To recap, the attack looks like this: > > > > 1. Alice gets a certificate with key pair K_pub, K_priv. > > 2. The attacker gets his own certificate with K_pub, K_priv > > under his own name. > > 3. Alice connects to the server and offers to authenticate > > using certificate_url. > > 4. The attacker intercepts the server's connection to the > > URL provided by Alice and substitutes his own certificate. > > 5. The server now thinks that any data sent by Alice was > > actually sent by the attacker. > > But won't the CertificateVerify message fail since the attacker > has a different private key than Alice? No, because the attacker is presenting a certificate with Alice's public key and Alice is doing the signing. Remember that the key to the attack is that the attacker is able to get a cert for a name of his choice but with Alice's public key. > In any case, maybe the data that needs to be sent is not the > hash of the certificate, but rather the identity the client > wants to authenticate as. This could be the subject DN, or > SAN from the certificate. An advantage of using that is that > it is invariant even as the actual certificate is periodically > reissued. Perhaps yes, but that would require an actual change to the syntax of the protocol, whereas this is just a new requirement to use the existing syntax. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 17:35:14 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A09C3A6BFD; Tue, 29 Apr 2008 17:35:14 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E581E3A6C3E for ; Tue, 29 Apr 2008 17:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cvi2N3uDfXR for ; Tue, 29 Apr 2008 17:35:11 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 412D43A6AED for ; Tue, 29 Apr 2008 17:35:11 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0FA015081A; Tue, 29 Apr 2008 17:38:46 -0700 (PDT) Date: Tue, 29 Apr 2008 17:38:46 -0700 From: Eric Rescorla To: Mike In-Reply-To: <4817BC5E.5000209@pobox.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> <4817BC5E.5000209@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080430003846.0FA015081A@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Tue, 29 Apr 2008 17:25:02 -0700, Mike wrote: > > >> There is the problem of the client knowing when its certificate is > >> updated and that it should retrieve a new copy to recalculate the > >> hash. It could keep track of its own validity period, but that > >> complicates things, and wouldn't work if the CA decides to reissue > >> a certificate early. > > > > Polling occasionally hardly seems like an insuperable barrier. > > Another problem is if the client merely polls the URL to obtain the > certificate to calculate the hash without verifying that the cert. > is correct. And how can it know if the certificate is correct w/o > having its own copy? Huh? The client has been configured with the URL for the CA. It can also be configured with the expected DN and the CA's public key. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 20:54:57 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88A33A6C13; Tue, 29 Apr 2008 20:54:57 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2312D3A6C13 for ; Tue, 29 Apr 2008 20:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGE61VbG8DCG for ; Tue, 29 Apr 2008 20:54:56 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by core3.amsl.com (Postfix) with ESMTP id 30D143A6B02 for ; Tue, 29 Apr 2008 20:54:56 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id D9A373E4DA for ; Wed, 30 Apr 2008 03:54:58 +0000 (UTC) X-SpamScore: 1 Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by omf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Apr 2008 03:54:58 +0000 (UTC) Message-ID: <4817ED8C.9030208@bolyard.com> Date: Tue, 29 Apr 2008 20:54:52 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b3pre) Gecko/2008020302 NOT Firefox/2.0 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: tls@ietf.org References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> <4817881D.9080605@pobox.com> <20080429210648.F2F075081A@romeo.rtfm.com> <4817BA5E.5010402@pobox.com> <20080430003722.A3AE65081A@romeo.rtfm.com> In-Reply-To: <20080430003722.A3AE65081A@romeo.rtfm.com> X-Spam-Summary: 2, 0, 0, f0af98cce7d4728c, c1f0be6ca7734e96, nelson@bolyard.com, , RULES_HIT:152:355:379:599:601:973:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1605:1676:1711:1730:1747:1766:1792:2377:2379:2393:2559:2562:2897:2899:2900:2915:3027:3636:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4321:5007:6119:6120:7652:7875:7903:8557, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-session-marker: 6E656C736F6E40626F6C796172642E636F6D Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Eric Rescorla wrote, On 2008-04-29 17:37 PDT: > [...] the attacker is presenting a certificate with > Alice's public key and Alice is doing the signing. Remember > that the key to the attack is that the attacker is able to > get a cert for a name of his choice but with Alice's public > key. I call that CA malfeasance, having issued a cert without proof of key possession. Perhaps a server that trusts such a CA gets what it deserves. Given the usual assumptions of the improbability of key collisions, upon which digital signature systems depend, I claim that in the absence of - CA malfeasance, - CA collusion, - CA key compromise, - EE (victim) key compromise, - TLS server malfeasance (failing to verify signature on cert, or client's certificate verify message), and - server application malfeasance (failure to verify authorization of the verified identity), the worst the attacker can do is to substitute a certificate that causes a denial of service. In the unlikely event that the attacker is able to find a valid cert with the same public key as the victim's, issued by one of the CAs trusted by the server for client auth, it is very unlikely that the identity on that cert is one of the attacker's choosing or under the control or even influence of the attacker. The probability that the attacker finds a key collision for a valid cert with an identity that he controls (or from which he directly benefits) is essentially the same as (equivalent to?) the probability that he possesses or controls the victim's private key, which is effectively EE key compromise, which I excluded above. Substitution of a "random" client cert (whose identity is not under the attacker's control or to his benefit) is likely to result in no more than denial of service, for the reasons stated. But denial of service can be accomplished in many other more trivial ways. The hash doesn't protect against it. >> In any case, maybe the data that needs to be sent is not the >> hash of the certificate, but rather the identity the client >> wants to authenticate as. This could be the subject DN, or >> SAN from the certificate. An advantage of using that is that >> it is invariant even as the actual certificate is periodically >> reissued. Yes, I could accept that, too. That appears to address the concern that Eric (and others) have stated without imposing unnecessary limitations and difficulties. I agree with Martin's point that the client needs to assert an identity, which the signature merely verifies. A hash protects against some of the conditions I excluded above, but so does an identity assertion. > Perhaps yes, but that would require an actual change to the syntax of > the protocol, whereas this is just a new requirement to use the > existing syntax. Yes, but perhaps it's worthy of undertaking to make that change. Use of the extension could require either a hash or a GeneralName. /Nelson _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Apr 29 21:57:04 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8CA3A69E3; Tue, 29 Apr 2008 21:57:04 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC9A3A690F for ; Tue, 29 Apr 2008 21:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8WsA7HErWaf for ; Tue, 29 Apr 2008 21:57:02 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 7DD6B3A68FA for ; Tue, 29 Apr 2008 21:57:02 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 4C56925FC08; Tue, 29 Apr 2008 21:57:05 -0700 (PDT) Date: Tue, 29 Apr 2008 21:57:04 -0700 From: Eric Rescorla To: Nelson B Bolyard In-Reply-To: <4817ED8C.9030208@bolyard.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com> <48173B41.5000401@bolyard.com> <20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> <20080429202042.3E54E5081A@romeo.rtfm.com> <4817881D.9080605@pobox.com> <20080429210648.F2F075081A@romeo.rtfm.com> <4817BA5E.5010402@pobox.com> <20080430003722.A3AE65081A@romeo.rtfm.com> <4817ED8C.9030208@bolyard.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080430045705.4C56925FC08@kilo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At Tue, 29 Apr 2008 20:54:52 -0700, Nelson B Bolyard wrote: > > Eric Rescorla wrote, On 2008-04-29 17:37 PDT: > > [...] the attacker is presenting a certificate with > > Alice's public key and Alice is doing the signing. Remember > > that the key to the attack is that the attacker is able to > > get a cert for a name of his choice but with Alice's public > > key. > > I call that CA malfeasance, having issued a cert without proof of > key possession. Perhaps a server that trusts such a CA gets what it > deserves. Then I encourage you to take that up with PKIX, since it seems clear to me that this is explicitly allowed (RFC 3280 S 3.1.): This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of possession through a challenge- response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime > Given the usual assumptions of the improbability of key collisions, upon > which digital signature systems depend, I claim that in the absence of > - CA malfeasance, > - CA collusion, > - CA key compromise, > - EE (victim) key compromise, > - TLS server malfeasance (failing to verify signature on cert, or > client's certificate verify message), and > - server application malfeasance (failure to verify authorization of > the verified identity), > the worst the attacker can do is to substitute a certificate that causes > a denial of service. > > In the unlikely event that the attacker is able to find a valid cert > with the same public key as the victim's, issued by one of the CAs trusted > by the server for client auth, it is very unlikely that the identity on > that cert is one of the attacker's choosing or under the control or even > influence of the attacker. The probability that the attacker finds a > key collision for a valid cert with an identity that he controls (or from > which he directly benefits) is essentially the same as (equivalent to?) the > probability that he possesses or controls the victim's private key, which is > effectively EE key compromise, which I excluded above. Substitution of a > "random" client cert (whose identity is not under the attacker's control or > to his benefit) is likely to result in no more than denial of service, for > the reasons stated. > > But denial of service can be accomplished in many other more trivial ways. > The hash doesn't protect against it. The above material seems to be premised on the assumption that CAs who issue certificates without PoP are acting improperly, but as indicated above, I don't think that's at all clear, so I don't really subscribe to the conclusion either. > > Perhaps yes, but that would require an actual change to the syntax of > > the protocol, whereas this is just a new requirement to use the > > existing syntax. > > Yes, but perhaps it's worthy of undertaking to make that change. > Use of the extension could require either a hash or a GeneralName. Well, this would require creating an entirely new extension, since the client_certificate_url extension has no way of indicating whether hash (or anything else) will be indicated in the CertificateURL message, so the client can't safely provide a GeneralName value without potentially sending something the server can't handle. Not saying you shouldn't propose such an extension, but I don't see how that's an argument against requiring hash with this one. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 30 01:28:04 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2B13A699D; Wed, 30 Apr 2008 01:28:04 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4C63A6856 for ; Wed, 30 Apr 2008 01:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ug9jVZ-CnSS for ; Wed, 30 Apr 2008 01:28:02 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 180453A6CB6 for ; Wed, 30 Apr 2008 01:28:01 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3U8Rk47031176; Wed, 30 Apr 2008 11:28:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 11:27:40 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 11:27:40 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 11:27:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB727BCB44@vaebe104.NOE.Nokia.com> In-Reply-To: <48174BB8.7080009@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS document status update Thread-index: AciqFXKOG2MjkomOShKxVHKPibKFwAAhMIsQ References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com><48173B41.5000401@bolyard.com><20080429152618.B25AD5081A@romeo.rtfm.com> <48174BB8.7080009@pobox.com> From: To: , X-OriginalArrivalTime: 30 Apr 2008 08:27:40.0003 (UTC) FILETIME=[0D9C5B30:01C8AA9C] X-Nokia-AV: Clean Subject: Re: [TLS] TLS document status update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mike wrote: > But how could the substitution attack even succeed? You would need > to create a valid CA signature on the replacement certificate, which > should not be possible. This has been explained couple of times earlier, but let me recap one scenario: Assume that the client has several certificates (all of which are properly issued by valid CAs) that contain the same public key, but different subject names. For example, one of the subject names could identify the user as an employee of Example Inc; another name could be his personal identity; third one might be an administrator/superuser role; etc. (In this example, nobody's keys have been compromised, all CAs are behaving exactly as they should, proof-of-possession is being done, etc.) If the hash is not included, the client could send an URL to the first certificate, but the attacker could replace it with the third certificate. Given that TLS is a building block that's used in large variety of applications (and will be used in the future for things we don't know about yet), it's not totally unplausible that more than one of these certificates could be acceptable to a server, and it would behave differently for them. (You could of course argue that the user should have used different private/public key pairs when requesting these different certificates, but that's not always done. You could also argue that since all the certificates belong to the same user, there's no attack, but I don't agree with that one.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 30 11:03:10 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C75C28C114; Wed, 30 Apr 2008 11:03:10 -0700 (PDT) X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6E43A6C47 for ; Wed, 30 Apr 2008 11:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cCiKWFxLPY6 for ; Wed, 30 Apr 2008 11:03:06 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E686628C3B9 for ; Wed, 30 Apr 2008 11:02:17 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m3UIwwj2782554; Wed, 30 Apr 2008 19:58:58 +0100 Received: from 137.194.192.227 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 30 Apr 2008 19:58:32 +0200 (CEST) Message-ID: <57263.137.194.192.227.1209578312.squirrel@www.isima.fr> In-Reply-To: <20080430003846.0FA015081A@romeo.rtfm.com> References: <1696498986EFEC4D9153717DA325CB727BC503@vaebe104.NOE.Nokia.com><48173B41.5000401@bolyard.com><20080429152618.B25AD5081A@romeo.rtfm.com><48174BB8.7080009@pobox.com><20080429202042.3E54E5081A@romeo.rtfm.com><4817BC5E.5000209@pobox.com> <20080430003846.0FA015081A@romeo.rtfm.com> Date: Wed, 30 Apr 2008 19:58:32 +0200 (CEST) From: badra@isima.fr To: Pasi.Eronen@nokia.com, ekr@networkresonance.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Wed, 30 Apr 2008 19:58:58 +0100 (WEST) Cc: tls@ietf.org Subject: [TLS] =?utf-8?b?IFJlOsKgwqBUTFPCoGRvY3VtZW50wqBzdGF0dXPCoHVwZGF0?= =?utf-8?q?e?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Pasi.Eronen@nokia.com wrote: > draft-ietf-tls-rsa-aes-gcm: > The draft went through WGLC, and Joe posted version -03 which > seems to address the WGLC comments. Unless there are > objections, this will be sent to AD evaluation once the chairs > get the Document Shepherd Write-Up written. > > draft-ietf-tls-ecc-new-mac > > The draft also went through WGLC; version -05 seems to address > the WGLC comments, but has some editorial nits. Once Eric submits version -06, this will be sent to AD evaluation. > Dear Pasi and Eric, I would like to inform you and the WG that I submitted a document (draft-badra-tls-psk-new-mac-aes-gcm), which specifies combinations of AES_GCM and PSK, and dsecribes a set of ciphersuites with stronger digest algorithms. http://www.ietf.org/internet-drafts/draft-badra-tls-psk-new-mac-aes-gcm-02.txt Since the document is based and heavily borrows from draft-ietf-tls-ecc-new-mac and draft-ietf-tls-rsa-aes-gcm, I would like to request that the TLS WG adopts this document as a WG item. Best regards, Badra _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls