From internet-drafts@ietf.org Tue Apr 2 09:05:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A15D21F8D01; Tue, 2 Apr 2013 09:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt+6DhGxc9I0; Tue, 2 Apr 2013 09:05:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EA921F8CE8; Tue, 2 Apr 2013 09:05:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130402160548.12739.44954.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 09:05:48 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:05:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-06.txt Pages : 9 Date : 2013-04-02 Abstract: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods (commonly referred to as OCSP stapling). Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-exte= nsion-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yngve@spec-work.net Tue Apr 2 09:10:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6D21F8D61 for ; Tue, 2 Apr 2013 09:10:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oswojZ8e3md for ; Tue, 2 Apr 2013 09:10:37 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7BD21F8D33 for ; Tue, 2 Apr 2013 09:10:36 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:55099 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UN3n9-0002Jz-JB for tls@ietf.org; Tue, 02 Apr 2013 18:10:35 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <20130402160548.12739.44954.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 18:10:22 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130402160548.12739.44954.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:10:37 -0000 Hello all, Just wrapping up a last minute IETF Last Call comment. - "OCSP stapling" reference in abstract - changed "inappropriate" to "MUST NOT" at the end of the section 2.2; suggested by the security reviewer On Tue, 02 Apr 2013 18:05:48 +0200, wrote: > > 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 : The TLS Multiple Certificate Status Request Extension > Author(s) : Yngve N. Pettersen > Filename : draft-ietf-tls-multiple-cert-status-extension-06.txt > Pages : 9 > Date : 2013-04-02 > > Abstract: > This document defines the Transport Layer Security (TLS) Certificate > Status Version 2 Extension to allow clients to specify and support > multiple certificate status methods (commonly referred to as OCSP > stapling). Also defined is a new method based on the Online > Certificate Status Protocol (OCSP) that servers can use to provide > status information not just about the server's own certificate, but > also the status of intermediate certificates in the chain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-multiple-cert-status-extension-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From jsalowey@cisco.com Tue Apr 2 14:37:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021E521F89C3 for ; Tue, 2 Apr 2013 14:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-upYHLHOEwv for ; Tue, 2 Apr 2013 14:36:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9521F89AF for ; Tue, 2 Apr 2013 14:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=479; q=dns/txt; s=iport; t=1364938619; x=1366148219; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=oE3PDCidMyo+z0hHy0ToEhoU04luYV83uzt6VIj9+j0=; b=MfSJN6l0qCXI5TRwtzUcNepHx6b7Mp0DcY+Jq97KuNuBRuM8I0u6ZQ/6 jLqP8FEYItBtZqie4WGNGJQW4xWqyrMEkJXiwP95XIARx84AlbIMpamDB HuJVsszHXaOD4OE2WPeSOC2DmptgyDfFA/G4/wCxrUUL3YAAXVCj/ubER 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA1OW1GtJXHB/2dsb2JhbABDgwfAK4EIFnSCIQEEOlEBKhRCJwQbiAygZpESkAyOaIMXYQOndoMLgig X-IronPort-AV: E=Sophos;i="4.87,394,1363132800"; d="scan'208";a="194235687" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 02 Apr 2013 21:36:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r32LawgC029413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Apr 2013 21:36:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 16:36:58 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Working Group interest draft-merkle-tls-brainpool-00 Thread-Index: AQHOL+o0F8aBBwuT10amdZZV6qKl7Q== Date: Tue, 2 Apr 2013 21:36:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Working Group interest draft-merkle-tls-brainpool-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:37:00 -0000 The authors of draft-merkle-tls-brainpool-00.txt have requested that the wo= rking group take on this work. I'm not sure if there is sufficient intere= st to bring this into the working group. If you are interested in this wo= rk please send a note to the list indicating if you can be counted on for r= eviews and/or text changes a necessary. If you think the working group sho= uld not take on this work please state why. Please respond by April 22, = 2013. =20 From simon@josefsson.org Tue Apr 2 17:11:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DD321F867A for ; Tue, 2 Apr 2013 17:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQKEkfxeUeOx for ; Tue, 2 Apr 2013 17:11:21 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1D92221F8624 for ; Tue, 2 Apr 2013 17:11:20 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r330BAdv012736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2013 02:11:12 +0200 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130403:tls@ietf.org::xtwY6w3tYQ7xmDT1:7YCl X-Hashcash: 1:22:130403:jsalowey@cisco.com::Zr+iNAcs+rBorbL4:DHdG Date: Wed, 03 Apr 2013 02:11:10 +0200 In-Reply-To: (Joseph Salowey's message of "Tue, 2 Apr 2013 21:36:58 +0000") Message-ID: <878v50mq1t.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "" Subject: Re: [TLS] Working Group interest draft-merkle-tls-brainpool-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 00:11:22 -0000 "Joseph Salowey (jsalowey)" writes: > The authors of draft-merkle-tls-brainpool-00.txt have requested that > the working group take on this work. I'm not sure if there is > sufficient interest to bring this into the working group. If you are > interested in this work please send a note to the list indicating if > you can be counted on for reviews and/or text changes a necessary. If > you think the working group should not take on this work please state > why. Please respond by April 22, 2013. I support taking on this work. I did a quick review and noticed this: OLD: Usage of elliptic curves for authentication and key agreement in TLS 1.1 and TLS 2.0 is defined in [RFC4492]. While the ASN.1 object ^ ^^^ NEW. Usage of elliptic curves for authentication and key agreement in TLS 1.0 and TLS 1.1 is defined in [RFC4492]. While the ASN.1 object ^ ^^^ /Simon From dharkins@lounge.org Tue Apr 2 18:58:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3185821F88E3 for ; Tue, 2 Apr 2013 18:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMN8BFy8qJXR for ; Tue, 2 Apr 2013 18:58:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id CD78921F88D8 for ; Tue, 2 Apr 2013 18:58:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2EE85A888006; Tue, 2 Apr 2013 18:58:03 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 2 Apr 2013 18:58:03 -0700 (PDT) Message-ID: <613af51993b8fbe387c3d24a96b03947.squirrel@www.trepanning.net> In-Reply-To: References: Date: Tue, 2 Apr 2013 18:58:03 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] Working Group interest draft-merkle-tls-brainpool-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:58:04 -0000 On Tue, April 2, 2013 2:36 pm, Joseph Salowey (jsalowey) wrote: > The authors of draft-merkle-tls-brainpool-00.txt have requested that the > working group take on this work. I'm not sure if there is sufficient > interest to bring this into the working group. If you are interested in > this work please send a note to the list indicating if you can be counted > on for reviews and/or text changes a necessary. If you think the working > group should not take on this work please state why. Please respond by > April 22, 2013. I support this work and can be counted on for reviews and also to validate the test vectors. Dan. From Michael.Staubermann@webolution.de Thu Apr 4 03:38:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5617E21F866E for ; Thu, 4 Apr 2013 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uiMi+MJ7oHw for ; Thu, 4 Apr 2013 03:38:18 -0700 (PDT) Received: from mail.webolution.de (mail.webolution.de [80.152.246.40]) by ietfa.amsl.com (Postfix) with ESMTP id 72FC421F84AD for ; Thu, 4 Apr 2013 03:38:16 -0700 (PDT) Received: from staubermann.webolution.de ([192.168.168.32] helo=StaubermannPC) by mail.webolution.de with esmtp (Exim 4.69) (envelope-from ) id 1UNhYZ-0007LG-TR; Thu, 04 Apr 2013 12:38:12 +0200 From: "Michael Staubermann" To: "'Joseph Salowey \(jsalowey\)'" References: In-Reply-To: Date: Thu, 4 Apr 2013 12:39:35 +0200 Message-ID: <070d01ce3120$b61a8970$224f9c50$@Staubermann@webolution.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOL+o0F8aBBwuT10amdZZV6qKl7ZjF2QLA Content-Language: de X-SA-Exim-Connect-IP: 192.168.168.32 X-SA-Exim-Mail-From: Michael.Staubermann@webolution.de X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on mail.webolution.de) Cc: tls@ietf.org Subject: Re: [TLS] Working Group interest draft-merkle-tls-brainpool-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 10:38:19 -0000 I support this work an can be counted on for reviews. There is already a published document from the European OMS Group (Metering), referring to TLS NamedCurved IDs for Brainpool ECC: http://www.oms-group.org/download/OMS-TR01_Security_v110.pdf (Chapter 7.1, Table 11) If no dedicated IANA assignment is available for the Brainpool curves, it is likely that the "Reserved for Private" use range of the EC named curved registry (65025-65279) will be used for the TBDs which may lead to future "Private" Assignment collisions. I agree with the proposal to start (in 2013) with 256bit curves and leave the 192bit and 224bit curves out for TLS. -mst From trevp@trevp.net Thu Apr 4 14:02:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822B521F93A9 for ; Thu, 4 Apr 2013 14:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.356 X-Spam-Level: * X-Spam-Status: No, score=1.356 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCJQ4jzp9Ooa for ; Thu, 4 Apr 2013 14:02:29 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D043621F8FD3 for ; Thu, 4 Apr 2013 14:02:28 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so2398654wey.5 for ; Thu, 04 Apr 2013 14:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=WCNffB/C9dp9HCn/MuaPFTWkgE6JQ564KWCnM7KzWGg=; b=KjV9WSSy+PZSdufJgtXPQBtb0SV7rDN0mcfqZs93wL1BTA3578wLlYN/ejYgJ8mwTw hyBCwtlg5eGHLupqMp/Hk8xJ8NSV7KBqxt8top2d3aalYprptOZ/BAV7RNN88h/QZWFX Bw+9GxH2i4CsuVHq/eWiuYs8OGxA+BAZejwn97B21AXMrVmIRa8rsh7BgQ6Ah5/pvPlW JKXu5oTHtNYbvPsA+cJ6Gg+Q+3HSseNKDShzMN2oii8xm+TarXypEdHNcKUSmfrMax/w dJ3emb74C4MYL9dV9yKZAzsSvqEbfNOT+odmi38ypTk+ojWk3xO3YEHyFtIwXkZgm1nY enRQ== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr11643296wjb.24.1365109347932; Thu, 04 Apr 2013 14:02:27 -0700 (PDT) Received: by 10.216.111.1 with HTTP; Thu, 4 Apr 2013 14:02:27 -0700 (PDT) X-Originating-IP: [64.134.227.227] Date: Thu, 4 Apr 2013 14:02:27 -0700 Message-ID: From: Trevor Perrin To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlxOb6xNfNABqHsLvwm6vIyQZObf4EOxL1+fmDrYsaqLrVVTNSzx81NxdfqKumfho89bw1A Subject: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:02:29 -0000 Hi, I've heard (anecdotally) that HTTPS between browsers and webservers who are both TLS-capable sometimes results in SSLv3 connections. Presumably this is due to firewall interference with the TLS handshake, causing browsers to retry an SSLv3 handshake. I believe TLS Extensions are generally not sent in the SSLv3 ClientHello (?). This isn't a major problem for TLS Extensions as optimizations (e.g. session tickets or OCSP stapling). However, there are proposals that *require* a TLS Extension response, for security: - TACK's "TackExtension" [1] - Certificate Transparency's "SignedCertificateTimestampList" [2] - OCSP stapling in the presence of an X.509 "must-staple" extension [3] How should these work in the case of a network-triggered SSLv3 fallback? One proposal would note that some browsers do, I think, send the RFC5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite in an SSLv3 ClientHello, and receive a "renegotiation_info" ServerHello extension in return. So there's evidence that this idiom of a "special ciphersuite value" in an SSLv3 ClientHello, and a TLS Extension in ServerHello, is "compatible-enough" with the horrible middleboxes triggering these fallbacks. This idiom wouldn't work with a proposal that sends data in ClientHello, but both the TACK and CT proposals use empty extension_data, and OCSP stapling seems like it would work as a binary signal, as well (?). So, is it reasonable for things like TACK to consider an SCSV value that could be used instead of (or in combination with) a ClientHello Extension, to request the corresponding ServerHello extension? Trevor From hanno@hboeck.de Thu Apr 4 14:34:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF79321F8EED for ; Thu, 4 Apr 2013 14:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSe6r3yEmwak for ; Thu, 4 Apr 2013 14:34:08 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id BA45921F8E91 for ; Thu, 4 Apr 2013 14:34:08 -0700 (PDT) Received: from melee ([::ffff:24.134.32.58]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by zucker.schokokeks.org with ESMTPSA; Thu, 04 Apr 2013 23:34:06 +0200 id 0000000000000022.00000000515DF1CE.0000197D Date: Thu, 4 Apr 2013 23:34:02 +0200 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: Trevor Perrin Message-ID: <20130404233402.6c91a9bf@melee> In-Reply-To: References: X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-6525-1365111247-0001-2" Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:34:10 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-6525-1365111247-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 4 Apr 2013 14:02:27 -0700 Trevor Perrin wrote: > I've heard (anecdotally) that HTTPS between browsers and webservers > who are both TLS-capable sometimes results in SSLv3 connections. > Presumably this is due to firewall interference with the TLS > handshake, causing browsers to retry an SSLv3 handshake. This happens pretty often if you have a unreliable (e.g. mobile) internet connection. Mozilla/nss-Bug about it: https://bugzilla.mozilla.org/show_bug.cgi?id=3D450280 And it's a serious problem if you're using Server Name Indication (SNI) for more than one SSL cert on one IP. The "solution" I found for our case was that I found it tolerable today to disable SSLv3 on the server side. However, I'm not really happy with that browser fallback behaviour, it's a serious pitfall for the use of SNI. --=20 Hanno B=F6ck mail/jabber: hanno@hboeck.de GPG: BBB51E42 http://www.hboeck.de/ --=_zucker.schokokeks.org-6525-1365111247-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCAAGBQJRXfHMAAoJEKWIAHK7tR5CfBEP/j31NY7b1f7ip0tYACtCEYQ2 S0iQclQu9xrj0zdoMhWcAGTvOyM0+6abEEOXdRID3h0D5Im4eWdfy3KBtSlR1bF+ kZSN2ivxkY4dMEiI2biHSA2rHMPwj53bFqp+vtvnIfBoQsF4qBid3F08/SyGXHUC wJ20okZZFNyIE5QeniFfaUyXoaQLxMyIrzwhEmuxl51P1HpTkD0qtOuszhALQTHh 4BhiBsC1jot8FLQZnisBRoUb28OPQdSeg81W5002FEhhi9o6cN8t/fxxyhP3KaAK N/LLZaPl6D+/mHfrgVly7ymIjQlWfkwneo2pZw9YhaCMlXhEWZlbNqTeSUBScJTh qzz82Q8YJ/SDGKx253oXamBmOGpZmdsVb4bWmZG32a4txq49ON5TFtwGdHFNjKC7 91ecO+SE3wyejWuLirBcPrJh4giPrY5aCQpnEKXJXY9800PDrSolzAu8vtBYv2Xe xsOnrQGodd1G1GWmf0psogWW2zfY7tAAOBBGPnL/BNjjw0HfVLpPpGqCfODyLOO4 Ot0PzaXj427WMK8XqqyyTVYCcQrPmCgij8lIX+jAkrIppaqNhj2yr1dG3zWcFlUn iRJ9EyNO8k336rzWiuHAsonFqn3hK+iD6L5mxR8jnuVdtKIrO14z6m0eHvHl34Nj l1HvQoueAbU7As9sNp1l =SKN2 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-6525-1365111247-0001-2-- From geoffk@geoffk.org Thu Apr 4 14:54:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5BC21F8712 for ; Thu, 4 Apr 2013 14:54:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cPP-mL1AJ7x for ; Thu, 4 Apr 2013 14:54:27 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id DA9A021F86DC for ; Thu, 4 Apr 2013 14:54:27 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 5F5A733D122; Thu, 4 Apr 2013 21:54:25 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Trevor Perrin References: From: Geoffrey Keating Date: 04 Apr 2013 14:54:25 -0700 In-Reply-To: Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:54:29 -0000 Trevor Perrin writes: > Hi, > > I've heard (anecdotally) that HTTPS between browsers and webservers > who are both TLS-capable sometimes results in SSLv3 connections. > Presumably this is due to firewall interference with the TLS > handshake, causing browsers to retry an SSLv3 handshake. The name of one firewall which is confirmed to do this would make it a lot more convincing... It's likely that some TLS connections failed due to packet loss or a busy server and so the 'fallback' was a mistake. > I believe TLS Extensions are generally not sent in the SSLv3 > ClientHello (?). This isn't a major problem for TLS Extensions as > optimizations (e.g. session tickets or OCSP stapling). > > However, there are proposals that *require* a TLS Extension response, > for security: > - TACK's "TackExtension" [1] > - Certificate Transparency's "SignedCertificateTimestampList" [2] > - OCSP stapling in the presence of an X.509 "must-staple" extension [3] > > How should these work in the case of a network-triggered SSLv3 fallback? I would phrase this as "how should these work when under attack and the attacker is blocking extensions". In the case of TACK, I think it should work by saying that if you've previously negotiated TACK, therefore the server must previously have supported at least TLSv1+extensions, so you SHOULD NOT fall back to a SSLv3 ClientHello for that server, and if you do, you MUST continue to apply any active pin. > One proposal would note that some browsers do, I think, send the > RFC5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite in an SSLv3 > ClientHello, and receive a "renegotiation_info" ServerHello extension > in return. I don't believe sending the ServerHello extension is the important part of that protocol, the key part is that the server rejects any renegotiation where the ciphersuite is included. > So there's evidence that this idiom of a "special ciphersuite value" > in an SSLv3 ClientHello, and a TLS Extension in ServerHello, is > "compatible-enough" with the horrible middleboxes triggering these > fallbacks. For counter-evidence, see . From yngve@spec-work.net Thu Apr 4 15:43:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DE21F8FD3 for ; Thu, 4 Apr 2013 15:43:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLHUj9zopZqY for ; Thu, 4 Apr 2013 15:43:52 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id F2D3621F8FA1 for ; Thu, 4 Apr 2013 15:43:50 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:56399 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UNssm-0000Oq-P9 for tls@ietf.org; Fri, 05 Apr 2013 00:43:48 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: Date: Fri, 05 Apr 2013 00:43:32 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 22:43:53 -0000 On Thu, 04 Apr 2013 23:02:27 +0200, Trevor Perrin wrote: > Hi, > > I've heard (anecdotally) that HTTPS between browsers and webservers > who are both TLS-capable sometimes results in SSLv3 connections. > Presumably this is due to firewall interference with the TLS > handshake, causing browsers to retry an SSLv3 handshake. There are several types of problem, both concerning network problems (Google have been detecting and tracking some of those) and what appears to be server problems with certain extensions. Regarding the latter, I have observed two specific issues: intolerance for Server Name Indication and for Certificate Status. The affected number of connections and servers appear to be very small. > I believe TLS Extensions are generally not sent in the SSLv3 > ClientHello (?). This isn't a major problem for TLS Extensions as That is correct; Opera 12 also have a fallback mode that uses TLS 1.0 without extensions. > optimizations (e.g. session tickets or OCSP stapling). > > However, there are proposals that *require* a TLS Extension response, > for security: > - TACK's "TackExtension" [1] > - Certificate Transparency's "SignedCertificateTimestampList" [2] > - OCSP stapling in the presence of an X.509 "must-staple" extension [3] > > How should these work in the case of a network-triggered SSLv3 fallback? For the servers/networks that will not accept a connection from a full TLS client with extensions, these features will not work, and strictly deployed (which they should be) the site will break. > One proposal would note that some browsers do, I think, send the > RFC5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite in an SSLv3 > ClientHello, and receive a "renegotiation_info" ServerHello extension > in return. > > So there's evidence that this idiom of a "special ciphersuite value" > in an SSLv3 ClientHello, and a TLS Extension in ServerHello, is > "compatible-enough" with the horrible middleboxes triggering these > fallbacks. In my opinion, using SCSVs should never be used. They were used once for Renego to accommodate SSL v3 only servers that could not be upgraded to TLS 1.x. That seems to have opened up a slippery slope where "every" problem can be "solved" by using those values, rather than standing firm and forcing the problematic servers/infrastructure to be updated. Bending over backwards will only ensure that the problem never disappear or take much longer than necessary to be removed. Also: using SCSVs from the client might "fix" the client->server information. What if some of the responsible infrastructure also affect the server->client communication, and break sending of extensions back to the client? > This idiom wouldn't work with a proposal that sends data in > ClientHello, but both the TACK and CT proposals use empty > extension_data, and OCSP stapling seems like it would work as a binary > signal, as well (?). > > So, is it reasonable for things like TACK to consider an SCSV value > that could be used instead of (or in combination with) a ClientHello > Extension, to request the corresponding ServerHello extension? > > > Trevor > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From jpixton@gmail.com Fri Apr 5 12:33:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1E21F93CD for ; Fri, 5 Apr 2013 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gyu-mPcE+JU for ; Fri, 5 Apr 2013 12:33:30 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B272B21F9390 for ; Fri, 5 Apr 2013 12:33:29 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id z53so3095929wey.37 for ; Fri, 05 Apr 2013 12:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Osd+eG7kIsIkg2tllawsZMCohaqfVSylZ/931vArCZ0=; b=Sm2x37vnVjynUB+EBwsKUR53HqK3ZaE/aPIvTELev7OLtlnC6hVMP3jFOn9FJ0i6vy T0yvNDpuIOQqz8XzCDELPjwYdUqCZNXpic1MW4g2xVw5dwaY80IBnSRMyRkw7SpbGvUV Fqin3cA+sx9uXfsh5O1mdIG9vTPGPjY4J9AFFTBmOKwT2WAcIKCezlpt5ezSphmhRPAt kGX8gEsLzfJBJlMKAfruLqf/tBQF8Eq2KKdYhK5Be+va1QPU6vAlttd9veM/OY5eX82m 6vzcImY7aXZHpjFquPbvaUa+JO+NJLoLqJlhdYQaul8xdWch0HlFj18Kd262k7wpPd5t gywA== MIME-Version: 1.0 X-Received: by 10.194.89.234 with SMTP id br10mr18846405wjb.43.1365190408863; Fri, 05 Apr 2013 12:33:28 -0700 (PDT) Received: by 10.216.163.195 with HTTP; Fri, 5 Apr 2013 12:33:28 -0700 (PDT) Date: Fri, 5 Apr 2013 20:33:28 +0100 Message-ID: From: Joseph Birr-Pixton To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 19:33:30 -0000 On Thu, 4 Apr 2013 23:34:02 +0200, Hanno B?ck wrote: > Date: Thu, 4 Apr 2013 23:34:02 +0200 > From: Hanno B?ck > Subject: Re: [TLS] SCSVs and SSLv3 fallback > Message-ID: <20130404233402.6c91a9bf@melee> > Content-Type: text/plain; charset="iso-8859-1" > And it's a serious problem if you're using Server Name > Indication (SNI) for more than one SSL cert on one IP. The "solution" I > found for our case was that I found it tolerable today to disable SSLv3 > on the server side. However, I'm not really happy with that browser > fallback behaviour, it's a serious pitfall for the use of SNI. Worse than that; it's a serious pitfall for users who think they are benefiting from any of the security improvements made since SSL3. For example: I surveyed the alexa top 500 web sites; 321 provide a working SSL or TLS service. 27% chose different security parameters under downgrade conditions. Of those, 81% lost forward secrecy under attacker control. Notably, google.com went from a server authentication key providing ~128 bits of security and ciphersuite providing forward secrecy, to a server authentication key providing ~73 bits of security and no forward secrecy. That is really very, very broken. More relevantly, any sites deploying non-broken AEAD ciphersuites in the near future (while still providing SSL3 service) will still be subject to attacker-controlled downgrade to CBC-mode or RC4 ciphersuites. Cheers, Joe From trevp@trevp.net Fri Apr 5 12:46:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDC821F98BD for ; Fri, 5 Apr 2013 12:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3+aMnCUp-Mx for ; Fri, 5 Apr 2013 12:46:32 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF1121F98BC for ; Fri, 5 Apr 2013 12:46:28 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id c10so936643wiw.8 for ; Fri, 05 Apr 2013 12:46:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1nsQNvQ9NFbTARigTQCY7Vb4kV8Zuhia9qDxbO6XFPk=; b=WSjv5Uc1wabDBUSx3RVCkGlW1QWw4emG8KQhFSFIEpjsYWH++pJNmDBndgBDqZysDV zxBYfeJwuvOrkaJtzdkoAueQz3kH2H3H0kLmN/7JQPBegAhraoXt8IY+Cm9D6rJBdF4B l7fOmxRl2XLXGDlc687MfSjnqKU9uIXEKC/vNKmlZgwULP4WGmg5d9KreF4OHIvjlfjP dqxaU7ZJi1P/ZlBAnj/7zWfVX+TAAfRXRdmYHt35/FfkTzx2PcFugO5lYZoLOWspo3sL 5+G5ZMs9HRbFVjH5/0EVjum/k3CGCO9jUoJX/Fu4QFr5jKhX+5kPeR6TGTkTJC8odrHG 6c9Q== MIME-Version: 1.0 X-Received: by 10.194.104.168 with SMTP id gf8mr18394076wjb.58.1365191188322; Fri, 05 Apr 2013 12:46:28 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 12:46:28 -0700 (PDT) X-Originating-IP: [173.11.71.218] In-Reply-To: References: Date: Fri, 5 Apr 2013 12:46:28 -0700 Message-ID: From: Trevor Perrin To: "Yngve N. Pettersen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmHQ+BQEWMC20ySgnQ9fyUJu1awppATo6ojZSD1QI8rB/oZzeg+8ubCBfkpPe9Z6BFGzRvf Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 19:46:33 -0000 Hi Hanno, Geoffrey, Yngve, Thanks for the info and thoughts, really helpful! It would get complicated to respond to every point individually, let me try to summarize: (1) I've heard anecdotal evidence that something like 1/1000 connections between TLS-capable (clients *and* servers) end up in an SSLv3 fallback. Hanno and Geoffrey point out this is often due to general network problems (e.g. packet loss) rather than middlebox TLS-intolerance. However I have heard, and Yngve seems to agree, that middlebox TLS-intolerance also contributes. Does anyone know more about this? Like: what portion of the above fallbacks are due to general network problems vs. TLS-intolerant middleboxes? (2) I suggested that TLS Extensions which do not require data in the ClientHello, and which are required for security, could follow the 5746 idiom of an SCSV alternative to the ClientHello extension for use in SSLv3 fallback. Geoffrey and Yngve suggest a different approach, where browsers disable SSLv3 fallback when talking to a hostname for which they expect one of these TLS Extensions. With a flakey network, browsers would retry TLS until they get through or give up. With TLS-intolerant middleboxes, Yngve suggests "standing firm and forcing the problematic servers/infrastructure to be updated". I see some problems with this: (a) With current proposals for CT or OCSP stapling, the requirement for an OCSP or CT response via TLS Extensions is signalled by the server's certificate, so is not known until *after* an SSLv3 fallback. Presumably the browser could cancel the SSL handshake and restart a TLS handshake at that point, but that wastes multiple round trips. (b) With TLS-layer pinning (like TACK), this proposal would prevent "active pins" from causing problems, but pin creation would still be impeded: Connections to not-yet-pinned sites could still suffer from SSLv3 fallbacks due to flakey networks or intolerant middleboxes, and not receive the pin assertion. (c) This proposal is guaranteed to fail with TLS-intolerant middleboxes, whereas the SCSV proposal has a good chance of working. (d) As far as "standing firm" and trying to drive these middleboxes off the Internet. I'm all for someone else trying that (CT? :-). But for TACK: If there's any significant number of these middleboxes, and we cause anything close to a 1/1000 failure rate, we simply won't be deployed. I'd be interested in hearing more about why people oppose the SCSV approach. We're nowhere close to exhaustion of the ciphersuite (or extension) registries. Is there some real problem with SCSVs, or does it just offend people's sense of the "proper way" to do things? Trevor From n.mavrogiannopoulos@gmail.com Fri Apr 5 14:31:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110021F98B7 for ; Fri, 5 Apr 2013 14:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcRT+W3eKYpD for ; Fri, 5 Apr 2013 14:31:02 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7C121F98A9 for ; Fri, 5 Apr 2013 14:31:02 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id z7so1558403eaf.31 for ; Fri, 05 Apr 2013 14:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=0tULzIGAoIiphZYUiwqxev0B2FrjkxkLu23EIfKXpdM=; b=PCqLbKTNueIhrzZg3az0zAF7hlmCPpYRJ8Omxg+dtfCNb4jqdZ8WIxRz+unOlNkXMq EMlHoyPuwA5o3Lys1cp0UUNXhk/c2BL262xrVsiS5jSlBOnjN0eGf0KhOG4bn/pu+vw3 hXnX/cv8djQDAezFkNjEmL1EF24OTgg9HlYc54AG9IuDEw6wyGVPwmWuOt1WAmVXUyNm 8uMVsNUHWsPRl90nm+GP+MnNM4vHSF3YFPdYzUNUYm/VKWgBc6F/qkWR7q9/lz4tPgmc wmUbhQLdl9AB+7zpMLDjQ/w3b5hAX45iMhVnSdhHVYdYXCcuk1IXByWsYffcYXBroa2P vmnA== X-Received: by 10.15.43.73 with SMTP id w49mr22894331eev.12.1365197461152; Fri, 05 Apr 2013 14:31:01 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f47sm17647444eep.13.2013.04.05.14.30.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 14:31:00 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <515F428E.2010900@gnutls.org> Date: Fri, 05 Apr 2013 23:30:54 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 21:31:06 -0000 On 04/05/2013 09:46 PM, Trevor Perrin wrote: > (c) This proposal is guaranteed to fail with TLS-intolerant > middleboxes, whereas the SCSV proposal has a good chance of working. [...] > I'd be interested in hearing more about why people oppose the SCSV > approach. We're nowhere close to exhaustion of the ciphersuite (or > extension) registries. Is there some real problem with SCSVs, or does > it just offend people's sense of the "proper way" to do things? I wouldn't expect the problem of failed TLS connections due to middle boxes or bad implementations to disappear by making a complex protocol even more complex. By having a protocol that offers more than a way to do things I'd expect an increase to the interoperability and failed connection issues we see today. More options for the same thing pretty much guarantees that there will be at least one implementation that will ship the non mainstream options untested. regards, Nikos From trevp@trevp.net Fri Apr 5 15:11:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58B721F98EB for ; Fri, 5 Apr 2013 15:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlaK27pqwKX0 for ; Fri, 5 Apr 2013 15:11:35 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id E07A721F98DC for ; Fri, 5 Apr 2013 15:11:34 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so1036464wib.2 for ; Fri, 05 Apr 2013 15:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=62smQxB2IuCYSJQEUfNXDvGwImzdg7X6ANMTV92Dqpk=; b=iqLrSb4QjJMDSIH6HuA8UcDvCY49fMLn4XDbjm3CI0qY04qZ4wxPkzo6BOlqel6Vuj oVwKWBt/XnDk5H7Y0hiqUIH6K5y+y2EGQqd+D604B68PsB+zuj8KT4954/fP0eGonv9/ v9KBLDwEIdD9ulPPel4lcGtcuGO008S4B6YThSk5Md3NrexLprHbwR4im5sPbQ4DmJTY Yb8D3Dx8DGUzAEDJuFIbbHZ+8GGMdAaIC2bOPVWCdTUiFUOO/iDgISrs0DKgOY3XVxKO jR+mCSHwTfZLBSarV1zwp4CDdBaBX57HOptLvat0a0ldxyr4qyoFBuvcXPM7/1yNHEXy CpXQ== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr19024247wjb.24.1365199893203; Fri, 05 Apr 2013 15:11:33 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 15:11:32 -0700 (PDT) X-Originating-IP: [173.11.71.218] In-Reply-To: <515F428E.2010900@gnutls.org> References: <515F428E.2010900@gnutls.org> Date: Fri, 5 Apr 2013 15:11:32 -0700 Message-ID: From: Trevor Perrin To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkAY2X3jrYoSWH6850bikNiuAntbaDWdJ3nHDY1i79dg6gU9+ApPUXkdzeoBDJdFW2w0wh6 Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:11:35 -0000 On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos wrote: > On 04/05/2013 09:46 PM, Trevor Perrin wrote: > > >> (c) This proposal is guaranteed to fail with TLS-intolerant >> middleboxes, whereas the SCSV proposal has a good chance of working. > > [...] >> I'd be interested in hearing more about why people oppose the SCSV >> approach. We're nowhere close to exhaustion of the ciphersuite (or >> extension) registries. Is there some real problem with SCSVs, or does >> it just offend people's sense of the "proper way" to do things? > > I wouldn't expect the problem of failed TLS connections due to middle > boxes or bad implementations to disappear by making a complex protocol > even more complex. If the problem is TLS-intolerant middleboxes, then allowing necessary handshake data to flow via SSLv3, using a mechanism that has worked for other extension data, should make the problem better. No? > By having a protocol that offers more than a way to do things I'd expect > an increase to the interoperability and failed connection issues we see > today. More options for the same thing pretty much guarantees that there > will be at least one implementation that will ship the non mainstream > options untested. This is pretty easy to test, the logic is simple: - client sends SCSV and/or empty ClientHello extension - on receiving SCSV and/or empty ClientHello extension, server sends ServerHello extension. This is even simpler than RFC5746, since for (CT, TACK, OCSP "must-staple") the ClientHello Extension could just be an empty signal, and the ServerHello contains a static response. This idiom is so simple it could be handled by an "extender file" interface: The site administrator could specify an "extender file" containing PEM-encoded TLS Extensions in the server config. Each PEM-encoded blob would contain a prefix specifying the TLS extension number and (optional) SCSV number. This would avoid the need for server-side code changes for any Extension that follows this idiom. So, we would only need to deploy this once into (OpenSSL, Apache, nginx, etc.). Does that alleviate your concern? I've discussed this with Ben Laurie and begun an OpenSSL patch, which at least CT and TACK could take advantage of. It doesn't allow SCSV specification yet, but I'm wondering if it should: https://github.com/trevp/openssl_extender Trevor From paul.hoffman@vpnc.org Fri Apr 5 15:19:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B429C21F9922 for ; Fri, 5 Apr 2013 15:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OerGQNXcYksA for ; Fri, 5 Apr 2013 15:19:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 205BD21F977F for ; Fri, 5 Apr 2013 15:19:22 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r35MJ4Vq079015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Apr 2013 15:19:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Fri, 5 Apr 2013 15:19:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <515F428E.2010900@gnutls.org> To: Trevor Perrin X-Mailer: Apple Mail (2.1503) Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:19:22 -0000 On Apr 5, 2013, at 3:11 PM, Trevor Perrin wrote: > On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos = wrote: >> On 04/05/2013 09:46 PM, Trevor Perrin wrote: >>=20 >>=20 >>> (c) This proposal is guaranteed to fail with TLS-intolerant >>> middleboxes, whereas the SCSV proposal has a good chance of working. >>=20 >> [...] >>> I'd be interested in hearing more about why people oppose the SCSV >>> approach. We're nowhere close to exhaustion of the ciphersuite (or >>> extension) registries. Is there some real problem with SCSVs, or = does >>> it just offend people's sense of the "proper way" to do things? >>=20 >> I wouldn't expect the problem of failed TLS connections due to middle >> boxes or bad implementations to disappear by making a complex = protocol >> even more complex. >=20 > If the problem is TLS-intolerant middleboxes, then allowing necessary > handshake data to flow via SSLv3, using a mechanism that has worked > for other extension data, should make the problem better. No? No. You assume that the "TLS-intolerant middleboxes" actually understand = real SSLv3, not some very limited and old picture of it. You might fix = the problem for *some* middleboxes, at the cost of making the protocol = even more fragile. --Paul Hoffman= From trevp@trevp.net Fri Apr 5 15:47:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DCB21F98D6 for ; Fri, 5 Apr 2013 15:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=1.275, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOjPhU00fZ7Z for ; Fri, 5 Apr 2013 15:47:17 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8C21F986D for ; Fri, 5 Apr 2013 15:47:17 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so4175440wgh.3 for ; Fri, 05 Apr 2013 15:47:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NizcH/pve9a9c2geO0hCo4/nfRD+kQ/vCu2FKnZjTGg=; b=GgWx09goAxLiUlat+tRNNq4U/GUJ3fJ8bN9aB8RebTdcjT8xDmCW/yBXNCvuIABTxQ JJ8s25YP9cOzCwHjRjaHv3RLHhKyI90oVT0KwuhP1Q0KKj8dPwcu1IfrF55CoAqWjEZ+ aYAzaYlV2Ojq2buWQBcxuvBkDsLgUCsMFJUbOy9pCQ9JX8Vao1HIov0LujmNZMxLetPp 2RilxiqdWbMmTCHV0v3LTid0NC9Yvn7pJAdDLElfXcCVBeeqWvK+Db3A0mhKss5WuQ17 Opm79+C+xd7hNIk2kmwLWlbnl4F5w7KyU3q5KP1M8mFTZ1eo9y4Yb/Ing8p84A9lIpig iXBg== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr19131575wjb.24.1365202036392; Fri, 05 Apr 2013 15:47:16 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 15:47:16 -0700 (PDT) X-Originating-IP: [173.11.71.218] In-Reply-To: References: <515F428E.2010900@gnutls.org> Date: Fri, 5 Apr 2013 15:47:16 -0700 Message-ID: From: Trevor Perrin To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl3JaFtVP3XY/wqgi63AffKEdcnELWmYgHbNpw4mmZRjlEHM9WAsr0hpGcjN4Ed1IS7+AvN Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:47:18 -0000 On Fri, Apr 5, 2013 at 3:19 PM, Paul Hoffman wrote: > On Apr 5, 2013, at 3:11 PM, Trevor Perrin wrote: >> On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos wrote: >>> >>> I wouldn't expect the problem of failed TLS connections due to middle >>> boxes or bad implementations to disappear by making a complex protocol >>> even more complex. >> >> If the problem is TLS-intolerant middleboxes, then allowing necessary >> handshake data to flow via SSLv3, using a mechanism that has worked >> for other extension data, should make the problem better. No? > > No. You assume that the "TLS-intolerant middleboxes" actually understand real SSLv3, not some very limited and old picture of it. You might fix the problem for *some* middleboxes, at the cost of making the protocol even more fragile. Well, we're agreed this might fix the problem for some middleboxes. :-) The alternative, in the TLS-intolerant middlebox case, is... what, exactly? Fail to connect? Trevor From yngve@spec-work.net Fri Apr 5 16:18:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24921F8F86 for ; Fri, 5 Apr 2013 16:18:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oviQNIF7Q1X for ; Fri, 5 Apr 2013 16:18:38 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2F16921F8F33 for ; Fri, 5 Apr 2013 16:18:38 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:57990 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UOFu0-0003ZC-BH for tls@ietf.org; Sat, 06 Apr 2013 01:18:36 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <515F428E.2010900@gnutls.org> Date: Sat, 06 Apr 2013 01:18:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 23:18:39 -0000 On Sat, 06 Apr 2013 00:47:16 +0200, Trevor Perrin wrote: > On Fri, Apr 5, 2013 at 3:19 PM, Paul Hoffman > wrote: >> On Apr 5, 2013, at 3:11 PM, Trevor Perrin wrote: >>> On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos >>> wrote: >>>> >>>> I wouldn't expect the problem of failed TLS connections due to middle >>>> boxes or bad implementations to disappear by making a complex protocol >>>> even more complex. >>> >>> If the problem is TLS-intolerant middleboxes, then allowing necessary >>> handshake data to flow via SSLv3, using a mechanism that has worked >>> for other extension data, should make the problem better. No? >> >> No. You assume that the "TLS-intolerant middleboxes" actually >> understand real SSLv3, not some very limited and old picture of it. You >> might fix the problem for *some* middleboxes, at the cost of making the >> protocol even more fragile. > > Well, we're agreed this might fix the problem for some middleboxes. :-) > > The alternative, in the TLS-intolerant middlebox case, is... what, > exactly? Fail to connect? Given that we don't know what these middleboxes react to, using SCSVs might work for some, but not others, because those could be checking for "known" cipher suites; some might even consider a unknown cipher suite to be an "attack". (Note: There are apparently middleboxes that do not allow TLS 1.1 or TLS 1.2 connections to be established, so if these middleboxes block on "unknown" protocol versions, I would not be surprised if some don't fail to pass "unknown" cipher suites, as well) That the Renego SCSV *seem* to have worked, does not mean that a new SCSV will work equally well. As Paul says, adding an SCSV system will add complexity, which might cause other problems, including differences between how implementations behave when seeing them. Example: There are a number of servers, F5 BigIP among them, that does not tolerate a combination of the Renego Information Extension and the Renego SCSV in the same handshake. The danger is that by using an SCSV we might "fix" the problem for one group of users, and completely break SSL/TLS for another group of users, the size of which might conceivably be substantially larger than the other group, and there is no way to find out which it is going to be before the system is deployed. For that matter, using an SCSV to indicate an extension and to bypass an interfering middlebox assumes that the middlebox will permit the associated handshake extension to be passed back to the client. I don't think that is a certainty, even if it seems to have worked for Renego (but worst case: that might be due to the middle boxes being updated to handle that particular extension, since it was a security protocol patch) Bottom line: Assume that Murphy's Law applies; if something can be done wrong, then somebody will do it wrong. And in terms of these middleboxes, somebody have, but we don't know how many ways they have done it wrong. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From trevp@trevp.net Fri Apr 5 21:41:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B6321F9797 for ; Fri, 5 Apr 2013 21:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cDtb4waiZmF for ; Fri, 5 Apr 2013 21:41:34 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE821F9757 for ; Fri, 5 Apr 2013 21:41:34 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id r3so3374639wey.17 for ; Fri, 05 Apr 2013 21:41:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6wHI190n/JuCX/yKZDOcMgtw2SP2Lclii0hspyQ2/+E=; b=KfluGTR1e+MtOb9iZ+rTSRauIqrxAeNrNaOh+azHD1puuVA7TtVSpUXAAPGL44BJes stsIMVbSSx9Q+27HiqHDt5B1k4ZQ7VeYvZDuBXoGiEmFVePbD/HdlnylrnSe3NEg7qw+ Wyfp2QbiCvF5LPC6qVPKZkrlGAcHJc9Jy+hhexOkPMhxPYLATILS5/WzT5RplC7pnMqS bZCKU/oTS75jS7uNsrnv79MfRtLs0hhXTiSrhLVbOHt4RxI75hoELOaj39a7Qawzwzsd c3n8NdKYeofSzwdTIrm1wAzNKbOdlUl67qcP4mA7H7frSN7tAx180iVfZb7rcEZV01PG yDDg== MIME-Version: 1.0 X-Received: by 10.180.87.170 with SMTP id az10mr2449718wib.3.1365223293499; Fri, 05 Apr 2013 21:41:33 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 21:41:33 -0700 (PDT) X-Originating-IP: [173.164.206.245] In-Reply-To: References: <515F428E.2010900@gnutls.org> Date: Fri, 5 Apr 2013 21:41:33 -0700 Message-ID: From: Trevor Perrin To: "Yngve N. Pettersen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk05H9vgJvp4XRptncT+NMIXj9HYF4OOZskdPC2p97896sX3mwNFdTLMZNVS30+O5cFxQON Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 04:41:35 -0000 On Fri, Apr 5, 2013 at 4:18 PM, Yngve N. Pettersen wrote: > On Sat, 06 Apr 2013 00:47:16 +0200, Trevor Perrin wrote: >> On Fri, Apr 5, 2013 at 3:19 PM, Paul Hoffman >> wrote: >>> No. You assume that the "TLS-intolerant middleboxes" actually understand >>> real SSLv3, not some very limited and old picture of it. You might fix the >>> problem for *some* middleboxes, at the cost of making the protocol even more >>> fragile. >> >> >> Well, we're agreed this might fix the problem for some middleboxes. :-) >> >> The alternative, in the TLS-intolerant middlebox case, is... what, >> exactly? Fail to connect? > > > Given that we don't know what these middleboxes react to, using SCSVs might > work for some, but not others, Agreed. > The danger is that by using an SCSV we might "fix" the problem for one group > of users, and completely break SSL/TLS for another group of users Suppose the SCSV is only allowed in the specific case of an SSLv3 fallback where an extension response is required or the connection will fail (due to a requirement for TACK, CT, or OCSP). In this case, it can't break anything because the connection is already going to be broken. It's not guaranteed to work, but there's evidence it might. Does that address this concern? > Bottom line: Assume that Murphy's Law applies; if something can be done > wrong, then somebody will do it wrong. And in terms of these middleboxes, > somebody have, but we don't know how many ways they have done it wrong. Sure. What data do we have? Does the estimate of 1/1000 connections between (TLS-capable clients and servers) getting an SSL3 fallback seem right to you? Do you have any idea how much of that is general network problems vs. middlebox problems? Trevor From n.mavrogiannopoulos@gmail.com Sat Apr 6 02:23:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7A21F8D8C for ; Sat, 6 Apr 2013 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl9P40pSniRZ for ; Sat, 6 Apr 2013 02:23:04 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2E621F8D86 for ; Sat, 6 Apr 2013 02:23:03 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so1657103ead.41 for ; Sat, 06 Apr 2013 02:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=FgIHue/huZUoO4G2oMnkqDZuyq6jVBtljY/UymnVUDc=; b=bRSw+UYluHnkk0+8dUIzWdWrciAhOtQC9NMb+d2wgqvyOztfl99ybc6NhAVwtvvk+1 A1Xj2RgjQY6diTRQBLhpqYM4/ycBo8+Gp7ZvSXp+Nry3XZYhVUlIezDsbA4kuYbYFskp S3VLSIV1tlTt1Fewlhrw4v84nge19I4T6oUHR2J6IfO1OQs80rZ9R5iWaxO87wOJsWFg oISKNvltmdpIEo6RxKAypMNVgI44SkEoJquMQDhTFmX+kKbHAZbY0l62OcWiys1/eWkP bsYI2we+znQL7MGgYV+L7axWWJ5DoBN1gPtFyjK8/XKYb0F5U01fydUygcrDGH8D4ybs tTDQ== X-Received: by 10.15.76.132 with SMTP id n4mr8249237eey.16.1365240182399; Sat, 06 Apr 2013 02:23:02 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id cd3sm10089340eeb.6.2013.04.06.02.23.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Apr 2013 02:23:01 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <515FE96F.4000007@gnutls.org> Date: Sat, 06 Apr 2013 11:22:55 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Trevor Perrin References: <515F428E.2010900@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:23:05 -0000 On 04/06/2013 12:11 AM, Trevor Perrin wrote: >>> (c) This proposal is guaranteed to fail with TLS-intolerant >>> middleboxes, whereas the SCSV proposal has a good chance of working. >> [...] >>> I'd be interested in hearing more about why people oppose the SCSV >>> approach. We're nowhere close to exhaustion of the ciphersuite (or >>> extension) registries. Is there some real problem with SCSVs, or does >>> it just offend people's sense of the "proper way" to do things? >> >> I wouldn't expect the problem of failed TLS connections due to middle >> boxes or bad implementations to disappear by making a complex protocol >> even more complex. > If the problem is TLS-intolerant middleboxes, then allowing necessary > handshake data to flow via SSLv3, using a mechanism that has worked > for other extension data, should make the problem better. No? It may reduce the error failures in some middle-boxes. We cannot be sure about that because we don't know the actual reason for failure, we just speculate. Nevertheless your focus on SSL 3.0 is also wrong. Given the number of security flaws known to that protocol it may be more productive for the WG to work towards phasing it out. >> By having a protocol that offers more than a way to do things I'd expect >> an increase to the interoperability and failed connection issues we see >> today. More options for the same thing pretty much guarantees that there >> will be at least one implementation that will ship the non mainstream >> options untested. > This is pretty easy to test, the logic is simple: > - client sends SCSV and/or empty ClientHello extension > - on receiving SCSV and/or empty ClientHello extension, server sends > ServerHello extension. What would you do at the case a middle box only accepts extension A using SCSV but extension B is only accepted as ClientHello extension? Since what are you countering of is bugs, you can never be sure what the next bug would be. Bugs should be treated as bugs. > This idiom is so simple it could be handled by an "extender file" The previous extension mechanism was even simpler but still there were several middle-boxes that got it wrong. regards, Nikos From yngve@spec-work.net Sat Apr 6 05:14:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A69421F8E04 for ; Sat, 6 Apr 2013 05:14:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUOcgbiF1SC1 for ; Sat, 6 Apr 2013 05:14:24 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id B7B0F21F8CEB for ; Sat, 6 Apr 2013 05:14:23 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:51110 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UOS0k-00070A-Od for tls@ietf.org; Sat, 06 Apr 2013 14:14:22 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "tls@ietf.org" References: <515F428E.2010900@gnutls.org> Date: Sat, 06 Apr 2013 14:14:06 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 12:14:26 -0000 On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin wrote: >> The danger is that by using an SCSV we might "fix" the problem for one >> group >> of users, and completely break SSL/TLS for another group of users > > Suppose the SCSV is only allowed in the specific case of an SSLv3 > fallback where an extension response is required or the connection > will fail (due to a requirement for TACK, CT, or OCSP). > > In this case, it can't break anything because the connection is > already going to be broken. It's not guaranteed to work, but there's > evidence it might. > > Does that address this concern? No, it does not. The reason it does not, is that once the client have fallen back to SSL v3 due to version and/or extension intolerance in the server and/or the middleboxes you can either use a plain SSL v3 or a SSL v3 with the proposed SCSVs. Assuming a plain SSLv3 does not work, then the SCSV will not work either. OTOH, if the the plain SSLv3 works OK, we do not at present know if the SCSV variant will work in all cases. even if the SCSV is passed through, we do not know if the Server Hello extension will be passed through on the way back. So, using an SCSV in the SSL v3 handshake do risk breaking a handshake that would otherwise have completed. I have no idea how likely that problem is, but as Nikos pointed out, this is trying to accommodate bugs in implementations, but we don't have a complete list of the bugs that have been created in these implementations. >> Bottom line: Assume that Murphy's Law applies; if something can be done >> wrong, then somebody will do it wrong. And in terms of these >> middleboxes, >> somebody have, but we don't know how many ways they have done it wrong. > > Sure. What data do we have? > > Does the estimate of 1/1000 connections between (TLS-capable clients > and servers) getting an SSL3 fallback seem right to you? Actually, the numbers I have been informed of is that the number of completed connections forced to SSLv3 is less than half that. The number of affected renego patched *servers* in my sample is in the 0.2% range IIRC, but number of server does not translate to actual usage in number of connection by users. The much lower fraction of downgraded connections indicate that the servers I've detected are not frequently accessed. (BTW, the total number of intolerant servers is about 1.5%, most of them not renego patched). > Do you have any idea how much of that is general network problems vs. > middlebox problems? All the discoveries about this problem have been made by Google. I know Google was considering doing some tests to try to ferret out how much of the problem was due to middleboxes or the servers, but I do not know if they have done so yet, or what the results were, if they did. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From trevp@trevp.net Sat Apr 6 09:59:08 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC321F8499 for ; Sat, 6 Apr 2013 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7snQlVCv5Zsa for ; Sat, 6 Apr 2013 09:59:07 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA8521F8498 for ; Sat, 6 Apr 2013 09:59:06 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t57so3538117wey.32 for ; Sat, 06 Apr 2013 09:59:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9UUzkT7x9CQM/SPER8Rjrb/LYmoBMtTsC+aSV5BoY3Q=; b=OHmHhXwbgzexigZRIWv9vNPZYgM3q7NAaLBSi7ouxM3BAJsfZQQRZHuRK7I3Ass4O/ P3FPggZ2cLVRMYns69zbkiQvFFRSHWgXiBzjMWPwZsS8E8bUZcVFFLiGNLmuk7rUJJCh 5SwGVbERW3WDF2yqY3HzqkBTI8ScmNjaIyY6hUrS+tXIbjHK5uEazu5Iz2B9GPus7vYV C2XP1YTPWbs01eC6RZXIJnKEp1+v8ZQ+5npGNyxHjIJeiRgocq8uKeilp2IZDYhlrpDf n1okFXEEyaYM85X2eVNmev9gHHSiFhJkKy2ZmH/pM0ofMJcWzN6Iq1MsxNOiKEzK5NMm nu7g== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr4888662wib.22.1365267546242; Sat, 06 Apr 2013 09:59:06 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Sat, 6 Apr 2013 09:59:06 -0700 (PDT) X-Originating-IP: [173.164.206.245] In-Reply-To: References: <515F428E.2010900@gnutls.org> Date: Sat, 6 Apr 2013 09:59:06 -0700 Message-ID: From: Trevor Perrin To: "Yngve N. Pettersen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQks8FTnhERcCKasMzxPTwPzI2U3bOR9bP2IDnImZ8KjLYRsQOhj8Qd0CNKxOYkDLr+eoIPd Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 16:59:08 -0000 On Sat, Apr 6, 2013 at 5:14 AM, Yngve N. Pettersen wrote: > On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin wrote: >> >> Suppose the SCSV is only allowed in the specific case of an SSLv3 >> fallback where an extension response is required or the connection >> will fail (due to a requirement for TACK, CT, or OCSP). >> >> In this case, it can't break anything because the connection is >> already going to be broken. It's not guaranteed to work, but there's >> evidence it might. >> >> Does that address this concern? > > > No, it does not. [...] > we do not at present know if the SCSV > variant will work in all cases. [...] > So, using an SCSV in the SSL v3 handshake do risk breaking a handshake that > would otherwise have completed. No, you missed my point. I was proposing using SCSVs only in the case that an SSLv3 fallback is necessary, and the browser *REQUIRES* some data from the server (TACK, CT, OCSP), or the browser will refuse the connection. Example: Suppose a browser has an active TACK pin for a domain, but sending a TLS ClientHello to that domain results in a TCP reset. Since the TACK pin exists, the browser can assume it is not contacting a TLS-intolerant server. But a TLS-intolerant middlebox seems like a possibility (though we still need more data on prevalence). I believe current browsers would want to try an SSLv3 fallback in this case, to attempt to work around the interference. However! SSLv3 fallback is pointless here unless the browser has some chance of signalling that it requires a tack, and receiving it. I am proposing giving this a chance of working, by using the same SCSV / ServerHello Extension idiom that has worked for RFC 5746. Of course, this might not work for any specific middlebox! But if the middlebox allows unknown ciphersuites and data at the end of the SSL ServerHello, then it will. And if the middlebox has been patched to whitelist the specific 5746 SCSV and ServerHello extension, that implies it could be upgraded for new uses of this idiom as well. Trevor From yngve@spec-work.net Sat Apr 6 12:05:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EE121F8BE9 for ; Sat, 6 Apr 2013 12:05: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WrL7cqjHVVh for ; Sat, 6 Apr 2013 12:05:05 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44C21F8BE0 for ; Sat, 6 Apr 2013 12:05:03 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:55767 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UOYQA-00063d-A7 for tls@ietf.org; Sat, 06 Apr 2013 21:05:02 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "tls@ietf.org" References: <515F428E.2010900@gnutls.org> Date: Sat, 06 Apr 2013 21:04:45 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 19:05:06 -0000 On Sat, 06 Apr 2013 18:59:06 +0200, Trevor Perrin wrote: > On Sat, Apr 6, 2013 at 5:14 AM, Yngve N. Pettersen > wrote: >> On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin >> wrote: >>> >>> Suppose the SCSV is only allowed in the specific case of an SSLv3 >>> fallback where an extension response is required or the connection >>> will fail (due to a requirement for TACK, CT, or OCSP). >>> >>> In this case, it can't break anything because the connection is >>> already going to be broken. It's not guaranteed to work, but there's >>> evidence it might. >>> >>> Does that address this concern? >> >> >> No, it does not. > [...] >> we do not at present know if the SCSV >> variant will work in all cases. > [...] >> So, using an SCSV in the SSL v3 handshake do risk breaking a handshake >> that >> would otherwise have completed. > > No, you missed my point. > > I was proposing using SCSVs only in the case that an SSLv3 fallback is > necessary, and the browser *REQUIRES* some data from the server (TACK, > CT, OCSP), or the browser will refuse the connection. > > Example: Suppose a browser has an active TACK pin for a domain, but > sending a TLS ClientHello to that domain results in a TCP reset. > > Since the TACK pin exists, the browser can assume it is not contacting > a TLS-intolerant server. In which case the client knows what the highest supported version, and the extension tolerance, for the server, as you say. In any such case the client should IMNSHO assume that it is being subjected to a Man In the Middle attack, using a version rollback attack, and abort the connection. The client should in such a situation not permit itself to downgrade the security of the connection, which includes _not_ attempting to set up the connection using SSL v3, or any TLS version lower than what was used the last time it had a successful connection. That is BTW, the principle embedded in my version rollback removal draft , which uses the server's support of the Renego extension as a proxy indication to determine full version and extension tolerance, and then use that information to assume that any failure to negotiate a connection, when signaling the client's highest supported version with full extension support in the handshake, means that the connection is being subjected to a version rollback attack, and terminate the connection attempt rather than roll back to an older version. > But a TLS-intolerant middlebox seems like a > possibility (though we still need more data on prevalence). I believe > current browsers would want to try an SSLv3 fallback in this case, to > attempt to work around the interference. > > However! SSLv3 fallback is pointless here unless the browser has some > chance of signalling that it requires a tack, and receiving it. > > I am proposing giving this a chance of working, by using the same SCSV > / ServerHello Extension idiom that has worked for RFC 5746. > > Of course, this might not work for any specific middlebox! But if the > middlebox allows unknown ciphersuites and data at the end of the SSL > ServerHello, then it will. And if the middlebox has been patched to > whitelist the specific 5746 SCSV and ServerHello extension, that > implies it could be upgraded for new uses of this idiom as well. It could be that they have been patched, if there was a problem, but the Renego issue was a high profile security issue, and its solution was one that was being deployed in all clients within a very short period of time. Failure to patch any troublesome middleboxes would have caused severe problems for users. I doubt any such incentive to patch will be present for most other extensions of TLS, particularly if the usage of the SCSV depends on the server being known to support the new feature. In other words: If there is a problem in this area, you should not assume that it will be quickly fixed, at least not before general server support is past 50% or an even higher percentage of high traffic sites use it, which might take several years to be achieved. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From rob.stradling@comodo.com Mon Apr 8 06:08:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA0821F84D4 for ; Mon, 8 Apr 2013 06:08:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuyW0J35Kgs8 for ; Mon, 8 Apr 2013 06:08:42 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id C071C21F9397 for ; Mon, 8 Apr 2013 06:08:40 -0700 (PDT) Received: (qmail 18577 invoked from network); 8 Apr 2013 13:08:37 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Apr 2013 13:08:37 -0000 Received: (qmail 4245 invoked by uid 1000); 8 Apr 2013 13:08:37 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 08 Apr 2013 14:08:37 +0100 Message-ID: <5162C154.1010202@comodo.com> Date: Mon, 08 Apr 2013 14:08:36 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> In-Reply-To: <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:08:44 -0000 On 29/03/13 18:34, Hannes Tschofenig wrote: > Hi Rob, > > I worked on a document update and the current snapshot can be found here: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt > > Let me know if that fits your needs. Hi Hannes. You propose treating the entire CertificateStatus message as a single CachedObject, but I'd like to propose a finer-grained approach: treat each OCSP Response as a separate CachedObject. Here's why... - A number of browsers/OSes already implement OCSP Response caches, and I think it'd make sense for these caches to be reusable in the context of Cached-Info. - It's common for OCSP Responses for Intermediate certificates to be valid for much longer than OCSP Responses for End-entity certificates. Also, it's common for clients to encounter multiple End-entity certificates issued by the same Intermediate certificate. For these reasons, it will often be the case that a client has already cached the OCSP Response for the Intermediate(s) and will therefore only need the server to send the OCSP Response for the End-entity certificate. Your draft already permits clients to send multiple CachedObject attributes of the same CachedInformationType, so I don't see any issues with the client->server part of my approach. For the server->client part, the Multi-Stapling draft [1] already allows some of the OCSP Responses to be omitted... "Individual elements of the list MAY have a length of 0 (zero) bytes" ...although the rest of that sentence is problematic w.r.t. my approach: ", if the server does not have the OCSP response for that particular certificate stored, in which case, the client MUST act as if a response was not received for that particular certificate." Also, the following paragraph in the Cached-Info draft is problematic w.r.t. my approach: "The server MUST NOT include more than one fingerprint for a single information element, i.e., at maximum only one CachedObject structure per replaced information is provided." I realize that time is running out to get changes made to the Multi-Stapling draft before publication as an RFC, and I realize that my approach would make the Cached-Info draft more complicated. However, I think it'd be worth the effort. What does anybody else think? [1] http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ > Ciao > Hannes > > On Mar 28, 2013, at 11:23 PM, Rob Stradling wrote: > >> On 28/03/13 18:41, Hannes Tschofenig wrote: >>> Hi Sean, >>> >>> It addresses all open issues we had at the IETF meeting. >>> >>> It does not yet contain the text for adding the OCSP response caching, as suggested by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >>> I could propose some text by tomorrow since I believe it is useful functionality. >> >> Hannes, >> >> For Multi-Stapling, there will be cases where a TLS client has previously seen the OCSP Response(s) for the Intermediate(s) but not yet seen the OCSP Response for the End-entity cert. >> >> It would be useful in such cases if Cached-Info would enable the TLS server to only have to send the OCSP Response(s) that the TLS client hasn't previously cached. >> >>> Ciao >>> Hannes >>> >>> On Mar 28, 2013, at 7:21 PM, Sean Turner wrote: >>> >>>> Does this version address all known outstanding issues? >>>> >>>> spt >>>> >>>> On 3/28/13 3:29 AM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting. >>>>> >>>>> The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >>>>> >>>>> Ciao >>>>> Hannes -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From yngve@spec-work.net Mon Apr 8 06:58:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3358121F95EA for ; Mon, 8 Apr 2013 06:58:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atvHH33IX3Vy for ; Mon, 8 Apr 2013 06:58:15 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4977521F95DB for ; Mon, 8 Apr 2013 06:58:15 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:49736 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPCaK-0005cL-U2; Mon, 08 Apr 2013 15:58:12 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Hannes Tschofenig" , "Rob Stradling" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> Date: Mon, 08 Apr 2013 15:58:08 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <5162C154.1010202@comodo.com> User-Agent: Opera Mail/12.15 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:58:16 -0000 On Mon, 08 Apr 2013 15:08:36 +0200, Rob Stradling wrote: > On 29/03/13 18:34, Hannes Tschofenig wrote: >> Hi Rob, >> >> I worked on a document update and the current snapshot can be found >> here: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt >> >> Let me know if that fits your needs. > > Hi Hannes. You propose treating the entire CertificateStatus message as > a single CachedObject, but I'd like to propose a finer-grained approach: > treat each OCSP Response as a separate CachedObject. Here's why... > - A number of browsers/OSes already implement OCSP Response caches, > and I think it'd make sense for these caches to be reusable in the > context of Cached-Info. > - It's common for OCSP Responses for Intermediate certificates to be > valid for much longer than OCSP Responses for End-entity certificates. > Also, it's common for clients to encounter multiple End-entity > certificates issued by the same Intermediate certificate. For these > reasons, it will often be the case that a client has already cached the > OCSP Response for the Intermediate(s) and will therefore only need the > server to send the OCSP Response for the End-entity certificate. I am opposed to mixing in content sent by other servers, because it could be a privacy violation since it would leak information about which CAs are used by the sites the user have visited. The information might change relatively often, but it could still leak information to the other sites. Also, the number of entries in the list sent in the Client Hello could quickly become relatively large, since a client could easily encounter dozens of intermediate CAs in a session. The only way something like this would work without becoming a security problem is that the client would first know that the server is using the same intermediate CA as one or more other servers it have visited, which means that the server must send the entire response anyway, so there is no saving of bytes on the wire. Optimizing storage on the client is a separate matter, best left to the implementers. IMO the Cached Info extension can *only* concern itself with information received from the current server, *never* what has been received by another server. It might be that this should be spelled out in the spec, perhaps in the security considerations, at least. In a worst case scenario such a multi-server caching concept could lead to a "TLS Cached Info" super cookie that can be used to track a user across multiple unrelated websites, which is conceivable in the case of multi-stapling (and server certificates, too). How: In addition to the chained website certificates add a separate certificate among the certificates sent to the client, which is configured for OCSP. Since the multi-stapling system is linked to the sequence of certificates in the Server Certificate message, not the actual certificate chain being validated, the extra OCSP response could be used to uniquely identify the user, at least for the current session. Doing so might be computationally expensive, if the extra entry is signed, but since it is for a certificate that is not validated .... why should it be signed? -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From agl@google.com Mon Apr 8 08:10:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CC121F9816 for ; Mon, 8 Apr 2013 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yss8Y3hJDHp9 for ; Mon, 8 Apr 2013 08:10:56 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 805E221F9798 for ; Mon, 8 Apr 2013 08:10:49 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so7095210iec.4 for ; Mon, 08 Apr 2013 08:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nUybnuUN85QTNOM1RxWdLeCIq9mAv7Ry0JxZaYHdVoY=; b=HlRlj2HreDkUHwIVzy9yb/TjEH2bW4OJF8o4H5I5bSTMTrBw+qGSp36et9XSsKlOee 8xWsV68XKLWxaVmxw8wPN4Q+TyPQIS/HVeXr64tfQswdf91KxDCEeYeg0Oj9p/X5ylcR Onb8DoEl9clJ9rGsUhj3nK5e13pd76oVZFJY9JYxh66RzekfbTvqOt6+IN9TX5AtpWSv 2fQtxew9UMWOnl9314dxP+zgN/2nBwCbuDFjVBugN8x7uItyQXo+i6617lPHKH7BLFp/ t6LJurrr0sdlDaTr4FM8SNn/Y66giQKb0FWXkqpzcJV3BIQBqTzEwtZDao3Y8AlOkcMB VL8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=nUybnuUN85QTNOM1RxWdLeCIq9mAv7Ry0JxZaYHdVoY=; b=bh4g/fsyjwZQ+6IlClAoA2pyTZT1Z9nmSbZkY/59O/SxOSNK8BLbZdWldT40ElwRjX EyV453tvGoeB+v6/JNkBO2V0egUR7tSxmUnTFio2OtiT2PR7TtGT06lJjSkQG0eXVwSs 5vofrOG+txlSHD3XYOQd7kM5Mbi43lZ5PQNx/gL2d3zmJ8hU7JHooxFzLy+WjsUFdUVf +a/mp1/G3UyhQua4mm4Uv3Wkldvc2LnHOaKj/9/piLAuZJkK9L2WG1Kv27mV6pVZYlVB U3KQ4HvSDnlY+3Q/SIPZ9u9j56u1Vp2r8oOjSumn3Ckz5uK8EPIa8nnvxQC7Dl3Ua8XN eN4A== MIME-Version: 1.0 X-Received: by 10.50.150.167 with SMTP id uj7mr7345070igb.1.1365433843109; Mon, 08 Apr 2013 08:10:43 -0700 (PDT) Received: by 10.231.229.6 with HTTP; Mon, 8 Apr 2013 08:10:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 11:10:43 -0400 Message-ID: From: Adam Langley To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlOJJCcHQbCJOooB3UQI9RA9vHssAKoyoaIuOakUAqGhZrsxvnxVwJUAx7G08J/67fNmtfNAB4n2FKOxtEwCVB/dkrrqD9gkKSqT7u2SC3i/dpw6/Qm/xB6TX2qnD5UL7m/aMaxAZpMHgWprLg8KxmxINB7b0/DycorBtEUUoUtMG15gX3lbQuQyb71shYjU7rLo6Bm Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 15:10:58 -0000 On Thu, Apr 4, 2013 at 5:54 PM, Geoffrey Keating wrote: > The name of one firewall which is confirmed to do this would make it a > lot more convincing... It's likely that some TLS connections failed > due to packet loss or a busy server and so the 'fallback' was a > mistake. NetASQ devices certainly did do it, at least in some configurations. Hopefully that has been fixed since I contacted them about it, but I'm sure that not every customer has updated etc. At the moment Chrome has a two-step fallback: TLS 1.1 -> TLS 1.0 and then to SSLv3. From Chrome to Google (i.e. TLS 1.1 capable endpoints) we see 0.1% of connections doing both fallbacks and then connecting successfully. Of course, it is possible that this is due to transient networking issues, but it seems like a rather high number for that. (In contrast we see 0.3% doing just the first fallback) Cheers AGL From wwwrun@rfc-editor.org Wed Mar 27 09:18:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A2521F9096 for ; Wed, 27 Mar 2013 09:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viAd7fZ4b9ER for ; Wed, 27 Mar 2013 09:18:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 66EEC21F90F1 for ; Wed, 27 Mar 2013 09:18:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C07E9B1E002; Wed, 27 Mar 2013 09:18:19 -0700 (PDT) To: dtaylor@gnutls.org, thomwu@cisco.com, nmav@gnutls.org, trevp@trevp.net, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20130327161819.C07E9B1E002@rfc-editor.org> Date: Wed, 27 Mar 2013 09:18:19 -0700 (PDT) X-Mailman-Approved-At: Mon, 08 Apr 2013 09:18:41 -0700 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC5054 (3570) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:18:50 -0000 The following errata report has been submitted for RFC5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=3570 -------------------------------------- Type: Editorial Reported by: Nico Roeser Section: 2.5.1.3 Original Text ------------- 2.5.1.3. Unknown SRP User Name Corrected Text -------------- 2.5.1.3. Unknown SRP User Name Notes ----- Too many spaces in the heading. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5054 (draft-ietf-tls-srp-14) -------------------------------------- Title : Using the Secure Remote Password (SRP) Protocol for TLS Authentication Publication Date : November 2007 Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Mon Apr 8 09:55:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA6021F92C1; Mon, 8 Apr 2013 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDbzoQqhTnnn; Mon, 8 Apr 2013 09:55:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3521F9184; Mon, 8 Apr 2013 09:55:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408165522.15443.38417.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 09:55:22 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-applayerprotoneg-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:55:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Transport Layer Security (TLS) Application Layer Protoco= l Negotiation Extension Author(s) : Stephan Friedl Andrei Popov Filename : draft-ietf-tls-applayerprotoneg-00.txt Pages : 8 Date : 2013-04-05 Abstract: This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trevp@trevp.net Mon Apr 8 11:35:02 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C021F8E63 for ; Mon, 8 Apr 2013 11:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCDFPOJnylcj for ; Mon, 8 Apr 2013 11:35:01 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 17CF921F8783 for ; Mon, 8 Apr 2013 11:35:00 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so4175305wiw.2 for ; Mon, 08 Apr 2013 11:35:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LpCp1OnzwGDC/1xQKyp2NmX5+ajmmgrn/qsW/N9ZmqQ=; b=I9AuBbZU+dQQiKkUGv4jakKoK3NtaCtdFQrT/Yi0lBKvd2cCDaRoCGA7NEm5RdvOMm VWkRTjJhAQYrIWYTsy60x9AdNJ3pWSCB4sihHmOmJqAC1/kymza72s0iENIdiy1BpVM5 AD/4up7ePa30Dweh5YhqjkdDKnYllDqWxgg5Xtz1YF1jBTpa2Ozmm4cYJK4paKYeaMC1 BiwrlPT7eWx1imY6MyJBoEAq9o4eZkZ8UfKvjsGZLp4HUbC3KXu7pp7/Mi3K85iP1DmE J2DjQy+jCFr3n9f68XX9wAlzL9S9h7qNMCK5tMA7o+tgmu5o39QPIpoUB/rOQTED+SC0 1qFg== MIME-Version: 1.0 X-Received: by 10.194.104.168 with SMTP id gf8mr32987274wjb.58.1365446099653; Mon, 08 Apr 2013 11:34:59 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Mon, 8 Apr 2013 11:34:59 -0700 (PDT) X-Originating-IP: [173.164.206.245] In-Reply-To: References: <515F428E.2010900@gnutls.org> Date: Mon, 8 Apr 2013 11:34:59 -0700 Message-ID: From: Trevor Perrin To: "Yngve N. Pettersen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkhrda5sRWt+irTUzn4J/02l/vORfcykmuXp2koTB6ooB5+q59ihYIYnihRynEgYzYCS7oW Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:35:02 -0000 Hi Yngve, Thanks for the reference to your rollback prevention draft [1]. I've also seen the Eric Rescorla and Adam Langley proposals [2,3]. These all seem practical ways to enable a TLS-capable party suffering an SSLv3 fallback to detect that the other party is TLS-capable. I'd love to see any of them deployed, so such connections could be rejected. Browser makers could aso preload their browser with a list of TLS-capable sites (such as their own), and disable SSLv3 fallback for them. Hopefully these actions would force TLS-intolerant middleboxes to be replaced, so browsers could stop having to work-around them and this problem would disappear. However! Until this happens, I think new TLS enhancements must unfortunately try to be compatible with browser workaround behavior. So I'm proposing TACK (and similar proposals) could make use of SSLv3 SCSVS in a narrowly-scoped context: - Only in case of SSLv3 fallback - Only when additional data is required from the server or the connection will fail In the long-term, if TLS-intolerant middleboxes can be eliminated to the point that browsers *don't* need to support them, this case will cease to exist. At that point this mechanism will be unused and unneeded. As you and Nikos have pointed out, there is no guarantee that this mechanism will always work. However if deployed, we could gather statistics on it. Anyways, I'd love to hear a better proposal for handling this difficult and unfortunate case. But it's seeming like the best option for TACK (which is my immediate concern) would be to specify an SCSV mechanism. Does that seem reasonable? Trevor [1] http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/ [2] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html [3] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html On Sat, Apr 6, 2013 at 12:04 PM, Yngve N. Pettersen wrote: > On Sat, 06 Apr 2013 18:59:06 +0200, Trevor Perrin wrote: > >> On Sat, Apr 6, 2013 at 5:14 AM, Yngve N. Pettersen >> wrote: >>> >>> On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin >>> wrote: >>>> >>>> >>>> Suppose the SCSV is only allowed in the specific case of an SSLv3 >>>> fallback where an extension response is required or the connection >>>> will fail (due to a requirement for TACK, CT, or OCSP). >>>> >>>> In this case, it can't break anything because the connection is >>>> already going to be broken. It's not guaranteed to work, but there's >>>> evidence it might. >>>> >>>> Does that address this concern? >>> >>> >>> >>> No, it does not. >> >> [...] >>> >>> we do not at present know if the SCSV >>> variant will work in all cases. >> >> [...] >>> >>> So, using an SCSV in the SSL v3 handshake do risk breaking a handshake >>> that >>> would otherwise have completed. >> >> >> No, you missed my point. >> >> I was proposing using SCSVs only in the case that an SSLv3 fallback is >> necessary, and the browser *REQUIRES* some data from the server (TACK, >> CT, OCSP), or the browser will refuse the connection. >> >> Example: Suppose a browser has an active TACK pin for a domain, but >> sending a TLS ClientHello to that domain results in a TCP reset. >> >> Since the TACK pin exists, the browser can assume it is not contacting >> a TLS-intolerant server. > > > In which case the client knows what the highest supported version, and the > extension tolerance, for the server, as you say. > > In any such case the client should IMNSHO assume that it is being subjected > to a Man In the Middle attack, using a version rollback attack, and abort > the connection. The client should in such a situation not permit itself to > downgrade the security of the connection, which includes _not_ attempting to > set up the connection using SSL v3, or any TLS version lower than what was > used the last time it had a successful connection. > > That is BTW, the principle embedded in my version rollback removal draft > , > which uses the server's support of the Renego extension as a proxy > indication to determine full version and extension tolerance, and then use > that information to assume that any failure to negotiate a connection, when > signaling the client's highest supported version with full extension support > in the handshake, means that the connection is being subjected to a version > rollback attack, and terminate the connection attempt rather than roll back > to an older version. > > >> But a TLS-intolerant middlebox seems like a >> possibility (though we still need more data on prevalence). I believe >> current browsers would want to try an SSLv3 fallback in this case, to >> attempt to work around the interference. >> >> However! SSLv3 fallback is pointless here unless the browser has some >> chance of signalling that it requires a tack, and receiving it. >> >> I am proposing giving this a chance of working, by using the same SCSV >> / ServerHello Extension idiom that has worked for RFC 5746. >> >> Of course, this might not work for any specific middlebox! But if the >> middlebox allows unknown ciphersuites and data at the end of the SSL >> ServerHello, then it will. And if the middlebox has been patched to >> whitelist the specific 5746 SCSV and ServerHello extension, that >> implies it could be upgraded for new uses of this idiom as well. > > > It could be that they have been patched, if there was a problem, but the > Renego issue was a high profile security issue, and its solution was one > that was being deployed in all clients within a very short period of time. > Failure to patch any troublesome middleboxes would have caused severe > problems for users. > > I doubt any such incentive to patch will be present for most other > extensions of TLS, particularly if the usage of the SCSV depends on the > server being known to support the new feature. > > In other words: If there is a problem in this area, you should not assume > that it will be quickly fixed, at least not before general server support is > past 50% or an even higher percentage of high traffic sites use it, which > might take several years to be achieved. > > > -- > Sincerely, > Yngve N. Pettersen > > Using Opera's mail client: http://www.opera.com/mail/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Mon Apr 8 12:00:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52221F9771 for ; Mon, 8 Apr 2013 12:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClnPMKRgIm91 for ; Mon, 8 Apr 2013 12:00:32 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D613A21F9762 for ; Mon, 8 Apr 2013 12:00:30 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r38J0QiL002346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 21:00:26 +0200 (MEST) In-Reply-To: <20130404233402.6c91a9bf@melee> To: =?ISO-8859-1?Q?Hanno_B=F6ck?= Date: Mon, 8 Apr 2013 21:00:26 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20130408190026.0CA491A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:00:35 -0000 Hanno B=F6ck wrote: > > Trevor Perrin wrote: >> >> I've heard (anecdotally) that HTTPS between browsers and webservers >> who are both TLS-capable sometimes results in SSLv3 connections. >> Presumably this is due to firewall interference with the TLS >> handshake, causing browsers to retry an SSLv3 handshake. >=20 > This happens pretty often if you have a unreliable (e.g. mobile) > internet connection. Mozilla/nss-Bug about it: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D450280 >=20 > And it's a serious problem if you're using Server Name > Indication (SNI) for more than one SSL cert on one IP. The "solution" I > found for our case was that I found it tolerable today to disable SSLv3 > on the server side. However, I'm not really happy with that browser > fallback behaviour, it's a serious pitfall for the use of SNI. Looking at the discussion under the above bugzilla URL (and how long this has been dragging along) is quite disappointing. I've seen vaguely similar breakage in Microsoft SChannel when used by WinHTTP with lots of active scripting, occasionally causing white pages, stateful apps to get out-of-sync with the frontend and users to loose their input. I believe, that the effect is already properly described here: https://bugzilla.mozilla.org/show_bug.cgi?id=3D450280#c3 in that it can even happen with (reload). and "some" light in this response: https://bugzilla.mozilla.org/show_bug.cgi?id=3D450280#c13 mentioning that "reload" is technically a "stop+reload". The issue that seems to affect Firefox in the same fashion that it affects SChannel is that the fallback driving logic fails to distinguish between locally triggered aborts of a TLS handshake and aborts caused by the remote peer (unexpected remote connection closure, fatal TLS alert or MAC error during the TLS handshake). A timeout during the TLS handshake is **seperate** and harder to deal with. Active scripting, Users hitting or Reload, User navigation before a page has completed loading of all elements, (meta-)refresh before a page has completed loading of all elements and event-based active content that causes replacement of page data or navigation to other locations may all **LOCALLY** cause termination of an active TLS socket, and in arbitrary states of the communication -- sometimes during the handshake. When the TLS socket is locally aborted, this ought to neither invalidate the client-side TLS session cache entry, nor ought this to cause a fallback to a lower TLS protocol version. From what is described in the above bugzilla entry, it appears that FF might inappropriately perform a fallback when the connection is locally aborted (potentially limited to aborting during an active TLS handshake). Depending on what the TLS client memorizes about (prior) connections, a first change might be to make the purging of TLS sessions from the client-side TLS session cache less agressive, and not perform a protocol fallback to SSLv3 when there is an existing TLS session in the TLS session cache that was successfully established with TLS extensions in the ClientHello. -Martin From mrex@sap.com Mon Apr 8 12:33:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3377921F9408 for ; Mon, 8 Apr 2013 12:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiyKff1Brk5N for ; Mon, 8 Apr 2013 12:33:04 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 75AC821F93C4 for ; Mon, 8 Apr 2013 12:33:04 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r38JX3QA008271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 21:33:03 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Mon, 8 Apr 2013 21:33:02 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130408193302.E9B3F1A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:33:05 -0000 Yngve N. Pettersen wrote: > > That is BTW, the principle embedded in my version rollback removal draft > , > which uses the server's support of the Renego extension as a proxy > indication to determine full version and extension tolerance, and then use > that information to assume that any failure to negotiate a connection, > when signaling the client's highest supported version with full extension > support in the handshake, means that the connection is being subjected to > a version rollback attack, and terminate the connection attempt rather > than roll back to an older version. But you do realize that this idea has been killed by Microsoft shipping its goofed RSA premaster secret version (check) in Windows7 SChannel -- and Win7 SChannel with rfc5746 support has been in such a state of misery for almost 3 years now. -Martin From mrex@sap.com Mon Apr 8 12:40:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62CA21F8EE1 for ; Mon, 8 Apr 2013 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsA1YHETbDMd for ; Mon, 8 Apr 2013 12:40:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6056B21F8615 for ; Mon, 8 Apr 2013 12:40:19 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r38Je9xT005213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 21:40:09 +0200 (MEST) In-Reply-To: To: Geoffrey Keating Date: Mon, 8 Apr 2013 21:40:08 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130408194008.ED6D71A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:40:22 -0000 Geoffrey Keating wrote: > > > I've heard (anecdotally) that HTTPS between browsers and webservers > > who are both TLS-capable sometimes results in SSLv3 connections. > > Presumably this is due to firewall interference with the TLS > > handshake, causing browsers to retry an SSLv3 handshake. > > The name of one firewall which is confirmed to do this would make it a > lot more convincing... It's likely that some TLS connections failed > due to packet loss or a busy server and so the 'fallback' was a > mistake. In a different discussion I heard the name of one such middleboxes, one that seems to be popular in enterprises: https://kb.bluecoat.com/index?page=content&id=KB5493 that appears to be incompatible with _at_least_ the silly Windows SChannel and (former?) iPhone behaviour to use TLSv1.2 at the record layer. I don't know whether this affected middlebox will is hostile towards TLSv1.2 in general, or would let pass a more reasonable record version "{03,01}" for a "{03,03}" ClientHello, such as is used by openssl-1.0.1. -Martin From mrex@sap.com Mon Apr 8 12:49:34 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE68A21F8E63 for ; Mon, 8 Apr 2013 12:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSzX2tI-s4nv for ; Mon, 8 Apr 2013 12:49:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F076F21F86C1 for ; Mon, 8 Apr 2013 12:49:33 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r38JnToM011939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 21:49:29 +0200 (MEST) In-Reply-To: <20130408194008.ED6D71A698@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Mon, 8 Apr 2013 21:49:29 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130408194929.7D02E1A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:49:34 -0000 Following up to myself. That middlebox vendors knowledgebase article says "Cannot access some HTTPS sites in Internet Explorer with Windows 7", so it seems to affect connections established with TLSv1.2, not just initial TLSv1.2 ClientHellos with TLSv1.2 at the record layer. Sorry for the confusion. -Martin Martin Rex wrote: > Geoffrey Keating wrote: > > > > > I've heard (anecdotally) that HTTPS between browsers and webservers > > > who are both TLS-capable sometimes results in SSLv3 connections. > > > Presumably this is due to firewall interference with the TLS > > > handshake, causing browsers to retry an SSLv3 handshake. > > > > The name of one firewall which is confirmed to do this would make it a > > lot more convincing... It's likely that some TLS connections failed > > due to packet loss or a busy server and so the 'fallback' was a > > mistake. > > In a different discussion I heard the name of one such middleboxes, > one that seems to be popular in enterprises: > > https://kb.bluecoat.com/index?page=content&id=KB5493 > > that appears to be incompatible with _at_least_ the silly Windows SChannel > and (former?) iPhone behaviour to use TLSv1.2 at the record layer. > > I don't know whether this affected middlebox will is hostile towards > TLSv1.2 in general, or would let pass a more reasonable record version > "{03,01}" for a "{03,03}" ClientHello, such as is used by openssl-1.0.1. From yngve@spec-work.net Mon Apr 8 12:51:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8D321F935D for ; Mon, 8 Apr 2013 12:51:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBlbE0Hd5hZ3 for ; Mon, 8 Apr 2013 12:51:57 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id AA94721F8E63 for ; Mon, 8 Apr 2013 12:51:56 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:55053 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPI6d-0007p6-1i for tls@ietf.org; Mon, 08 Apr 2013 21:51:55 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "tls@ietf.org" References: <515F428E.2010900@gnutls.org> Date: Mon, 08 Apr 2013 21:51:51 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:51:59 -0000 On Mon, 08 Apr 2013 20:34:59 +0200, Trevor Perrin wrote: > Hi Yngve, > > Thanks for the reference to your rollback prevention draft [1]. I've > also seen the Eric Rescorla and Adam Langley proposals [2,3]. > > These all seem practical ways to enable a TLS-capable party suffering > an SSLv3 fallback to detect that the other party is TLS-capable. > > I'd love to see any of them deployed, so such connections could be > rejected. Browser makers could aso preload their browser with a list > of TLS-capable sites (such as their own), and disable SSLv3 fallback > for them. Opera 12.x already deploy the one I've described (It was also deployed in Opera 10.50 to 11.0x). There are basically two main categories of Renego patched servers causing issues, one does not tolerate the Server Name extension (e.g ), the other does not tolerate the Certificate Status extension (e.g. which is part of a cluster of 90+ servers on the same /24 segment) > Hopefully these actions would force TLS-intolerant middleboxes to be > replaced, so browsers could stop having to work-around them and this > problem would disappear. I hope my proposal might manage that, but I don't think EKR and Adam's proposals will, since they try to work around the broken servers and middleboxes, and do not confront them. Still, there have been little activity on this topic in the WG, no matter which direction one would like to take on this topic. > However! Until this happens, I think new TLS enhancements must > unfortunately try to be compatible with browser workaround behavior. > > So I'm proposing TACK (and similar proposals) could make use of SSLv3 > SCSVS in a narrowly-scoped context: > - Only in case of SSLv3 fallback > - Only when additional data is required from the server or the > connection will fail > > In the long-term, if TLS-intolerant middleboxes can be eliminated to > the point that browsers *don't* need to support them, this case will > cease to exist. At that point this mechanism will be unused and > unneeded. The problem, from my point of view, is that as long as standards and clients *capitulates* to (or maybe a better description is: allows themselves to be *blackmailed* by) those middleboxes (and servers), they will *never* go away, because the visited websites do not break; "if it ain't broken, don't fix it". (I suspect some would make references to "Danegeld" in similar situations.) Case in point: Servers are still version intolerant 13+ years after TLS 1.0 started being deployed, because clients allowed themselves to fall back to SSL v3. The situation is even worse regarding extension intolerance. Even with the reminder about tolerance in RFC 5746 0.15% of renego patched servers are extension (88%) and/or version intolerant (24%) in the TLS 1.0 to TLS 1.2 range, and the reason they are still around is that the other clients have not enforced a no-rollback policy for renego patched servers. Overall, 14.7% are intolerant for those in the 3.x and/or 4.x range. > As you and Nikos have pointed out, there is no guarantee that this > mechanism will always work. However if deployed, we could gather > statistics on it. Which will not mean that the problem will get fixed. It will just mean that clients implement more and more complex recovery methods in an attempt to get past what they think breaks the connection in those cases. Quite the opposite of what my "removal" draft attempt to accomplish Also: How long until a serious security vulnerability rears its head out of that mess of workarounds and iterative fallbacks? > > Anyways, I'd love to hear a better proposal for handling this > difficult and unfortunate case. But it's seeming like the best option > for TACK (which is my immediate concern) would be to specify an SCSV > mechanism. > > Does that seem reasonable? > > > Trevor > > > [1] > http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/ > [2] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html > [3] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html > > > On Sat, Apr 6, 2013 at 12:04 PM, Yngve N. Pettersen > wrote: >> On Sat, 06 Apr 2013 18:59:06 +0200, Trevor Perrin >> wrote: >> >>> On Sat, Apr 6, 2013 at 5:14 AM, Yngve N. Pettersen >>> >>> wrote: >>>> >>>> On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin >>>> wrote: >>>>> >>>>> >>>>> Suppose the SCSV is only allowed in the specific case of an SSLv3 >>>>> fallback where an extension response is required or the connection >>>>> will fail (due to a requirement for TACK, CT, or OCSP). >>>>> >>>>> In this case, it can't break anything because the connection is >>>>> already going to be broken. It's not guaranteed to work, but there's >>>>> evidence it might. >>>>> >>>>> Does that address this concern? >>>> >>>> >>>> >>>> No, it does not. >>> >>> [...] >>>> >>>> we do not at present know if the SCSV >>>> variant will work in all cases. >>> >>> [...] >>>> >>>> So, using an SCSV in the SSL v3 handshake do risk breaking a handshake >>>> that >>>> would otherwise have completed. >>> >>> >>> No, you missed my point. >>> >>> I was proposing using SCSVs only in the case that an SSLv3 fallback is >>> necessary, and the browser *REQUIRES* some data from the server (TACK, >>> CT, OCSP), or the browser will refuse the connection. >>> >>> Example: Suppose a browser has an active TACK pin for a domain, but >>> sending a TLS ClientHello to that domain results in a TCP reset. >>> >>> Since the TACK pin exists, the browser can assume it is not contacting >>> a TLS-intolerant server. >> >> >> In which case the client knows what the highest supported version, and >> the >> extension tolerance, for the server, as you say. >> >> In any such case the client should IMNSHO assume that it is being >> subjected >> to a Man In the Middle attack, using a version rollback attack, and >> abort >> the connection. The client should in such a situation not permit itself >> to >> downgrade the security of the connection, which includes _not_ >> attempting to >> set up the connection using SSL v3, or any TLS version lower than what >> was >> used the last time it had a successful connection. >> >> That is BTW, the principle embedded in my version rollback removal draft >> , >> which uses the server's support of the Renego extension as a proxy >> indication to determine full version and extension tolerance, and then >> use >> that information to assume that any failure to negotiate a connection, >> when >> signaling the client's highest supported version with full extension >> support >> in the handshake, means that the connection is being subjected to a >> version >> rollback attack, and terminate the connection attempt rather than roll >> back >> to an older version. >> >> >>> But a TLS-intolerant middlebox seems like a >>> possibility (though we still need more data on prevalence). I believe >>> current browsers would want to try an SSLv3 fallback in this case, to >>> attempt to work around the interference. >>> >>> However! SSLv3 fallback is pointless here unless the browser has some >>> chance of signalling that it requires a tack, and receiving it. >>> >>> I am proposing giving this a chance of working, by using the same SCSV >>> / ServerHello Extension idiom that has worked for RFC 5746. >>> >>> Of course, this might not work for any specific middlebox! But if the >>> middlebox allows unknown ciphersuites and data at the end of the SSL >>> ServerHello, then it will. And if the middlebox has been patched to >>> whitelist the specific 5746 SCSV and ServerHello extension, that >>> implies it could be upgraded for new uses of this idiom as well. >> >> >> It could be that they have been patched, if there was a problem, but the >> Renego issue was a high profile security issue, and its solution was one >> that was being deployed in all clients within a very short period of >> time. >> Failure to patch any troublesome middleboxes would have caused severe >> problems for users. >> >> I doubt any such incentive to patch will be present for most other >> extensions of TLS, particularly if the usage of the SCSV depends on the >> server being known to support the new feature. >> >> In other words: If there is a problem in this area, you should not >> assume >> that it will be quickly fixed, at least not before general server >> support is >> past 50% or an even higher percentage of high traffic sites use it, >> which >> might take several years to be achieved. >> >> >> -- >> Sincerely, >> Yngve N. Pettersen >> >> Using Opera's mail client: http://www.opera.com/mail/ >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From rob.stradling@comodo.com Mon Apr 8 12:52:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19D321F972F for ; Mon, 8 Apr 2013 12:52:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDmlPVHerfM5 for ; Mon, 8 Apr 2013 12:52:47 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4AA21F8E63 for ; Mon, 8 Apr 2013 12:52:47 -0700 (PDT) Received: (qmail 23473 invoked from network); 8 Apr 2013 19:52:46 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Apr 2013 19:52:46 -0000 Received: (qmail 16869 invoked by uid 1000); 8 Apr 2013 19:52:46 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 08 Apr 2013 20:52:46 +0100 Message-ID: <5163200D.2030300@comodo.com> Date: Mon, 08 Apr 2013 20:52:45 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:52:49 -0000 On 08/04/13 14:58, Yngve N. Pettersen wrote: > I am opposed to mixing in content sent by other servers, because it > could be a privacy violation since it would leak information about which > CAs are used by the sites the user have visited. The information might > change relatively often, but it could still leak information to the > other sites. Hi Yngve. I need to clarify what I was proposing... > Also, the number of entries in the list sent in the Client Hello could > quickly become relatively large, since a client could easily encounter > dozens of intermediate CAs in a session. I didn't mean that the client would send CachedObjects for every Intermediate certificate that it has previously encountered. Rather, I meant that the client would only send CachedObjects for Intermediate certificates that it has good reason to believe are "relevant" for this connection. > The only way something like this would work without becoming a security > problem is that the client would first know that the server is using the > same intermediate CA as one or more other servers it have visited, which > means that the server must send the entire response anyway, so there is > no saving of bytes on the wire. Agreed, but only for the client's first ever visit to a site. My proposal attempts to save bytes on the wire for subsequent full handshakes to the same site (for as long as the same End-entity certificate is used). > Optimizing storage on the client is a separate matter, best left to the > implementers. > > IMO the Cached Info extension can *only* concern itself with information > received from the current server, *never* what has been received by > another server. It might be that this should be spelled out in the spec, > perhaps in the security considerations, at least. When the client sends the ClientHello for a full handshake, it has not yet authenticated that "the current server" is indeed the same server from which it previously retrieved certain information. All the client has done so far is a (potentially insecure) DNS lookup. And anyway, I was only envisaging that clients would send CachedObjects of OCSP Responses that have "been received by another server" in cases where it would be safe to do so. Example: - Client visits https://www.google.com and https://mail.google.com, each for the first time ever, and caches the certificate chains and OCSP Responses for the End-entity and Intermediate certs. Client observes that the same "Google Internet Authority" Intermediate is used in both cases. - A while later, client performs another full handshake to https://www.google.com and gets back a different OCSP Response (with a more recent thisUpdate value) for the same Intermediate cert. - A while later, client performs another full handshake to https://mail.google.com. It sends the CachedObject for the Intermediate OCSP Response that https://www.google.com just returned, because it knows that this OCSP Response is relevant for the Intermediate cert that https://mail.google.com used last time the client connected to it, and because this OCSP Response is the freshest one that the client has available. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From yngve@spec-work.net Mon Apr 8 13:07:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7656821F92B7 for ; Mon, 8 Apr 2013 13:07:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY-MCww7ZI5T for ; Mon, 8 Apr 2013 13:07:08 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3552121F9334 for ; Mon, 8 Apr 2013 13:07:07 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:55589 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPILK-0003CW-Kj; Mon, 08 Apr 2013 22:07:06 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Rob Stradling" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> Date: Mon, 08 Apr 2013 22:07:02 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <5163200D.2030300@comodo.com> User-Agent: Opera Mail/12.15 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:07:09 -0000 On Mon, 08 Apr 2013 21:52:45 +0200, Rob Stradling wrote: > On 08/04/13 14:58, Yngve N. Pettersen wrote: > >> I am opposed to mixing in content sent by other servers, because it >> could be a privacy violation since it would leak information about which >> CAs are used by the sites the user have visited. The information might >> change relatively often, but it could still leak information to the >> other sites. > > Hi Yngve. I need to clarify what I was proposing... > >> Also, the number of entries in the list sent in the Client Hello could >> quickly become relatively large, since a client could easily encounter >> dozens of intermediate CAs in a session. > > I didn't mean that the client would send CachedObjects for every > Intermediate certificate that it has previously encountered. Rather, I > meant that the client would only send CachedObjects for Intermediate > certificates that it has good reason to believe are "relevant" for this > connection. I was primarily reacting to this in your post: >> - It's common for OCSP Responses for Intermediate certificates to be >> valid for much longer than OCSP Responses for End-entity certificates. >> Also, it's common for clients to encounter multiple End-entity >> certificatesissued by the same Intermediate certificate. For these >> reasons, it will >> often be the case that a client has already cached the OCSP Response for >> the Intermediate(s) and will therefore only need the server to send the >> OCSP Response for the End-entity certificate. > And anyway, I was only envisaging that clients would send CachedObjects > of OCSP Responses that have "been received by another server" in cases > where it would be safe to do so. s/safe/"safe"/ > Example: > - Client visits https://www.google.com and https://mail.google.com, > each for the first time ever, and caches the certificate chains and OCSP > Responses for the End-entity and Intermediate certs. Client observes > that the same "Google Internet Authority" Intermediate is used in both > cases. > - A while later, client performs another full handshake to > https://www.google.com and gets back a different OCSP Response (with a > more recent thisUpdate value) for the same Intermediate cert. > - A while later, client performs another full handshake to > https://mail.google.com. It sends the CachedObject for the Intermediate > OCSP Response that https://www.google.com just returned, because it > knows that this OCSP Response is relevant for the Intermediate cert that > https://mail.google.com used last time the client connected to it, and > because this OCSP Response is the freshest one that the client has > available. What about www.co.uk and bank.co.uk? Such things get complicated very fast, which is why we had to develop the public suffix list. Please, let us stay way, way, *way* out of that particular thorny area. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Mon Apr 8 13:41:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B57521F9156 for ; Mon, 8 Apr 2013 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.205 X-Spam-Level: X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DynHR5-p-o3 for ; Mon, 8 Apr 2013 13:41:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1F21F84D9 for ; Mon, 8 Apr 2013 13:41:14 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r38KfD7v016267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 22:41:13 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Mon, 8 Apr 2013 22:41:13 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130408204113.601EA1A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:41:15 -0000 Yngve N. Pettersen wrote: > > Even with the reminder about tolerance in RFC 5746 0.15% of renego patched > servers are extension (88%) and/or version intolerant (24%) in the TLS 1.0 > to TLS 1.2 range, and the reason they are still around is that the other > clients have not enforced a no-rollback policy for renego patched servers. > Overall, 14.7% are intolerant for those in the 3.x and/or 4.x range. Huh? -------------------------------------------------------^^^ Why would you ever check for 4.xx version numbers? Rejecting 4.x version numbers is perfectly OK for TLS servers! rfc5246 says: TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. A TLS client that uses a version {04,00} at the record layer or in ClientHello.client_version is squarely in undefined territory, and every conceivable server behaviour is perfectly compliant with the TLSv1.2 spec. (Personally, however, I believe that crashing is never a valid option for the server). -Martin From yngve@spec-work.net Mon Apr 8 13:54:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C71E21F907E for ; Mon, 8 Apr 2013 13:54:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OzIf33e1MpX for ; Mon, 8 Apr 2013 13:54:51 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1B21F8EFC for ; Mon, 8 Apr 2013 13:54:51 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:56457 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPJ5V-0005HQ-Sd; Mon, 08 Apr 2013 22:54:49 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <20130408204113.601EA1A698@ld9781.wdf.sap.corp> Date: Mon, 08 Apr 2013 22:54:46 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130408204113.601EA1A698@ld9781.wdf.sap.corp> User-Agent: Opera Mail/12.15 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:54:52 -0000 On Mon, 08 Apr 2013 22:41:13 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> Even with the reminder about tolerance in RFC 5746 0.15% of renego >> patched >> servers are extension (88%) and/or version intolerant (24%) in the TLS >> 1.0 >> to TLS 1.2 range, and the reason they are still around is that the other >> clients have not enforced a no-rollback policy for renego patched >> servers. >> Overall, 14.7% are intolerant for those in the 3.x and/or 4.x range. > > Huh? -------------------------------------------------------^^^ > > Why would you ever check for 4.xx version numbers? > > Rejecting 4.x version numbers is perfectly OK for TLS servers! > > rfc5246 says: > TLS servers > compliant with this specification MUST accept any value {03,XX} as > the record layer version number for ClientHello. > > TLS clients that wish to negotiate with older servers MAY send any > value {03,XX} as the record layer version number. > > A TLS client that uses a version {04,00} at the record layer or in > ClientHello.client_version is squarely in undefined territory, > and every conceivable server behaviour is perfectly compliant > with the TLSv1.2 spec. (Personally, however, I believe that > crashing is never a valid option for the server). The keywords are "forward compatibility". And your quote concerns the *record* layer version, which is 3.1 in my testcase. The 4.1 that I am using in my test, is set in the *ClientHello.client_version* field. IMO a SSL/TLS server MUST tolerate ANY ClientHello.client_version larger than its own highest supported version, and when returning the Server Hello will reply with whatever its highest supported version is. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Mon Apr 8 14:31:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140BD21F9133 for ; Mon, 8 Apr 2013 14:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo9EqIbF3ARR for ; Mon, 8 Apr 2013 14:31:23 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 38B3D21F8FED for ; Mon, 8 Apr 2013 14:31:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r38LVLUO023218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 23:31:21 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Mon, 8 Apr 2013 23:31:21 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130408213121.C150B1A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 21:31:24 -0000 Yngve N. Pettersen wrote: > Martin Rex wrote: > > > > Why would you ever check for 4.xx version numbers? > > > > Rejecting 4.x version numbers is perfectly OK for TLS servers! > > > > rfc5246 says: > > TLS servers > > compliant with this specification MUST accept any value {03,XX} as > > the record layer version number for ClientHello. > > > > TLS clients that wish to negotiate with older servers MAY send any > > value {03,XX} as the record layer version number. > > > > A TLS client that uses a version {04,00} at the record layer or in > > ClientHello.client_version is squarely in undefined territory, > > and every conceivable server behaviour is perfectly compliant > > with the TLSv1.2 spec. (Personally, however, I believe that > > crashing is never a valid option for the server). > > The keywords are "forward compatibility". > > And your quote concerns the *record* layer version, which is 3.1 in my > testcase. > > The 4.1 that I am using in my test, is set in the > *ClientHello.client_version* field. > > IMO a SSL/TLS server MUST tolerate ANY ClientHello.client_version larger > than its own highest supported version, and when returning the Server > Hello will reply with whatever its highest supported version is. Quoting from rfc4346 (TLS v1.1 Record Protocol PDU): http://tools.ietf.org/html/rfc4346#page-18 struct { uint8 major, minor; } ProtocolVersion; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; A TLS client that sends a ClientHello.client_version with major=4,minor=1 and expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2 is just as misguided as a client that sends a ClientHello.client_version with major=254, minor=255 and expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2. The meaning of the latter protocol version is defined here: http://tools.ietf.org/html/rfc4347 and there is *NO* reservation or requirement in rfc5246 that would could be interpreted to make "major=4" any less invalid than "major=254". -Martin From yngve@spec-work.net Mon Apr 8 16:19:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DF321F8E7A for ; Mon, 8 Apr 2013 16:19:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inzQYInN9PcO for ; Mon, 8 Apr 2013 16:19:55 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id AFA7321F8498 for ; Mon, 8 Apr 2013 16:19:53 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:58469 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPLLq-00012E-2r; Tue, 09 Apr 2013 01:19:50 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <20130408213121.C150B1A698@ld9781.wdf.sap.corp> Date: Tue, 09 Apr 2013 01:19:46 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130408213121.C150B1A698@ld9781.wdf.sap.corp> User-Agent: Opera Mail/12.15 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 23:19:55 -0000 On Mon, 08 Apr 2013 23:31:21 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> Martin Rex wrote: >> > >> > Why would you ever check for 4.xx version numbers? >> > >> > Rejecting 4.x version numbers is perfectly OK for TLS servers! >> > >> > rfc5246 says: >> > TLS servers >> > compliant with this specification MUST accept any value {03,XX} as >> > the record layer version number for ClientHello. >> > >> > TLS clients that wish to negotiate with older servers MAY send any >> > value {03,XX} as the record layer version number. >> > >> > A TLS client that uses a version {04,00} at the record layer or in >> > ClientHello.client_version is squarely in undefined territory, >> > and every conceivable server behaviour is perfectly compliant >> > with the TLSv1.2 spec. (Personally, however, I believe that >> > crashing is never a valid option for the server). >> >> The keywords are "forward compatibility". >> >> And your quote concerns the *record* layer version, which is 3.1 in my >> testcase. >> >> The 4.1 that I am using in my test, is set in the >> *ClientHello.client_version* field. >> >> IMO a SSL/TLS server MUST tolerate ANY ClientHello.client_version larger >> than its own highest supported version, and when returning the Server >> Hello will reply with whatever its highest supported version is. > > > Quoting from rfc4346 (TLS v1.1 Record Protocol PDU): > > http://tools.ietf.org/html/rfc4346#page-18 > > struct { > uint8 major, minor; > } ProtocolVersion; > > struct { > ContentType type; > ProtocolVersion version; > uint16 length; > opaque fragment[TLSPlaintext.length]; > } TLSPlaintext; > > > A TLS client that sends a ClientHello.client_version with > major=4,minor=1 and > expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2 is just as > misguided > as a client that sends a ClientHello.client_version with major=254, > minor=255 > and expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2. > > The meaning of the latter protocol version is defined here: > http://tools.ietf.org/html/rfc4347 > > and there is *NO* reservation or requirement in rfc5246 that would could > be > interpreted to make "major=4" any less invalid than "major=254". The version field is defined as (major, minor), the version negotiation logic (See RFC 5246 Sec E.1) is defined as lowest version of the clients signaled version and the highest supported by the server. There is AFAIK nothing in RFC 5246 that says that the major version must match, at least implying that the operation is min((major_client, minor_client), (major_server, minor_server)). I think is is quite reasonable to assume that *if* TLS should ever need a significant upgrade, one large enough that the major version number is changed, then we would (unless we were dealing with a complete protocol collapse) still want clients to be able to work with 3.x servers, which means that as long as the client does not know the supported version of the server it would use a 3.x handshake (similar to SSL v2 backwards compatibility), but indicate a 4.x (or whatever is assigned) version as its highest supported version instead of a 3.x. In order for that to work, current servers will have to tolerate such a new version scheme. If we ever get into such a situation, my guess is that we would want to prevent a version rollback; if we still trust the older version I think we also still trust the hashmethod, at least barely, to detect a modified handshake, but not enough to allow a rollback due to connection failure (unless we have some other way to signal, like we did to prevent rollback to SSLv2 from SSLv3). At present, a no rollback policy like that would break 15% of all renego patched websites. As I said 3 years ago, this is a forward compatibility time bomb (for reference, the version intolerance numbers for v4.x are, as of Dec. 2012, 27% for all, 12% for renego patched) -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From trevp@trevp.net Mon Apr 8 16:21:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AAE21F8DBF for ; Mon, 8 Apr 2013 16:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUXemPGK+wJS for ; Mon, 8 Apr 2013 16:21:58 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id B73B021F84CA for ; Mon, 8 Apr 2013 16:21:57 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id e11so6553796wgh.16 for ; Mon, 08 Apr 2013 16:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OyTtnLOTXoEBI+rzLnXYHoKw3R91fLkhMj7LrzKwhsw=; b=f8b3yjxnHa5oWsWq7oMhGAKFzjFFPmm8Blereld/eeDK/HU4TPSOO4mXFb4SBV2Pgg MqWKpplAUAUhk5G0ID2cOOKhd1HlZTIvtjA7igJZiEEG+A2FJp7mcnfebbjCD4J26q1C KZJzxFxFoaPVSUsaFW1o+d9wLs9kYkn5+IdDsQfE5jXp8C8Qm0MILOVWcrFFcudDwhn3 nnPoLfRQYHu+PwftNLWrXtSKghExD1BSIRF7/wl4QLluQqiaJ2LHvBuTN39xxvySABm1 wbXOjkrGALsFx6WSL0iXPK9c5FTnhpS6EMru8C4H5qko/i3fkQfgwqaTD5ZPNBhtiINl OV3g== MIME-Version: 1.0 X-Received: by 10.180.87.170 with SMTP id az10mr16143957wib.3.1365463316560; Mon, 08 Apr 2013 16:21:56 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Mon, 8 Apr 2013 16:21:56 -0700 (PDT) X-Originating-IP: [64.134.227.192] In-Reply-To: References: <515F428E.2010900@gnutls.org> Date: Mon, 8 Apr 2013 16:21:56 -0700 Message-ID: From: Trevor Perrin To: "Yngve N. Pettersen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk4AJjxYMU8ztXGEmT8xDedo9mpZxpIr35i3ZTn+MmKfs7jELx72dKg39olUpSALtrZBs+n Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 23:21:59 -0000 On Mon, Apr 8, 2013 at 12:51 PM, Yngve N. Pettersen wrote: > On Mon, 08 Apr 2013 20:34:59 +0200, Trevor Perrin wrote: > >> Hi Yngve, >> >> Thanks for the reference to your rollback prevention draft [1]. I've >> also seen the Eric Rescorla and Adam Langley proposals [2,3]. >> >> These all seem practical ways to enable a TLS-capable party suffering >> an SSLv3 fallback to detect that the other party is TLS-capable. >> >> I'd love to see any of them deployed, so such connections could be >> rejected. Browser makers could aso preload their browser with a list >> of TLS-capable sites (such as their own), and disable SSLv3 fallback >> for them. > > > Opera 12.x already deploy the one I've described (It was also deployed in > Opera 10.50 to 11.0x). Interesting! To make sure I understand: - You're saying Opera 12.x will refuse to connect to RFC 5746-supporting sites if there's a TLS-intolerant middlebox in the way? - According to [1,2], about half of all TLS servers are RFC 5746-supporting? Could I infer that Opera is providing rollback/MITM/middlebox protection to roughly half of all TLS connections made by its users? If so, that's an impressive step, and great news! Do you think other browsers will follow suit? >> Hopefully these actions would force TLS-intolerant middleboxes to be >> replaced, so browsers could stop having to work-around them and this >> problem would disappear. > > > I hope my proposal might manage that, but I don't think EKR and Adam's > proposals will, since they try to work around the broken servers and > middleboxes, and do not confront them. Not sure that's true. From Eric's draft [3]: """ If the SCSV value is present and is not equal to ClientHello.client_version, then the server MUST terminate the handshake with a fatal "handshake_failure" alert. """ >From Adam's post [4]: """ the semantics of TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 handshakes that included this ciphersuite with a fatal error. """ They have the client explicitly signal TLS capability via an SCSV, whereas you have the client infer the server's TLS capability from presence of renegotiation_info. So their mechanism only works if both clients and servers support it. Your mechanism can be rolled out unilaterally in a browser, at the cost of a higher connection-failure rate (as you've said, ~1/700 servers return renegotiation_info while being TLS intolerant; whether rejecting these servers is a "feature" or "bug" is another question :-) >> In the long-term, if TLS-intolerant middleboxes can be eliminated to >> the point that browsers *don't* need to support them, this case will >> cease to exist. At that point this mechanism will be unused and >> unneeded. > > > The problem, from my point of view, is that as long as standards and clients > *capitulates* to (or maybe a better description is: allows themselves to be > *blackmailed* by) those middleboxes (and servers), they will *never* go > away, because the visited websites do not break; "if it ain't broken, don't > fix it". (I suspect some would make references to "Danegeld" in similar > situations.) I agree these middleboxes will not get fixed unless browsers and servers break compatibility with them. But TACK/CT/etc aren't needed for this: - Browsers could refuse SSLv3 fallback for sites that signal renegotiation_info (Opera) - Browsers could be preloaded with lists of sites to refuse SSLv3 fallback for - Browsers could stop doing SSLv3 fallback entirely - Servers could refuse SSLv3 handshakes - Servers could refuse SSLv3 handshakes with a TLS_CAPABLE_SCSV (per Eric and Adam) They are mostly not doing so. So in the face of the widespread middlebox "capitulation" which is a current fact-of-life on the web, I question whether it's fair to force the cost of breaking these middleboxes on young protocol efforts that are already facing huge challenges to deployment. I think doing so will simply make potential adopters unwilling to experiment with these new enhancements, while having no impact on bad middleboxes. >> As you and Nikos have pointed out, there is no guarantee that this >> mechanism will always work. However if deployed, we could gather >> statistics on it. > > > Which will not mean that the problem will get fixed. It means we will learn how successful this approach is in creating TACK/CT/OCSP-must-staple connections through TLS-intolerant middleboxes. > It will just mean that > clients implement more and more complex recovery methods in an attempt to > get past what they think breaks the connection in those cases. > > Quite the opposite of what my "removal" draft attempt to accomplish I support your rollback removal draft, and other methods. But unless/until they've been effective, I don't agree that new TLS enhancements should be prevented from trying widely-deployed compatibility fallbacks. > Also: How long until a serious security vulnerability rears its head out of > that mess of workarounds and iterative fallbacks? I support removal of all these fallbacks. I hope we can get there. But that is not the present reality TACK etc. have to contend with. (And do note that TACK / CT / OCSP must-staple etc. are attempting to address *existing* serious security vulnerabilities related to the CA system, revocation, and so on.) Trevor [1] http://my.opera.com/securitygroup/blog/2011/05/19/renego-popular-unpatched-and-vulnerable-sites [2] http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=163&type=4&OPENCONF=75799905b2bb79c800ddf7ade3caad00 [3] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html [4] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html From mrex@sap.com Mon Apr 8 16:56:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112021F8DBF for ; Mon, 8 Apr 2013 16:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIW3wIk-A0xM for ; Mon, 8 Apr 2013 16:56:06 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E053C21F8D8E for ; Mon, 8 Apr 2013 16:56:05 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r38Nu31j014774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Apr 2013 01:56:03 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Tue, 9 Apr 2013 01:56:03 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130408235603.A906F1A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 23:56:07 -0000 Yngve N. Pettersen wrote: > Martin Rex wrote: > > > > Quoting from rfc4346 (TLS v1.1 Record Protocol PDU): > > > > http://tools.ietf.org/html/rfc4346#page-18 > > > > struct { > > uint8 major, minor; > > } ProtocolVersion; > > > > struct { > > ContentType type; > > ProtocolVersion version; > > uint16 length; > > opaque fragment[TLSPlaintext.length]; > > } TLSPlaintext; > > The version field is defined as (major, minor), the version negotiation > logic (See RFC 5246 Sec E.1) is defined as lowest version of the clients > signaled version and the highest supported by the server. There is AFAIK > nothing in RFC 5246 that says that the major version must match, at least > implying that the operation is min((major_client, minor_client), > (major_server, minor_server)). I'm sorry, but that is a non-seqitur. from the conceivable version numbers: {1.x} undefined {2,x} undefined (reserved/blocked) {3,x} SSLv3 and TLS {4,x} undefined {127,x} undefined {128,x} undefined {129,x} undefined {253,x} undefined {254,x} DTLS {255,x} undefined and only the behaviour for {3,x} for x>3 is covered in rfc5246 Appendix E. > > I think is is quite reasonable to assume that *if* TLS should ever need a > significant upgrade, one large enough that the major version number is > changed, This is silly and unnecessary. The IETF could easily assign the marketing term "TLSv2.0" for ProtocolVersion {3,4}, so there is no reason to use a major version other than 3 for the forseeable future. -Martin From ashokkumar.j@gmail.com Mon Apr 8 23:41:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D444021F859C for ; Mon, 8 Apr 2013 23:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK6Yq4yJUaiE for ; Mon, 8 Apr 2013 23:41:49 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3107321F8FA5 for ; Mon, 8 Apr 2013 23:41:49 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id jw11so6056288veb.8 for ; Mon, 08 Apr 2013 23:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Y+fHp5YE9r1wy2Aqajlt0ipIfA+Ki3NUGf/yz8j2O5o=; b=K3qhhWeQhph6uN/47ZYScpxVBbD8yZcrs9jeXIO1VQTvwayOyYqmc6DsxlA0RO/eaR pZifTIiifRzoflg2LRDXQlNBg0CaYoRcnqEPtccpO2Iuw6Vo2XUEYU8+rSfBTgvm6beT Z09yb+XDtz0WymJplcKc23ee43FieuAi0XlP0sVPFtJZhmXrcTf4raRWhbP52IEFl9Fk mTjE89UiyXQbZXPwN9QFmMq+B19993B8N9iaZFspFsas0K5c+s5qMJlKfmmPFKVClbDC VgDK5VKIl11WXsXQGBQx76IV1swRIe136m+SWNmjqy0h0u1AZ74lFbfUCBHkYjtdCQqD cSBQ== MIME-Version: 1.0 X-Received: by 10.52.34.102 with SMTP id y6mr15537967vdi.19.1365489708651; Mon, 08 Apr 2013 23:41:48 -0700 (PDT) Received: by 10.52.155.211 with HTTP; Mon, 8 Apr 2013 23:41:48 -0700 (PDT) Date: Tue, 9 Apr 2013 12:11:48 +0530 Message-ID: From: Ashok Kumar To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf30780d62075b8a04d9e7d91a Subject: [TLS] ALPN - specifying client preference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 06:41:50 -0000 --20cf30780d62075b8a04d9e7d91a Content-Type: text/plain; charset=ISO-8859-1 With NPN, client could choose the protocol that it has better support for. With ALPN, do we intend to add some mechanism where the client can specify its preference? I believe the order in which the protocols are sent give some preference, but is anyone interested in having options to say that client prefers all protocols equally? Regards, Ashok P.S.: I'm new to TLS list and apologize if the query is not relevant. I was thinking more in lines of HTTP headers having qvalues. --20cf30780d62075b8a04d9e7d91a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
With NPN, client could choose the protocol that it has bet= ter support for.

With ALPN, do we intend to add some mec= hanism where the client can specify its preference? I believe the order in = which the protocols are sent give some preference, but is anyone interested= in having options to say that client prefers all protocols equally?=A0

Regards,
Ashok

P.S.: I'm new to TLS list and apologize if the query is not relevant. = I was thinking more in lines of HTTP headers having qvalues.
--20cf30780d62075b8a04d9e7d91a-- From turners@ieca.com Tue Apr 9 09:13:46 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D789A21F93E9 for ; Tue, 9 Apr 2013 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTBV1SWzEKnV for ; Tue, 9 Apr 2013 09:13:46 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.236.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB9A21F93E8 for ; Tue, 9 Apr 2013 09:13:46 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 32FE9DD792CA0; Tue, 9 Apr 2013 11:13:41 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 2719CDD792C73 for ; Tue, 9 Apr 2013 11:13:41 -0500 (CDT) Received: from [198.180.150.142] (port=56450 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UPbB3-0001id-IC; Tue, 09 Apr 2013 11:13:45 -0500 Message-ID: <51643E38.3040206@ieca.com> Date: Tue, 09 Apr 2013 12:13:44 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <5152404E.2010702@ieca.com> <51529CCE.5070302@gnutls.org> In-Reply-To: <51529CCE.5070302@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:56450 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] request for early IANA assignment for ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:13:47 -0000 On 3/27/13 3:16 AM, Nikos Mavrogiannopoulos wrote: > On 03/27/2013 01:41 AM, Sean Turner wrote: > > >> Based on the WG adopting the TLS-based upper-layer protocol negotiation >> mechanism working item in Atlanta, what looks like consensus to me on >> using ALPN, and the fact that we're not exactly running out of code > > > The advantage of no point registration during draft stage is that > contributors are not limited by arguments like "this is now implemented > and deployed - too difficult to change". The disadvantage is no > interoperability testing. > > However, I'd find it nice to easily reserve points for ciphersuites or > other TLS IANA managed points at an early stage of a draft for > interoperability testing. Those points could be reserved for a limited > time and kept if the RFC is identical to the draft. So I think that such > process should be generalized, if possible, rather than applied only for > ALPN. There's a process for this that is documented in RFC 4020 ;) One can request an early IANA code point assignment if the registry supports it, the draft is stable, the processing rules are clear, and there's pre-RFC deployment interest, etc. According to RFC 4020 registries eligible for early assignment are Standards Action. IANA will also accept IESG approved requests for IETF Consensus. When RFC 4020bis is out it will open up to "Specification Required" (where an RFC will be used as the stable reference), "RFC Required", "IETF Review", or "Standards Action". It's obviously more complicated than just requesting a value in a registry with particular rules. The request process is documented here: https://tools.ietf.org/html/rfc4020#section-3.1. Note the final point in s3.1: 5) IANA makes an allocation from the appropriate registry, marking it as "temporary", valid for a period of one year from the date of allocation. The date of allocation should also be recorded in the registry and made visible to the public. So basically, what you're asking for is this, assuming I understand your request. Now before everybody starts flooding me with request, if it's TLS related I'm going to be redirecting the request to the WG chairs to first determine whether the draft should be a WG draft. If so, then it'll need to be adopted by the WG (or about to be adopted), be stable, be well-documented, and there's sufficient interest in pre-RFC deployment etc.. That'll all get weighed by the chairs. If the WG isn't interested in adopting the draft as WG item, I'm likely still going to be coming back to the WG later to make sure it won't break anything similar to how cipher suites LCs get shared with the WG. spt From Andrei.Popov@microsoft.com Tue Apr 9 10:09:20 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2537B21F91BC for ; Tue, 9 Apr 2013 10:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGeF7-44JKdJ for ; Tue, 9 Apr 2013 10:09:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 193FC21F8FC7 for ; Tue, 9 Apr 2013 10:09:17 -0700 (PDT) Received: from BL2FFO11FD019.protection.gbl (10.1.15.204) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.664.0; Tue, 9 Apr 2013 17:09:01 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD019.mail.protection.outlook.com (10.173.161.37) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Tue, 9 Apr 2013 17:09:08 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 9 Apr 2013 17:08:57 +0000 Received: from mail44-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Apr 2013 17:07:08 +0000 Received: from mail44-ch1 (localhost [127.0.0.1]) by mail44-ch1-R.bigfish.com (Postfix) with ESMTP id EA48C4006D for ; Tue, 9 Apr 2013 17:07:07 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz9371I1469Kc85fh4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh17ej9a9j1155h) Received-SPF: softfail (mail44-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB070; H:BN1PR03MB072.namprd03.prod.outlook.com; LANG:en; Received: from mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1 (MessageSwitch) id 1365527225395546_24778; Tue, 9 Apr 2013 17:07:05 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail44-ch1.bigfish.com (Postfix) with ESMTP id 5CA144000A6; Tue, 9 Apr 2013 17:07:05 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Apr 2013 17:07:04 +0000 Received: from BN1PR03MB070.namprd03.prod.outlook.com (10.255.225.154) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.287.3; Tue, 9 Apr 2013 17:06:53 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB070.namprd03.prod.outlook.com (10.255.225.154) with Microsoft SMTP Server (TLS) id 15.0.651.13; Tue, 9 Apr 2013 17:06:52 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.211]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.173]) with mapi id 15.00.0651.000; Tue, 9 Apr 2013 17:06:52 +0000 From: Andrei Popov To: Ashok Kumar , "tls@ietf.org" Thread-Topic: [TLS] ALPN - specifying client preference Thread-Index: AQHONO1eLygdXv23qkGmueug6M6Z1pjOF8nA Date: Tue, 9 Apr 2013 17:06:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:a:2:c085:5cb7:cd84:99c5] Content-Type: multipart/alternative; boundary="_000_e0de82710fd94b2d8f5a01e69146a171BN1PR03MB072namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB070.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52254001)(164054002)(377454001)(80022001)(65816001)(74502001)(49866001)(81542001)(5343635001)(56816002)(56776001)(44976002)(69226001)(5343655001)(47736001)(18277545001)(564824003)(71186001)(76482001)(15202345001)(6806001)(46102001)(31966008)(54316002)(33646001)(59766001)(63696002)(47976001)(512954001)(20776003)(53806001)(50986001)(51856001)(77982001)(79102001)(74662001)(54356001)(4396001)(16676001)(81342001)(47446002)(18276755001)(16236675001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14MLTC103.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08118EFC2B Subject: Re: [TLS] ALPN - specifying client preference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:09:20 -0000 --_000_e0de82710fd94b2d8f5a01e69146a171BN1PR03MB072namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashok, In ALPN, the server SHOULD select the protocol that the server prefers amon= g the protocols advertised by the client. Having said that, the client send= s its list of supported protocols in descending order of preference (most-p= referred protocol first). This allows some freedom for the server-side impl= ementer to take the client's preference into account, but ultimately the pr= otocol selection occurs on the server. In NPN, the client SHOULD select the first protocol advertised by the serve= r that it also supports, i.e. the server's preferred protocol SHOULD be sel= ected by the client. An exception to this is the case where the client does= not support any of the server's protocols, in which case the client simply= chooses the client's most preferred protocol. So there is an expectation t= hat the client will honor the server's preference, but practically this dep= ends on the client-side NPN implementation. As for the client preferring "all protocols equally", can you elaborate on = the scenario? What would the server do differently if it had this informati= on? Thanks, Andrei From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Ashok= Kumar Sent: Monday, April 8, 2013 11:42 PM To: tls@ietf.org Subject: [TLS] ALPN - specifying client preference With NPN, client could choose the protocol that it has better support for. With ALPN, do we intend to add some mechanism where the client can specify = its preference? I believe the order in which the protocols are sent give so= me preference, but is anyone interested in having options to say that clien= t prefers all protocols equally? Regards, Ashok P.S.: I'm new to TLS list and apologize if the query is not relevant. I was= thinking more in lines of HTTP headers having qvalues. --_000_e0de82710fd94b2d8f5a01e69146a171BN1PR03MB072namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashok,

 <= /p>

In ALPN, the server SHOUL= D select the protocol that the server prefers among the protocols advertise= d by the client. Having said that, the client sends its list of supported protocols in descending order of preference (most-prefer= red protocol first). This allows some freedom for the server-side implement= er to take the client’s preference into account, but ultimately the p= rotocol selection occurs on the server.

 <= /p>

In NPN, the client SHOULD= select the first protocol advertised by the server that it also supports, = i.e. the server’s preferred protocol SHOULD be selected by the client. An exception to this is the case where the client does not = support any of the server’s protocols, in which case the client simpl= y chooses the client’s most preferred protocol. So there is an expect= ation that the client will honor the server’s preference, but practically this depends on the client-side NPN implementa= tion.

 <= /p>

As for the client preferr= ing “all protocols equally”, can you elaborate on the scenario?= What would the server do differently if it had this information?

 <= /p>

Thanks,=

 <= /p>

Andrei<= /p>

 <= /p>

From: tls-boun= ces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Ashok Kumar
Sent: Monday, April 8, 2013 11:42 PM
To: tls@ietf.org
Subject: [TLS] ALPN - specifying client preference=

 

With NPN, client could choose the protocol that it h= as better support for.

 

With ALPN, do we intend to add some mechanism where = the client can specify its preference? I believe the order in which the pro= tocols are sent give some preference, but is anyone interested in having op= tions to say that client prefers all protocols equally? 

 

Regards,

Ashok

 

P.S.: I'm new to TLS list and apologize if the query= is not relevant. I was thinking more in lines of HTTP headers having qvalu= es.

--_000_e0de82710fd94b2d8f5a01e69146a171BN1PR03MB072namprd03pro_-- From rob.stradling@comodo.com Tue Apr 9 12:08:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A02B21F9590 for ; Tue, 9 Apr 2013 12:08:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkXcOSZ7EnFa for ; Tue, 9 Apr 2013 12:08:02 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9310921F91D4 for ; Tue, 9 Apr 2013 12:08:00 -0700 (PDT) Received: (qmail 12855 invoked from network); 9 Apr 2013 19:07:54 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Apr 2013 19:07:54 -0000 Received: (qmail 10054 invoked by uid 1000); 9 Apr 2013 19:07:54 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 09 Apr 2013 20:07:54 +0100 Message-ID: <51646709.4030803@comodo.com> Date: Tue, 09 Apr 2013 20:07:53 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:08:04 -0000 On 08/04/13 21:07, Yngve N. Pettersen wrote: >> Example: >> - Client visits https://www.google.com and https://mail.google.com, >> each for the first time ever, and caches the certificate chains and >> OCSP Responses for the End-entity and Intermediate certs. Client >> observes that the same "Google Internet Authority" Intermediate is >> used in both cases. >> - A while later, client performs another full handshake to >> https://www.google.com and gets back a different OCSP Response (with a >> more recent thisUpdate value) for the same Intermediate cert. >> - A while later, client performs another full handshake to >> https://mail.google.com. It sends the CachedObject for the >> Intermediate OCSP Response that https://www.google.com just returned, >> because it knows that this OCSP Response is relevant for the >> Intermediate cert that https://mail.google.com used last time the >> client connected to it, and because this OCSP Response is the freshest >> one that the client has available. > > What about www.co.uk and bank.co.uk? > > Such things get complicated very fast, which is why we had to develop > the public suffix list. > > Please, let us stay way, way, *way* out of that particular thorny area. If the End-entity certs at https://www.co.uk and https://bank.co.uk are both issued by the same Intermediate, then what's the problem? Why are the domain names even relevant when deciding whether or not it's "safe" for the client to send an Intermediate cert's OCSP Response that a different server provided? I agree that my proposal should be rejected _if_ the consensus is that it adds too much extra complexity. But IMHO the more bytes on the wire we can save, the more chance there is that Multi-Stapling + Cached-Info will actually get deployed widely. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From yngve@spec-work.net Tue Apr 9 14:00:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B80E21F991F for ; Tue, 9 Apr 2013 14:00:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km7s4W4NgOz0 for ; Tue, 9 Apr 2013 13:59:59 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id D55F521F9920 for ; Tue, 9 Apr 2013 13:59:57 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:56187 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPfdz-0003Wa-A5; Tue, 09 Apr 2013 22:59:55 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Rob Stradling" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> Date: Tue, 09 Apr 2013 22:59:52 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <51646709.4030803@comodo.com> User-Agent: Opera Mail/12.15 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:00:00 -0000 On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling wrote: > On 08/04/13 21:07, Yngve N. Pettersen wrote: > >>> Example: >>> - Client visits https://www.google.com and https://mail.google.com, >>> each for the first time ever, and caches the certificate chains and >>> OCSP Responses for the End-entity and Intermediate certs. Client >>> observes that the same "Google Internet Authority" Intermediate is >>> used in both cases. >>> - A while later, client performs another full handshake to >>> https://www.google.com and gets back a different OCSP Response (with a >>> more recent thisUpdate value) for the same Intermediate cert. >>> - A while later, client performs another full handshake to >>> https://mail.google.com. It sends the CachedObject for the >>> Intermediate OCSP Response that https://www.google.com just returned, >>> because it knows that this OCSP Response is relevant for the >>> Intermediate cert that https://mail.google.com used last time the >>> client connected to it, and because this OCSP Response is the freshest >>> one that the client has available. >> >> What about www.co.uk and bank.co.uk? >> >> Such things get complicated very fast, which is why we had to develop >> the public suffix list. >> >> Please, let us stay way, way, *way* out of that particular thorny area. > > If the End-entity certs at https://www.co.uk and https://bank.co.uk are > both issued by the same Intermediate, then what's the problem? > Why are the domain names even relevant when deciding whether or not it's > "safe" for the client to send an Intermediate cert's OCSP Response that > a different server provided? Tip: If domain names are irrelevant, make sure they do not carry meaning in the discussion, particularly when combined with the word "safe". Might confuse things. > I agree that my proposal should be rejected _if_ the consensus is that > it adds too much extra complexity. But IMHO the more bytes on the wire > we can save, the more chance there is that Multi-Stapling + Cached-Info > will actually get deployed widely. The concept still assumes that server1 and server2 will have same binary response R for certificate X at time T, even if the client have previously only seen R from server1, and instead seen response S from server2. If, at time T both R and S are valid, but R is valid longer than S, which should be indicated to server2? If both, that means more (unnecessary) bytes on the wire, particularly if you have more than 2 servers (e.g. 200) with the same (issuer) certificate, each with binary different valid responses. What if the client indicates R to server2 and leaves out S, but server2 does not have R (and might get response Q if it requested an update)? Most likely server2 would then resend response S. Result: unnecessary bytes on the wire. Personally, I think it is better to assume that the OCSP responses kept by two servers are different, even if they are signed by the same issuer. It might be that servers in different geographical areas connect to different OCSP responders which have responses generated at different times (or who generate on-the-fly responses). As mentioned above, the potential problems becomes even more pronounced if you are dealing with hundreds or thousands of servers (as we would likely do with servers using Comodo issued certificates, for example). My advice: Keep cache lists for each server separate from the lists used for other servers. That does not mean that the client cannot optimize storage by combining the storage for each entry in the list, though. There is too much chance of guessing wrong about what the server should know based on what the client knows. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From piyush@ditenity.com Tue Apr 9 15:53:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27D21F97EE for ; Tue, 9 Apr 2013 15:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_LT4=0.442, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWtEa1qK8L2M for ; Tue, 9 Apr 2013 15:53:03 -0700 (PDT) Received: from mail-gg0-x234.google.com (mail-gg0-x234.google.com [IPv6:2607:f8b0:4002:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id BC59521F97E2 for ; Tue, 9 Apr 2013 15:53:02 -0700 (PDT) Received: by mail-gg0-f180.google.com with SMTP id e5so1130438ggk.25 for ; Tue, 09 Apr 2013 15:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=u6/7dAqTXo5NACHYjOd33sRnEeIGoXV83kaD1VlxuYw=; b=oTfKtHCX36W/C+94vI+XaDTX7K8l540AQdn86QyObV0bRhVp1csHWTU0ONM8c6TlAQ TNGyEd3yhwFpT5vV6xwVfOApQR0nGrjkiUp9qBWM6SH+0sw4zRfom7Y23xBR+cC9cI7/ OzepB3wXV80nNUOL4q7GD0vFCfp201M+Qk8XH7TC3KQgq2ZwgVoiLVFD/YRoP/vjWL5z z/fhNzO7n5laq0GGyWH1YtRmljDgZN91qVrsUSCTivdJvkcEC92//5nh08xeQqtZfo59 0PzIo9QeCcdazvunh0cNYOi0FsZSxmMfrocYsA2rg1GwVy04W9C9+YHZxrz4YUnPatvZ SAGg== X-Received: by 10.236.202.195 with SMTP id d43mr16557335yho.64.1365547979230; Tue, 09 Apr 2013 15:52:59 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id h6sm45949307yhf.19.2013.04.09.15.52.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 15:52:58 -0700 (PDT) From: "Piyush Jain" To: "'Yngve N. Pettersen'" , "'Rob Stradling'" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> In-Reply-To: Date: Tue, 9 Apr 2013 15:52:44 -0700 Message-ID: <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlAb7NsstXjqmQRSHXKYXg2JOPjAHY6j2EAi7U10ICrEPZfgKTKz73AOQ2LZoBb2wfGgHhzkwPAfgjWBgCU4m1cQJXslm/lv/de9A= Content-Language: en-us X-Gm-Message-State: ALoCoQnWwFDZEjAQ6e8qTCl6C6zEsvy65Oxv9hndr1jRkialadpaD2vuX/OG7Qtocg9IYJPo77j4 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:53:07 -0000 I'm having a basic problem understanding OCSPResponse cachedinfo object and the need to obtain the latest cert_status from the server. Why does a TLS client care if it has the same OCSP responses (for server and any intermediate certificate) as the TLS server, as long as it has some valid OCSP responses for those certificates? IMO, all the client cares about is the fact that it can build a valid status checked path to the locally configured trust anchor. So the only thing that the client needs to tell the server is the list of certificates for which it needs the status (either because the status in the cache expired or because it never got the status from this or other server). This can be communicated easily through a list of Boolean values. The position of the value corresponds to the position of certificate in the certificate chain and the value indicates if the client wants the server to include the status of corresponding cert. This makes the cached info object for OCSP responses much smaller compared to the representation that uses hash and also allows the clients to make use of locally cached OCSP responses irrespective of where they came from. -Piyush > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Yngve N. Pettersen > Sent: Tuesday, April 09, 2013 2:00 PM > To: Rob Stradling > Cc: tls@ietf.org > Subject: Re: [TLS] draft-ietf-tls-cached-info-14 > > On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling > wrote: > > > On 08/04/13 21:07, Yngve N. Pettersen wrote: > > > >>> Example: > >>> - Client visits https://www.google.com and > >>> https://mail.google.com, each for the first time ever, and caches > >>> the certificate chains and OCSP Responses for the End-entity and > >>> Intermediate certs. Client observes that the same "Google Internet > >>> Authority" Intermediate is used in both cases. > >>> - A while later, client performs another full handshake to > >>> https://www.google.com and gets back a different OCSP Response > (with > >>> a more recent thisUpdate value) for the same Intermediate cert. > >>> - A while later, client performs another full handshake to > >>> https://mail.google.com. It sends the CachedObject for the > >>> Intermediate OCSP Response that https://www.google.com just > >>> returned, because it knows that this OCSP Response is relevant for > >>> the Intermediate cert that https://mail.google.com used last time > >>> the client connected to it, and because this OCSP Response is the > >>> freshest one that the client has available. > >> > >> What about www.co.uk and bank.co.uk? > >> > >> Such things get complicated very fast, which is why we had to develop > >> the public suffix list. > >> > >> Please, let us stay way, way, *way* out of that particular thorny area. > > > > If the End-entity certs at https://www.co.uk and https://bank.co.uk > > are both issued by the same Intermediate, then what's the problem? > > Why are the domain names even relevant when deciding whether or not > > it's "safe" for the client to send an Intermediate cert's OCSP > > Response that a different server provided? > > Tip: If domain names are irrelevant, make sure they do not carry meaning in > the discussion, particularly when combined with the word "safe". Might > confuse things. > > > I agree that my proposal should be rejected _if_ the consensus is that > > it adds too much extra complexity. But IMHO the more bytes on the > > wire we can save, the more chance there is that Multi-Stapling + > > Cached-Info will actually get deployed widely. > > The concept still assumes that server1 and server2 will have same binary > response R for certificate X at time T, even if the client have previously only > seen R from server1, and instead seen response S from server2. > > If, at time T both R and S are valid, but R is valid longer than S, which should > be indicated to server2? If both, that means more (unnecessary) bytes on > the wire, particularly if you have more than 2 servers (e.g. 200) with the same > (issuer) certificate, each with binary different valid responses. > > What if the client indicates R to server2 and leaves out S, but server2 does > not have R (and might get response Q if it requested an update)? Most likely > server2 would then resend response S. Result: unnecessary bytes on the > wire. > > Personally, I think it is better to assume that the OCSP responses kept by two > servers are different, even if they are signed by the same issuer. It might be > that servers in different geographical areas connect to different OCSP > responders which have responses generated at different times (or who > generate on-the-fly responses). > > As mentioned above, the potential problems becomes even more > pronounced if you are dealing with hundreds or thousands of servers (as we > would likely do with servers using Comodo issued certificates, for example). > > My advice: Keep cache lists for each server separate from the lists used for > other servers. That does not mean that the client cannot optimize storage by > combining the storage for each entry in the list, though. There is too much > chance of guessing wrong about what the server should know based on what > the client knows. > > -- > Sincerely, > Yngve N. Pettersen > > Using Opera's mail client: http://www.opera.com/mail/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ashokkumar.j@gmail.com Tue Apr 9 22:20:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23621F92F4 for ; Tue, 9 Apr 2013 22:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D04JIMWyhImV for ; Tue, 9 Apr 2013 22:20:38 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8B621F92E9 for ; Tue, 9 Apr 2013 22:20:38 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id c13so70960vea.11 for ; Tue, 09 Apr 2013 22:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vDYKoVK6SPk1oKitjZcEmCqv5ZrAgbQ5My4jJCefSKU=; b=dBzmYINrjJGj7tiqM/9ieIZG8Nh+AOEqep2XUkZKy7VjO2coNplnJ9Rxj3u5B4W+hM HrmNdFU/jdc2XH8T/h67N1CfLyGYR4I1T7TczP64bmom/ridwICf486fkrjEK1tW9jmb BIer+SNdhsJgvavkmc4ZWDl+UZyyZ+UsFuENrqag81sZqbt4RK7p+zjYmjKE0fAqCTpz ze9aNiA2IAYhHLi4fs73jXek8MzUWll9lPvDgEO2JdwdwEaHMEta1G3bFitJ6sL2EGkT 7UPVx6wGF3UrophiukSlElDh7jMykBjl0m40zrsVjAPL6IkJXhcUvj0zIt4VtIc62OqF mi3Q== MIME-Version: 1.0 X-Received: by 10.220.95.10 with SMTP id b10mr416657vcn.10.1365571237977; Tue, 09 Apr 2013 22:20:37 -0700 (PDT) Received: by 10.52.155.211 with HTTP; Tue, 9 Apr 2013 22:20:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Apr 2013 10:50:37 +0530 Message-ID: From: Ashok Kumar To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11c1d8788e57ef04d9fad4b7 Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN - specifying client preference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 05:20:39 -0000 --001a11c1d8788e57ef04d9fad4b7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Andrei, I was thinking in terms of having options to prevent strict preference orders. Let's say in near future, browsers use ALPN to negotiate between HTTP/1.1, SPDY/3, HTTP/2.0 and client doesn't mind between SPDY/3, HTTP/2.0 but prefers either of those over HTTP/1.1. I was just thinking that the server need not pick one of the two just because it appears first and thinks the client prefers it. Now that I read your mail, "server SHOULD select protocol that the _server prefers_ among the protocols advertised by the client", I see that it's completely server's choice and hence such an feature may not be useful. Thanks, Ashok On Tue, Apr 9, 2013 at 10:36 PM, Andrei Popov w= rote: > Hi Ashok,**** > > ** ** > > In ALPN, the server SHOULD select the protocol that the server prefers > among the protocols advertised by the client. Having said that, the clien= t > sends its list of supported protocols in descending order of preference > (most-preferred protocol first). This allows some freedom for the > server-side implementer to take the client=92s preference into account, b= ut > ultimately the protocol selection occurs on the server.**** > > ** ** > > In NPN, the client SHOULD select the first protocol advertised by the > server that it also supports, i.e. the server=92s preferred protocol SHOU= LD > be selected by the client. An exception to this is the case where the > client does not support any of the server=92s protocols, in which case th= e > client simply chooses the client=92s most preferred protocol. So there is= an > expectation that the client will honor the server=92s preference, but > practically this depends on the client-side NPN implementation.**** > > ** ** > > As for the client preferring =93all protocols equally=94, can you elabora= te on > the scenario? What would the server do differently if it had this > information?**** > > ** ** > > Thanks,**** > > ** ** > > Andrei**** > > ** ** > > *From:* tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] *On Behalf Of = *Ashok > Kumar > *Sent:* Monday, April 8, 2013 11:42 PM > *To:* tls@ietf.org > *Subject:* [TLS] ALPN - specifying client preference**** > > ** ** > > With NPN, client could choose the protocol that it has better support for= . > **** > > ** ** > > With ALPN, do we intend to add some mechanism where the client can specif= y > its preference? I believe the order in which the protocols are sent give > some preference, but is anyone interested in having options to say that > client prefers all protocols equally? **** > > ** ** > > Regards,**** > > Ashok**** > > ** ** > > P.S.: I'm new to TLS list and apologize if the query is not relevant. I > was thinking more in lines of HTTP headers having qvalues.**** > --=20 .- ... .... --- -.- --001a11c1d8788e57ef04d9fad4b7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Andrei,=A0

I was thinking in t= erms of having options to prevent strict preference orders. Let's say i= n near future, browsers use ALPN to negotiate between HTTP/1.1, SPDY/3, HTT= P/2.0 and client doesn't mind between SPDY/3, HTTP/2.0 but prefers eith= er of those over HTTP/1.1. I was just thinking that the server need not pic= k one of the two just because it appears first and thinks the client prefer= s it.

Now that I read your mail, "server SHO= ULD select protocol that the _server prefers_ among the protocols advertise= d by the client", I see that it's completely server's choice a= nd hence such an feature may not be useful.

Thanks,
Ashok


On Tue, Apr 9, = 2013 at 10:36 PM, Andrei Popov <Andrei.Popov@microsoft.com>= ; wrote:

Hi Ashok,

=A0<= /p>

In ALPN, the server SHOUL= D select the protocol that the server prefers among the protocols advertise= d by the client. Having said that, the client sends its list of supported protocols in descending order of preference (most-prefer= red protocol first). This allows some freedom for the server-side implement= er to take the client=92s preference into account, but ultimately the proto= col selection occurs on the server.

=A0<= /p>

In NPN, the client SHOULD= select the first protocol advertised by the server that it also supports, = i.e. the server=92s preferred protocol SHOULD be selected by the client. An exception to this is the case where the client does not = support any of the server=92s protocols, in which case the client simply ch= ooses the client=92s most preferred protocol. So there is an expectation th= at the client will honor the server=92s preference, but practically this depends on the client-side NPN implementa= tion.

=A0<= /p>

As for the client preferr= ing =93all protocols equally=94, can you elaborate on the scenario? What wo= uld the server do differently if it had this information?

=A0<= /p>

Thanks,

=A0<= /p>

Andrei

=A0<= /p>

From: tls-bounces@ietf.org= [mailto:tls-boun= ces@ietf.org] On Behalf Of Ashok Kumar
Sent: Monday, April 8, 2013 11:42 PM
To: tls@ietf.org
Subject: [TLS] ALPN - specifying client preference




--
.- ... .... = --- -.-
--001a11c1d8788e57ef04d9fad4b7-- From ynir@checkpoint.com Tue Apr 9 22:23:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8000221F9402 for ; Tue, 9 Apr 2013 22:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=5.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfNjL2Zfl-MG for ; Tue, 9 Apr 2013 22:23:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 434FD21F9401 for ; Tue, 9 Apr 2013 22:23:34 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3A5NSxT009691; Wed, 10 Apr 2013 08:23:28 +0300 X-CheckPoint: {5164F726-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 08:23:27 +0300 From: Yoav Nir To: Sean Turner Thread-Topic: [TLS] request for early IANA assignment for ALPN Thread-Index: AQHOKoQgEcc6yFdn6k20rGU594Lma5i4/3IAgBTzpQCAANyrAA== Date: Wed, 10 Apr 2013 05:23:27 +0000 Message-ID: <4FEFDF5C-6DBB-4009-ADFC-D11C72710A5E@checkpoint.com> References: <5152404E.2010702@ieca.com> <51529CCE.5070302@gnutls.org> <51643E38.3040206@ieca.com> In-Reply-To: <51643E38.3040206@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.42] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <26B951FBD139E74896DDA2B9133804D9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] request for early IANA assignment for ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 05:23:35 -0000 On Apr 9, 2013, at 7:13 PM, Sean Turner wrote: > On 3/27/13 3:16 AM, Nikos Mavrogiannopoulos wrote: >> On 03/27/2013 01:41 AM, Sean Turner wrote: >>=20 >>=20 >>> Based on the WG adopting the TLS-based upper-layer protocol negotiation >>> mechanism working item in Atlanta, what looks like consensus to me on >>> using ALPN, and the fact that we're not exactly running out of code >>=20 >>=20 >> The advantage of no point registration during draft stage is that >> contributors are not limited by arguments like "this is now implemented >> and deployed - too difficult to change". The disadvantage is no >> interoperability testing. >>=20 >> However, I'd find it nice to easily reserve points for ciphersuites or >> other TLS IANA managed points at an early stage of a draft for >> interoperability testing. Those points could be reserved for a limited >> time and kept if the RFC is identical to the draft. So I think that such >> process should be generalized, if possible, rather than applied only for >> ALPN. >=20 > There's a process for this that is documented in RFC 4020 ;) >=20 > One can request an early IANA code point assignment if the registry suppo= rts it, the draft is stable, the processing rules are clear, and there's pr= e-RFC deployment interest, etc. According to RFC 4020 registries eligible = for early assignment are Standards Action. IANA will also accept IESG appr= oved requests for IETF Consensus. When RFC 4020bis is out it will open up = to "Specification Required" (where an RFC will be used as the stable refere= nce), "RFC Required", "IETF Review", or "Standards Action". >=20 > It's obviously more complicated than just requesting a value in a registr= y with particular rules. The request process is documented here: > https://tools.ietf.org/html/rfc4020#section-3.1. >=20 > Note the final point in s3.1: >=20 > 5) IANA makes an allocation from the appropriate registry, marking it > as "temporary", valid for a period of one year from the date of > allocation. The date of allocation should also be recorded in the > registry and made visible to the public. >=20 > So basically, what you're asking for is this, assuming I understand your = request. >=20 > Now before everybody starts flooding me with request, if it's TLS related= I'm going to be redirecting the request to the WG chairs to first determin= e whether the draft should be a WG draft. But ALPN is already a WG draft (although it wasn't when the question was as= ked): http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00 > If so, then it'll need to be adopted by the WG (or about to be adopted), Done. > be stable, be well-documented, and there's sufficient interest in pre-RFC= deployment etc.. That'll all get weighed by the chairs. If the WG isn't = interested in adopting the draft as WG item, I'm likely still going to be c= oming back to the WG later to make sure it won't break anything similar to = how cipher suites LCs get shared with the WG. It's hard to say about stable, as this is a -00 version based on a -02 vers= ion. But there definitely is interest in deploying sooner rather than later= . Yoav= From n.mavrogiannopoulos@gmail.com Wed Apr 10 00:17:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93B121F867B for ; Wed, 10 Apr 2013 00:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muHc21h-i9qk for ; Wed, 10 Apr 2013 00:17:37 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3E56221F8651 for ; Wed, 10 Apr 2013 00:17:37 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id f6so75476qej.30 for ; Wed, 10 Apr 2013 00:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6YH0maPVA21t5lembcPOVV1hhRs/tG/cHfzv/HsdUcE=; b=r5FlTHvajOpMiNPqjO9JU6XIB8VHDOLofIuwZ5nUJjw7XSr/uQ9qrazZmA5ORI5IHh RLQE+tz9e/bk/dOFck5WdHNxQzdzr2MLuNtAofxIQSGUEH5gBshWWErZxxSmTSvji9tQ n5Mx55DUEFp86RMgWxG2njqehkTtra1p/vT+9ONLTzVbFuWr/Fw8NphCIOdPaKyQjHvv ZvASvSV9bpGndhmE7fzvhUT1g5Ta29/mmrNPU1LIM43ATv7I5Kb4cVWjpLrj85J9fpmu zpEcqfWLJ3PqZ82dKrdx5NtWiEkp4lPsekZMwAumUeTd+lf7UNAzgWk0HmcOir+Kk7LG U+kA== MIME-Version: 1.0 X-Received: by 10.229.69.16 with SMTP id x16mr325364qci.53.1365578256680; Wed, 10 Apr 2013 00:17:36 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.117.16 with HTTP; Wed, 10 Apr 2013 00:17:35 -0700 (PDT) In-Reply-To: <51643E38.3040206@ieca.com> References: <5152404E.2010702@ieca.com> <51529CCE.5070302@gnutls.org> <51643E38.3040206@ieca.com> Date: Wed, 10 Apr 2013 09:17:35 +0200 X-Google-Sender-Auth: AS3uA8ojNzGUeWl_4JO2c5RPJNE Message-ID: From: Nikos Mavrogiannopoulos To: Sean Turner Content-Type: multipart/alternative; boundary=0021cc022066e7131504d9fc7613 Cc: "tls@ietf.org" Subject: Re: [TLS] request for early IANA assignment for ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:17:38 -0000 --0021cc022066e7131504d9fc7613 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 9, 2013 at 6:13 PM, Sean Turner wrote: > However, I'd find it nice to easily reserve points for ciphersuites or > >> other TLS IANA managed points at an early stage of a draft for >> interoperability testing. Those points could be reserved for a limited >> time and kept if the RFC is identical to the draft. So I think that such >> process should be generalized, if possible, rather than applied only for >> ALPN. >> > > There's a process for this that is documented in RFC 4020 ;) > Didn't know that. That's indeed pretty useful process. Thank you for bringing that up. regards, Nikos --0021cc022066e7131504d9fc7613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 9, 2013 at 6:13 PM, Sean Turner <turners@ieca.com> wr= ote:
However, I'd find it nice to ea= sily reserve points for ciphersuites or
other TLS IANA managed points at an early stage of a draft for
interoperability testing. Those points could be reserved for a limited
time and kept if the RFC is identical to the draft. So I think that such process should be generalized, if possible, rather than applied only for ALPN.

There's a process for this that is documented in RFC 4020 ;)

Didn't know that. That's indeed pretty us= eful process. Thank you for bringing that up.

regards,
Nikos

--0021cc022066e7131504d9fc7613-- From n.mavrogiannopoulos@gmail.com Wed Apr 10 03:54:20 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF0321F8FD4 for ; Wed, 10 Apr 2013 03:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blN2n5GXmxVb for ; Wed, 10 Apr 2013 03:54:20 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id D93DB21F8FA2 for ; Wed, 10 Apr 2013 03:54:19 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so2223526qab.14 for ; Wed, 10 Apr 2013 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P9djO719sDFTWxdBT0OwUOOWaFyClImUMmwWxeeJ/2Y=; b=oDPw7/6y+mfAajIHyHc9X7jCxr1tDt5Bq3vyiv3mRMkyNYVFFM+S4lH1tqIjubiPnh tMwzlFTWRRL06epPs9+d6hM49Uq2hUdCSUMXf32PbVr2+Cjd9n5wmFNwzyP7r/r/tKIP z67+FU00KOS3RheETAv9pufX2D3tyqy3EO6vc6GaQj0sqbQ5yJW3W5JdUCJHkR1FIVf+ 72J0OS0MXfD8FYhYb1CR1wcSuvrMSccdy6yJ+KG/76ozPpfWGYzx/0nm4HuTPttMnOME x64FN2Kv3yAJ1icPnY8QWk7XDwZC2k6RO7tvTf/tgsH3JHaZz+aqWubmbKuqz4ugnXMs OifQ== MIME-Version: 1.0 X-Received: by 10.49.39.137 with SMTP id p9mr1593401qek.47.1365591259274; Wed, 10 Apr 2013 03:54:19 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.117.16 with HTTP; Wed, 10 Apr 2013 03:54:19 -0700 (PDT) In-Reply-To: <51643E38.3040206@ieca.com> References: <5152404E.2010702@ieca.com> <51529CCE.5070302@gnutls.org> <51643E38.3040206@ieca.com> Date: Wed, 10 Apr 2013 12:54:19 +0200 X-Google-Sender-Auth: _qDhcOj5Wvom3qe2xAhE9-aA56Q Message-ID: From: Nikos Mavrogiannopoulos To: Sean Turner Content-Type: multipart/alternative; boundary=047d7bdca69ceae63c04d9ff7db7 Cc: "tls@ietf.org" Subject: Re: [TLS] request for early IANA assignment for ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 10:54:20 -0000 --047d7bdca69ceae63c04d9ff7db7 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 9, 2013 at 6:13 PM, Sean Turner wrote: > There's a process for this that is documented in RFC 4020 ;) > One can request an early IANA code point assignment if the registry > supports it, the draft is stable, the processing rules are clear, and > there's pre-RFC deployment interest, etc. According to RFC 4020 registries > eligible for early assignment are Standards Action. IANA will also accept > IESG approved requests for IETF Consensus. When RFC 4020bis is out it will > open up to "Specification Required" (where an RFC will be used as the > stable reference), "RFC Required", "IETF Review", or "Standards Action". > btw. may I ask what is the process to propose another NameType to be used in the server_name extension of RFC6066. I am thinking of using that field in order to distinguish between different servers under the same host_name using a UUID as a distinguisher. However, my understanding is that this isn't possible as there is no registry to extend. This is related to my question in http://www.ietf.org/mail-archive/web/tls/current/msg09265.html regards, Nikos --047d7bdca69ceae63c04d9ff7db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 9, 2013 at 6:13 PM, Sean Turner <turners@ieca.com> wr= ote:
There's a process for this that is documented in RFC 4020 ;)
One can request an early IANA code point assignment if the registry support= s it, the draft is stable, the processing rules are clear, and there's = pre-RFC deployment interest, etc. =C2=A0According to RFC 4020 registries el= igible for early assignment are Standards Action. =C2=A0IANA will also acce= pt IESG approved requests for IETF Consensus. =C2=A0When RFC 4020bis is out= it will open up to "Specification Required" (where an RFC will b= e used as the stable reference), "RFC Required", "IETF Revie= w", or "Standards Action".

btw. may I ask what is the process to prop= ose another NameType to be used in the server_name extension of RFC6066. I = am thinking of using that field in order to distinguish between different s= ervers under the same host_name using a UUID as a distinguisher. However, m= y understanding is that this isn't possible as there is no registry to = extend.

This is related to my question in http://www.ietf.org/mail-archive/web/= tls/current/msg09265.html

regards,
Nikos

--047d7bdca69ceae63c04d9ff7db7-- From rob.stradling@comodo.com Wed Apr 10 05:21:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743BD21F9104 for ; Wed, 10 Apr 2013 05:21:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfT4ZzJfUxD1 for ; Wed, 10 Apr 2013 05:21:42 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3BABB21F92F2 for ; Wed, 10 Apr 2013 05:21:15 -0700 (PDT) Received: (qmail 15386 invoked from network); 10 Apr 2013 12:21:13 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2013 12:21:13 -0000 Received: (qmail 1399 invoked by uid 1000); 10 Apr 2013 12:21:13 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 10 Apr 2013 13:21:13 +0100 Message-ID: <51655939.3060001@comodo.com> Date: Wed, 10 Apr 2013 13:21:13 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:21:44 -0000 On 09/04/13 21:59, Yngve N. Pettersen wrote: >> If the End-entity certs at https://www.co.uk and https://bank.co.uk >> are both issued by the same Intermediate, then what's the problem? >> Why are the domain names even relevant when deciding whether or not >> it's "safe" for the client to send an Intermediate cert's OCSP >> Response that a different server provided? > > Tip: If domain names are irrelevant, make sure they do not carry meaning > in the discussion, particularly when combined with the word "safe". > Might confuse things. Noted. Thanks. >> I agree that my proposal should be rejected _if_ the consensus is that >> it adds too much extra complexity. But IMHO the more bytes on the >> wire we can save, the more chance there is that Multi-Stapling + >> Cached-Info will actually get deployed widely. > > The concept still assumes that server1 and server2 will have same binary > response R for certificate X at time T, even if the client have > previously only seen R from server1, and instead seen response S from > server2. Correct. > If, at time T both R and S are valid, but R is valid longer than S, > which should be indicated to server2? If both, that means more > (unnecessary) bytes on the wire, particularly if you have more than 2 > servers (e.g. 200) with the same (issuer) certificate, each with binary > different valid responses. > > What if the client indicates R to server2 and leaves out S, but server2 > does not have R (and might get response Q if it requested an update)? > Most likely server2 would then resend response S. Result: unnecessary > bytes on the wire. I agree that it's possible that R, S, Q and another 200+ variants of an Intermediate OCSP Response might all exist, but how likely is this? These days, CAs are expected to keep Root private keys off-line. So in the typical case of a cert chain involving just 1 Intermediate, it's likely that the Intermediate OCSP Responses will have been pregenerated. Therefore, it's likely that each server will pick up exactly the same OCSP Response to staple. But let's stop discussing this point. I just read Piyush's post and I think he's proposed a far better idea. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rob.stradling@comodo.com Wed Apr 10 06:41:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BD921F97BE for ; Wed, 10 Apr 2013 06:41:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNWTaL2AhQkc for ; Wed, 10 Apr 2013 06:41:23 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08C21F84CC for ; Wed, 10 Apr 2013 06:41:22 -0700 (PDT) Received: (qmail 19554 invoked from network); 10 Apr 2013 13:41:20 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2013 13:41:20 -0000 Received: (qmail 18237 invoked by uid 1000); 10 Apr 2013 13:41:20 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 10 Apr 2013 14:41:20 +0100 Message-ID: <51656C00.8030200@comodo.com> Date: Wed, 10 Apr 2013 14:41:20 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: tls@ietf.org References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> In-Reply-To: <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:41:24 -0000 On 09/04/13 23:52, Piyush Jain wrote: > I'm having a basic problem understanding OCSPResponse cachedinfo object and > the need to obtain the latest cert_status from the server. > > Why does a TLS client care if it has the same OCSP responses (for server and > any intermediate certificate) as the TLS server, as long as it has some > valid OCSP responses for those certificates? IMO, all the client cares about > is the fact that it can build a valid status checked path to the locally > configured trust anchor. > > So the only thing that the client needs to tell the server is the list of > certificates for which it needs the status (either because the status in the > cache expired or because it never got the status from this or other server). > This can be communicated easily through a list of Boolean values. The > position of the value corresponds to the position of certificate in the > certificate chain and the value indicates if the client wants the server to > include the status of corresponding cert. > This makes the cached info object for OCSP responses much smaller compared > to the representation that uses hash and also allows the clients to make use > of locally cached OCSP responses irrespective of where they came from. Thanks Piyush. I think that a "list of Boolean values" for requesting cert statuses is a much better idea. :-) When you say "The position of the value corresponds to the position of certificate in the certificate chain", I presume you're referring to the CachedObject(s) of type "certificate_chain" that the client sends. If a client were to send >1 CachedObjects of type "certificate_chain" and >1 "list of Boolean values" CachedObjects, there could be ambiguity over which "certificate_chain" is paired with which "list of Boolean values". Would we simply say that the CachedObject(s) of these two types must be sent in the same order? Or would we need to squeeze the "list of Boolean values" into the "certificate_chain" CachedObject type somehow? > -Piyush > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Yngve N. Pettersen >> Sent: Tuesday, April 09, 2013 2:00 PM >> To: Rob Stradling >> Cc: tls@ietf.org >> Subject: Re: [TLS] draft-ietf-tls-cached-info-14 >> >> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling >> wrote: >> >>> On 08/04/13 21:07, Yngve N. Pettersen wrote: >>> >>>>> Example: >>>>> - Client visits https://www.google.com and >>>>> https://mail.google.com, each for the first time ever, and caches >>>>> the certificate chains and OCSP Responses for the End-entity and >>>>> Intermediate certs. Client observes that the same "Google Internet >>>>> Authority" Intermediate is used in both cases. >>>>> - A while later, client performs another full handshake to >>>>> https://www.google.com and gets back a different OCSP Response >> (with >>>>> a more recent thisUpdate value) for the same Intermediate cert. >>>>> - A while later, client performs another full handshake to >>>>> https://mail.google.com. It sends the CachedObject for the >>>>> Intermediate OCSP Response that https://www.google.com just >>>>> returned, because it knows that this OCSP Response is relevant for >>>>> the Intermediate cert that https://mail.google.com used last time >>>>> the client connected to it, and because this OCSP Response is the >>>>> freshest one that the client has available. >>>> >>>> What about www.co.uk and bank.co.uk? >>>> >>>> Such things get complicated very fast, which is why we had to develop >>>> the public suffix list. >>>> >>>> Please, let us stay way, way, *way* out of that particular thorny area. >>> >>> If the End-entity certs at https://www.co.uk and https://bank.co.uk >>> are both issued by the same Intermediate, then what's the problem? >>> Why are the domain names even relevant when deciding whether or not >>> it's "safe" for the client to send an Intermediate cert's OCSP >>> Response that a different server provided? >> >> Tip: If domain names are irrelevant, make sure they do not carry meaning > in >> the discussion, particularly when combined with the word "safe". Might >> confuse things. >> >>> I agree that my proposal should be rejected _if_ the consensus is that >>> it adds too much extra complexity. But IMHO the more bytes on the >>> wire we can save, the more chance there is that Multi-Stapling + >>> Cached-Info will actually get deployed widely. >> >> The concept still assumes that server1 and server2 will have same binary >> response R for certificate X at time T, even if the client have previously > only >> seen R from server1, and instead seen response S from server2. >> >> If, at time T both R and S are valid, but R is valid longer than S, which > should >> be indicated to server2? If both, that means more (unnecessary) bytes on >> the wire, particularly if you have more than 2 servers (e.g. 200) with the > same >> (issuer) certificate, each with binary different valid responses. >> >> What if the client indicates R to server2 and leaves out S, but server2 > does >> not have R (and might get response Q if it requested an update)? Most > likely >> server2 would then resend response S. Result: unnecessary bytes on the >> wire. >> >> Personally, I think it is better to assume that the OCSP responses kept by > two >> servers are different, even if they are signed by the same issuer. It > might be >> that servers in different geographical areas connect to different OCSP >> responders which have responses generated at different times (or who >> generate on-the-fly responses). >> >> As mentioned above, the potential problems becomes even more >> pronounced if you are dealing with hundreds or thousands of servers (as we >> would likely do with servers using Comodo issued certificates, for > example). >> >> My advice: Keep cache lists for each server separate from the lists used > for >> other servers. That does not mean that the client cannot optimize storage > by >> combining the storage for each entry in the list, though. There is too > much >> chance of guessing wrong about what the server should know based on what >> the client knows. >> >> -- >> Sincerely, >> Yngve N. Pettersen >> >> Using Opera's mail client: http://www.opera.com/mail/ >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From yngve@spec-work.net Wed Apr 10 06:54:08 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16B221F8E2C for ; Wed, 10 Apr 2013 06:54: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XABwwiH8CtH for ; Wed, 10 Apr 2013 06:54:06 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07E21F8E46 for ; Wed, 10 Apr 2013 06:54:04 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:49495 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPvTC-0004Lh-9g; Wed, 10 Apr 2013 15:53:50 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "Rob Stradling" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> Date: Wed, 10 Apr 2013 15:53:46 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <51656C00.8030200@comodo.com> User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:54:08 -0000 Hi, Please keep in mind that the certificate chain sequence can be changed at any time. Any mechanism used would need to take that into consideration. Therefore, such a solution would have to link it to the fingerprint of the chain of stapled responses. However, once you provide that information you don't need a boolean value to indicate which responses you have and that are valid, because the server will already have that information. It might be conceivable to link the information to the fingerprint of the certificate chain and then use the bools, but that would actually require (a few) more bytes on the wire than indicating the fingerprint of the stapled response list (although: one could get past that by linking the stapled list with the entry for cached certificates, but I think that would complicate matters more than is necessary to save a few bytes; particularly if the client for some reason is not caching the certificate chain). On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling wrote: > On 09/04/13 23:52, Piyush Jain wrote: >> I'm having a basic problem understanding OCSPResponse cachedinfo object >> and >> the need to obtain the latest cert_status from the server. >> >> Why does a TLS client care if it has the same OCSP responses (for >> server and >> any intermediate certificate) as the TLS server, as long as it has some >> valid OCSP responses for those certificates? IMO, all the client cares >> about >> is the fact that it can build a valid status checked path to the locally >> configured trust anchor. >> >> So the only thing that the client needs to tell the server is the list >> of >> certificates for which it needs the status (either because the status >> in the >> cache expired or because it never got the status from this or other >> server). >> This can be communicated easily through a list of Boolean values. The >> position of the value corresponds to the position of certificate in the >> certificate chain and the value indicates if the client wants the >> server to >> include the status of corresponding cert. >> This makes the cached info object for OCSP responses much smaller >> compared >> to the representation that uses hash and also allows the clients to >> make use >> of locally cached OCSP responses irrespective of where they came from. > > Thanks Piyush. I think that a "list of Boolean values" for requesting > cert statuses is a much better idea. :-) > > When you say "The position of the value corresponds to the position of > certificate in the certificate chain", I presume you're referring to the > CachedObject(s) of type "certificate_chain" that the client sends. > > If a client were to send >1 CachedObjects of type "certificate_chain" > and >1 "list of Boolean values" CachedObjects, there could be ambiguity > over which "certificate_chain" is paired with which "list of Boolean > values". > > Would we simply say that the CachedObject(s) of these two types must be > sent in the same order? > Or would we need to squeeze the "list of Boolean values" into the > "certificate_chain" CachedObject type somehow? > >> -Piyush >> >>> -----Original Message----- >>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>> Yngve N. Pettersen >>> Sent: Tuesday, April 09, 2013 2:00 PM >>> To: Rob Stradling >>> Cc: tls@ietf.org >>> Subject: Re: [TLS] draft-ietf-tls-cached-info-14 >>> >>> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling >>> wrote: >>> >>>> On 08/04/13 21:07, Yngve N. Pettersen wrote: >>>> >>>>>> Example: >>>>>> - Client visits https://www.google.com and >>>>>> https://mail.google.com, each for the first time ever, and caches >>>>>> the certificate chains and OCSP Responses for the End-entity and >>>>>> Intermediate certs. Client observes that the same "Google Internet >>>>>> Authority" Intermediate is used in both cases. >>>>>> - A while later, client performs another full handshake to >>>>>> https://www.google.com and gets back a different OCSP Response >>> (with >>>>>> a more recent thisUpdate value) for the same Intermediate cert. >>>>>> - A while later, client performs another full handshake to >>>>>> https://mail.google.com. It sends the CachedObject for the >>>>>> Intermediate OCSP Response that https://www.google.com just >>>>>> returned, because it knows that this OCSP Response is relevant for >>>>>> the Intermediate cert that https://mail.google.com used last time >>>>>> the client connected to it, and because this OCSP Response is the >>>>>> freshest one that the client has available. >>>>> >>>>> What about www.co.uk and bank.co.uk? >>>>> >>>>> Such things get complicated very fast, which is why we had to develop >>>>> the public suffix list. >>>>> >>>>> Please, let us stay way, way, *way* out of that particular thorny >>>>> area. >>>> >>>> If the End-entity certs at https://www.co.uk and https://bank.co.uk >>>> are both issued by the same Intermediate, then what's the problem? >>>> Why are the domain names even relevant when deciding whether or not >>>> it's "safe" for the client to send an Intermediate cert's OCSP >>>> Response that a different server provided? >>> >>> Tip: If domain names are irrelevant, make sure they do not carry >>> meaning >> in >>> the discussion, particularly when combined with the word "safe". Might >>> confuse things. >>> >>>> I agree that my proposal should be rejected _if_ the consensus is that >>>> it adds too much extra complexity. But IMHO the more bytes on the >>>> wire we can save, the more chance there is that Multi-Stapling + >>>> Cached-Info will actually get deployed widely. >>> >>> The concept still assumes that server1 and server2 will have same >>> binary >>> response R for certificate X at time T, even if the client have >>> previously >> only >>> seen R from server1, and instead seen response S from server2. >>> >>> If, at time T both R and S are valid, but R is valid longer than S, >>> which >> should >>> be indicated to server2? If both, that means more (unnecessary) bytes >>> on >>> the wire, particularly if you have more than 2 servers (e.g. 200) with >>> the >> same >>> (issuer) certificate, each with binary different valid responses. >>> >>> What if the client indicates R to server2 and leaves out S, but server2 >> does >>> not have R (and might get response Q if it requested an update)? Most >> likely >>> server2 would then resend response S. Result: unnecessary bytes on the >>> wire. >>> >>> Personally, I think it is better to assume that the OCSP responses >>> kept by >> two >>> servers are different, even if they are signed by the same issuer. It >> might be >>> that servers in different geographical areas connect to different OCSP >>> responders which have responses generated at different times (or who >>> generate on-the-fly responses). >>> >>> As mentioned above, the potential problems becomes even more >>> pronounced if you are dealing with hundreds or thousands of servers >>> (as we >>> would likely do with servers using Comodo issued certificates, for >> example). >>> >>> My advice: Keep cache lists for each server separate from the lists >>> used >> for >>> other servers. That does not mean that the client cannot optimize >>> storage >> by >>> combining the storage for each entry in the list, though. There is too >> much >>> chance of guessing wrong about what the server should know based on >>> what >>> the client knows. >>> >>> -- >>> Sincerely, >>> Yngve N. Pettersen >>> >>> Using Opera's mail client: http://www.opera.com/mail/ >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> > -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From piyush@ditenity.com Wed Apr 10 07:02:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843EF21F980C for ; Wed, 10 Apr 2013 07:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_LT4=0.442, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whra8CE8VnEh for ; Wed, 10 Apr 2013 07:02:27 -0700 (PDT) Received: from mail-gg0-x231.google.com (mail-gg0-x231.google.com [IPv6:2607:f8b0:4002:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4E13321F97C8 for ; Wed, 10 Apr 2013 07:02:27 -0700 (PDT) Received: by mail-gg0-f177.google.com with SMTP id q1so48873gge.8 for ; Wed, 10 Apr 2013 07:02:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=AMGE5mXmTtHSbFNDU6OtLW8VNFdwhcC9AdPQgfaCt2A=; b=cFFjdEtJsV94pY9CFiOCAjIVzTAOqJXqxBn31AZO4wtefTao1HPnXuN+rM+sjdSSbq mvKWjipQoSamSe4AelT9xvNNBalaAn9NUz5HlJTREd2xmqfDr6b13h0uoni8gI0hMqJg dzr4XavUcDuQtZJaM85lRLo93Vg6J23ZHpm4anzmXz+Pu49ZWzycuxxvXMEef2dviJxY dMKZ/d0uMnFG8ZCcaXKiTl43WvcQaRXWS60/JXZ5TNlgfh1Q8XqxYQ5/wUfcHOpJJ+bD /ynT+XbMSfYHh01gJApU6QDPlp7cNyVJQNIIhHY6vN2iW5HLYvy5WW5VujakHmItPok6 m++A== X-Received: by 10.236.32.66 with SMTP id n42mr1133850yha.193.1365602546607; Wed, 10 Apr 2013 07:02:26 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id f70sm96617yhi.12.2013.04.10.07.02.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 07:02:26 -0700 (PDT) From: "Piyush Jain" To: "'Rob Stradling'" , References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> In-Reply-To: <51656C00.8030200@comodo.com> Date: Wed, 10 Apr 2013 07:02:10 -0700 Message-ID: <0a1001ce35f4$00409d50$00c1d7f0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlAb7NsstXjqmQRSHXKYXg2JOPjAHY6j2EAi7U10ICrEPZfgKTKz73AOQ2LZoBb2wfGgHhzkwPAfgjWBgCU4m1cQJXslm/AcH7iVICHlM1kpbh3OVg Content-Language: en-us X-Gm-Message-State: ALoCoQnzZdN83QqiUt74VOAMx2puPec7Vj5h5P06IkIIJwpE84GS4dDUTQF5DSVOT4uUBA1tht+y Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:02:28 -0000 > When you say "The position of the value corresponds to the position of > certificate in the certificate chain", I presume you're referring to the > CachedObject(s) of type "certificate_chain" that the client sends. [Piyush] Correct. > > If a client were to send >1 CachedObjects of type "certificate_chain" > and >1 "list of Boolean values" CachedObjects, there could be ambiguity over > which "certificate_chain" is paired with which "list of Boolean values". > > Would we simply say that the CachedObject(s) of these two types must be > sent in the same order? > Or would we need to squeeze the "list of Boolean values" into the > "certificate_chain" CachedObject type somehow? > [Piyush] Either approach would work (it is just different representation of same information). However, keeping them separate would be better just because implementations may want to support caching of certificate_chain and may not want to support caching of OCSP responses. Given that certificate_chain cached object represents a list of certificates with strict rules on ordering, ocsp cached object would be a list with same number of entries and same ordering as those of certificate chain. From mrex@sap.com Wed Apr 10 07:08:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8F921F97EF for ; Wed, 10 Apr 2013 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gE1Xo9oCn4U for ; Wed, 10 Apr 2013 07:08:09 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 86DA021F97E5 for ; Wed, 10 Apr 2013 07:08:09 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r3AE819j012808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 16:08:01 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Wed, 10 Apr 2013 16:08:01 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130410140801.B0BB41A6A1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:08:10 -0000 Yngve N. Pettersen wrote: > > My advice: Keep cache lists for each server separate from the lists used > for other servers. That does not mean that the client cannot optimize > storage by combining the storage for each entry in the list, though. There > is too much chance of guessing wrong about what the server should know > based on what the client knows. I agree with Yngve that it would be a terribly bad idea for TLS clients to announcing hashes of cached OCSP responses from other sources than a prior TLS handshake with the _exact_same_server_ . The concept of the caching mechanism is to cache data from a previous TLS handshake. Mixing in data from other sources is going to cause hardly predictable behaviour *AND* is going to leak information that ought not to be leaked (and may occasionally create a security problem "side channel"). The only thing that might be acceptable, is a means for the client to indicate "don't send me that information at all". The client could always omit the OCSP response extension (single and multi) from the TLS ClientHello, if it so desires (e.g. in a renegotiation handshake, if the client would also abort on a change of the server certificate). But even then, when the "I already have this information" is the result of TLS handshakes with another server, the result would be a side channel leaking information -- so TLS clients need to be careful here! -Martin From rob.stradling@comodo.com Wed Apr 10 07:10:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4433C21F9840 for ; Wed, 10 Apr 2013 07:10:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FMv8RIzBmud for ; Wed, 10 Apr 2013 07:10:20 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0B21F983F for ; Wed, 10 Apr 2013 07:10:14 -0700 (PDT) Received: (qmail 32534 invoked from network); 10 Apr 2013 14:10:13 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2013 14:10:13 -0000 Received: (qmail 18200 invoked by uid 1000); 10 Apr 2013 14:10:13 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 10 Apr 2013 15:10:13 +0100 Message-ID: <516572C4.8000300@comodo.com> Date: Wed, 10 Apr 2013 15:10:12 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Piyush Jain References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> <0a1001ce35f4$00409d50$00c1d7f0$@ditenity.com> In-Reply-To: <0a1001ce35f4$00409d50$00c1d7f0$@ditenity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:10:21 -0000 On 10/04/13 15:02, Piyush Jain wrote: >> When you say "The position of the value corresponds to the position of >> certificate in the certificate chain", I presume you're referring to the >> CachedObject(s) of type "certificate_chain" that the client sends. > [Piyush] Correct. > >> >> If a client were to send >1 CachedObjects of type "certificate_chain" >> and >1 "list of Boolean values" CachedObjects, there could be ambiguity > over >> which "certificate_chain" is paired with which "list of Boolean values". >> >> Would we simply say that the CachedObject(s) of these two types must be >> sent in the same order? >> Or would we need to squeeze the "list of Boolean values" into the >> "certificate_chain" CachedObject type somehow? >> > > [Piyush] > Either approach would work (it is just different representation of same > information). However, keeping them separate would be better just because > implementations may want to support caching of certificate_chain and may not > want to support caching of OCSP responses. Agreed. Also, we'd have to state that the number of "list of Boolean values" CachedObjects sent by the client MUST be either i) zero or ii) exactly the same as the number of "certificate_chain" CachedObject(s). > Given that certificate_chain cached object represents a list of certificates > with strict rules on ordering, ocsp cached object would be a list with same > number of entries and same ordering as those of certificate chain. Agreed. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rob.stradling@comodo.com Wed Apr 10 07:21:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1921F93EA for ; Wed, 10 Apr 2013 07:21:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAntB3GNoCXZ for ; Wed, 10 Apr 2013 07:21:54 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0614821F8A4F for ; Wed, 10 Apr 2013 07:21:52 -0700 (PDT) Received: (qmail 6709 invoked from network); 10 Apr 2013 14:21:47 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2013 14:21:47 -0000 Received: (qmail 586 invoked by uid 1000); 10 Apr 2013 14:21:47 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 10 Apr 2013 15:21:47 +0100 Message-ID: <5165757B.50109@comodo.com> Date: Wed, 10 Apr 2013 15:21:47 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:21:56 -0000 On 10/04/13 14:53, Yngve N. Pettersen wrote: > Hi, > > Please keep in mind that the certificate chain sequence can be changed > at any time. Any mechanism used would need to take that into consideration. It can be changed at any time on the server side, but we're talking about the certificate chain sequence that the client received and cached at a particular point in time. > Therefore, such a solution would have to link it to the fingerprint of > the chain of stapled responses. However, once you provide that > information you don't need a boolean value to indicate which responses > you have and that are valid, because the server will already have that > information. Isn't this exactly what Hannes proposed a couple of weeks ago? https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt > It might be conceivable to link the information to the fingerprint of > the certificate chain and then use the bools, but that would actually > require (a few) more bytes on the wire than indicating the fingerprint > of the stapled response list (although: one could get past that by > linking the stapled list with the entry for cached certificates, but I > think that would complicate matters more than is necessary to save a few > bytes; particularly if the client for some reason is not caching the > certificate chain). > > On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling > wrote: > >> On 09/04/13 23:52, Piyush Jain wrote: >>> I'm having a basic problem understanding OCSPResponse cachedinfo >>> object and >>> the need to obtain the latest cert_status from the server. >>> >>> Why does a TLS client care if it has the same OCSP responses (for >>> server and >>> any intermediate certificate) as the TLS server, as long as it has some >>> valid OCSP responses for those certificates? IMO, all the client >>> cares about >>> is the fact that it can build a valid status checked path to the locally >>> configured trust anchor. >>> >>> So the only thing that the client needs to tell the server is the >>> list of >>> certificates for which it needs the status (either because the status >>> in the >>> cache expired or because it never got the status from this or other >>> server). >>> This can be communicated easily through a list of Boolean values. The >>> position of the value corresponds to the position of certificate in the >>> certificate chain and the value indicates if the client wants the >>> server to >>> include the status of corresponding cert. >>> This makes the cached info object for OCSP responses much smaller >>> compared >>> to the representation that uses hash and also allows the clients to >>> make use >>> of locally cached OCSP responses irrespective of where they came from. >> >> Thanks Piyush. I think that a "list of Boolean values" for requesting >> cert statuses is a much better idea. :-) >> >> When you say "The position of the value corresponds to the position of >> certificate in the certificate chain", I presume you're referring to >> the CachedObject(s) of type "certificate_chain" that the client sends. >> >> If a client were to send >1 CachedObjects of type "certificate_chain" >> and >1 "list of Boolean values" CachedObjects, there could be >> ambiguity over which "certificate_chain" is paired with which "list of >> Boolean values". >> >> Would we simply say that the CachedObject(s) of these two types must >> be sent in the same order? >> Or would we need to squeeze the "list of Boolean values" into the >> "certificate_chain" CachedObject type somehow? >> >>> -Piyush >>> >>>> -----Original Message----- >>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>>> Yngve N. Pettersen >>>> Sent: Tuesday, April 09, 2013 2:00 PM >>>> To: Rob Stradling >>>> Cc: tls@ietf.org >>>> Subject: Re: [TLS] draft-ietf-tls-cached-info-14 >>>> >>>> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling >>>> wrote: >>>> >>>>> On 08/04/13 21:07, Yngve N. Pettersen wrote: >>>>> >>>>>>> Example: >>>>>>> - Client visits https://www.google.com and >>>>>>> https://mail.google.com, each for the first time ever, and caches >>>>>>> the certificate chains and OCSP Responses for the End-entity and >>>>>>> Intermediate certs. Client observes that the same "Google Internet >>>>>>> Authority" Intermediate is used in both cases. >>>>>>> - A while later, client performs another full handshake to >>>>>>> https://www.google.com and gets back a different OCSP Response >>>> (with >>>>>>> a more recent thisUpdate value) for the same Intermediate cert. >>>>>>> - A while later, client performs another full handshake to >>>>>>> https://mail.google.com. It sends the CachedObject for the >>>>>>> Intermediate OCSP Response that https://www.google.com just >>>>>>> returned, because it knows that this OCSP Response is relevant for >>>>>>> the Intermediate cert that https://mail.google.com used last time >>>>>>> the client connected to it, and because this OCSP Response is the >>>>>>> freshest one that the client has available. >>>>>> >>>>>> What about www.co.uk and bank.co.uk? >>>>>> >>>>>> Such things get complicated very fast, which is why we had to develop >>>>>> the public suffix list. >>>>>> >>>>>> Please, let us stay way, way, *way* out of that particular thorny >>>>>> area. >>>>> >>>>> If the End-entity certs at https://www.co.uk and https://bank.co.uk >>>>> are both issued by the same Intermediate, then what's the problem? >>>>> Why are the domain names even relevant when deciding whether or not >>>>> it's "safe" for the client to send an Intermediate cert's OCSP >>>>> Response that a different server provided? >>>> >>>> Tip: If domain names are irrelevant, make sure they do not carry >>>> meaning >>> in >>>> the discussion, particularly when combined with the word "safe". Might >>>> confuse things. >>>> >>>>> I agree that my proposal should be rejected _if_ the consensus is that >>>>> it adds too much extra complexity. But IMHO the more bytes on the >>>>> wire we can save, the more chance there is that Multi-Stapling + >>>>> Cached-Info will actually get deployed widely. >>>> >>>> The concept still assumes that server1 and server2 will have same >>>> binary >>>> response R for certificate X at time T, even if the client have >>>> previously >>> only >>>> seen R from server1, and instead seen response S from server2. >>>> >>>> If, at time T both R and S are valid, but R is valid longer than S, >>>> which >>> should >>>> be indicated to server2? If both, that means more (unnecessary) >>>> bytes on >>>> the wire, particularly if you have more than 2 servers (e.g. 200) >>>> with the >>> same >>>> (issuer) certificate, each with binary different valid responses. >>>> >>>> What if the client indicates R to server2 and leaves out S, but server2 >>> does >>>> not have R (and might get response Q if it requested an update)? Most >>> likely >>>> server2 would then resend response S. Result: unnecessary bytes on the >>>> wire. >>>> >>>> Personally, I think it is better to assume that the OCSP responses >>>> kept by >>> two >>>> servers are different, even if they are signed by the same issuer. It >>> might be >>>> that servers in different geographical areas connect to different OCSP >>>> responders which have responses generated at different times (or who >>>> generate on-the-fly responses). >>>> >>>> As mentioned above, the potential problems becomes even more >>>> pronounced if you are dealing with hundreds or thousands of servers >>>> (as we >>>> would likely do with servers using Comodo issued certificates, for >>> example). >>>> >>>> My advice: Keep cache lists for each server separate from the lists >>>> used >>> for >>>> other servers. That does not mean that the client cannot optimize >>>> storage >>> by >>>> combining the storage for each entry in the list, though. There is too >>> much >>>> chance of guessing wrong about what the server should know based on >>>> what >>>> the client knows. >>>> >>>> -- >>>> Sincerely, >>>> Yngve N. Pettersen >>>> >>>> Using Opera's mail client: http://www.opera.com/mail/ >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From piyush@ditenity.com Wed Apr 10 07:45:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACD421F94CC for ; Wed, 10 Apr 2013 07:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_LT4=0.442, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfoChVPjx6DL for ; Wed, 10 Apr 2013 07:45:51 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8D77721F93B2 for ; Wed, 10 Apr 2013 07:45:51 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id q14so60369yhf.22 for ; Wed, 10 Apr 2013 07:45:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=nuV4jx5uX/F7reB7NMuPVTpniA2p/wLiRly6BNgaAxg=; b=ZfAzHbGTfhwtZQmHem+A9lUddOYJw89VS+9Oyfql0p30yEDNhiYqzkIUXH9BJew4gb 3awPxOF5TFksZhefSpoSDKDJIErR42boZ8E43BtMLHQbNLK6yQKRwvgwpzqQFbKJcfH+ 57stn/C02Uo6rc0aKtI+kzvI66aHqQmZq5Bqt/vdBCfFR0txdySqys4CQDnyw5aFgPZu fFCdS+0QmhSAL1JH0Bnl554x12PMjL7HDdvBPO+kIsRFBH1D5sFcXB+2J3E7619/m3id i7rZRZoyiU+dZjxfZ3jPnhl4PPeNV6t8EZPbLpSYf2z5+zAX+QyuhKX6S9fUyJKjIXbR HCdQ== X-Received: by 10.236.199.78 with SMTP id w54mr1303024yhn.101.1365605150679; Wed, 10 Apr 2013 07:45:50 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id b78sm358210yhi.2.2013.04.10.07.45.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 07:45:49 -0700 (PDT) From: "Piyush Jain" To: "'Yngve N. Pettersen'" , , "'Rob Stradling'" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> In-Reply-To: Date: Wed, 10 Apr 2013 07:45:34 -0700 Message-ID: <0a1801ce35fa$10283650$3078a2f0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlAb7NsstXjqmQRSHXKYXg2JOPjAHY6j2EAi7U10ICrEPZfgKTKz73AOQ2LZoBb2wfGgHhzkwPAfgjWBgCU4m1cQJXslm/AcH7iVICHlM1kgJCjcGGls/OHMA= Content-Language: en-us X-Gm-Message-State: ALoCoQn9JtEzNEKljJwLPe6eYgbB3OBQmZTehSY4W8Fn9PB+Llnib+mLPTrHC7oLvUPC5xTS9vV0 Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:45:53 -0000 > Please keep in mind that the certificate chain sequence can be changed at > any time. Any mechanism used would need to take that into consideration. [Piyush] Not sure if I understood it correctly. TLS has strict guidelines on sequence of certificates in the chain. The certificate chain sequence would change only when the server certificate changes (or in some rare cases when intermediate CA's certificate rolls over). Right? If that happens than certificate_list cached object held by the client would become invalid and consequently any stapled responses associated with the old certificate chain would also become invalid. Let's make sure that we are on the same page regarding this before I respond to your other points below, otherwise we'll get past each other because we would be working off different set of assumptions. > > Therefore, such a solution would have to link it to the fingerprint of the chain > of stapled responses. However, once you provide that information you don't > need a boolean value to indicate which responses you have and that are > valid, because the server will already have that information. > It might be conceivable to link the information to the fingerprint of the > certificate chain and then use the bools, but that would actually require (a > few) more bytes on the wire than indicating the fingerprint of the stapled > response list (although: one could get past that by linking the stapled list with > the entry for cached certificates, but I think that would complicate matters > more than is necessary to save a few bytes; particularly if the client for some > reason is not caching the certificate chain). > On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling > wrote: > > > On 09/04/13 23:52, Piyush Jain wrote: > >> I'm having a basic problem understanding OCSPResponse cachedinfo > >> object and the need to obtain the latest cert_status from the server. > >> > >> Why does a TLS client care if it has the same OCSP responses (for > >> server and any intermediate certificate) as the TLS server, as long > >> as it has some valid OCSP responses for those certificates? IMO, all > >> the client cares about is the fact that it can build a valid status > >> checked path to the locally configured trust anchor. > >> > >> So the only thing that the client needs to tell the server is the > >> list of certificates for which it needs the status (either because > >> the status in the cache expired or because it never got the status > >> from this or other server). > >> This can be communicated easily through a list of Boolean values. The > >> position of the value corresponds to the position of certificate in > >> the certificate chain and the value indicates if the client wants the > >> server to include the status of corresponding cert. > >> This makes the cached info object for OCSP responses much smaller > >> compared to the representation that uses hash and also allows the > >> clients to make use of locally cached OCSP responses irrespective of > >> where they came from. > > > > Thanks Piyush. I think that a "list of Boolean values" for requesting > > cert statuses is a much better idea. :-) > > > > When you say "The position of the value corresponds to the position of > > certificate in the certificate chain", I presume you're referring to > > the > > CachedObject(s) of type "certificate_chain" that the client sends. > > > > If a client were to send >1 CachedObjects of type "certificate_chain" > > and >1 "list of Boolean values" CachedObjects, there could be > > ambiguity over which "certificate_chain" is paired with which "list of > > Boolean values". > > > > Would we simply say that the CachedObject(s) of these two types must > > be sent in the same order? > > Or would we need to squeeze the "list of Boolean values" into the > > "certificate_chain" CachedObject type somehow? > > > >> -Piyush > >> > >>> -----Original Message----- > >>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf > >>> Of Yngve N. Pettersen > >>> Sent: Tuesday, April 09, 2013 2:00 PM > >>> To: Rob Stradling > >>> Cc: tls@ietf.org > >>> Subject: Re: [TLS] draft-ietf-tls-cached-info-14 > >>> > >>> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling > >>> wrote: > >>> > >>>> On 08/04/13 21:07, Yngve N. Pettersen wrote: > >>>> > >>>>>> Example: > >>>>>> - Client visits https://www.google.com and > >>>>>> https://mail.google.com, each for the first time ever, and caches > >>>>>> the certificate chains and OCSP Responses for the End-entity and > >>>>>> Intermediate certs. Client observes that the same "Google > >>>>>> Internet Authority" Intermediate is used in both cases. > >>>>>> - A while later, client performs another full handshake to > >>>>>> https://www.google.com and gets back a different OCSP Response > >>> (with > >>>>>> a more recent thisUpdate value) for the same Intermediate cert. > >>>>>> - A while later, client performs another full handshake to > >>>>>> https://mail.google.com. It sends the CachedObject for the > >>>>>> Intermediate OCSP Response that https://www.google.com just > >>>>>> returned, because it knows that this OCSP Response is relevant > >>>>>> for the Intermediate cert that https://mail.google.com used last > >>>>>> time the client connected to it, and because this OCSP Response > >>>>>> is the freshest one that the client has available. > >>>>> > >>>>> What about www.co.uk and bank.co.uk? > >>>>> > >>>>> Such things get complicated very fast, which is why we had to > >>>>> develop the public suffix list. > >>>>> > >>>>> Please, let us stay way, way, *way* out of that particular thorny > >>>>> area. > >>>> > >>>> If the End-entity certs at https://www.co.uk and https://bank.co.uk > >>>> are both issued by the same Intermediate, then what's the problem? > >>>> Why are the domain names even relevant when deciding whether or > not > >>>> it's "safe" for the client to send an Intermediate cert's OCSP > >>>> Response that a different server provided? > >>> > >>> Tip: If domain names are irrelevant, make sure they do not carry > >>> meaning > >> in > >>> the discussion, particularly when combined with the word "safe". > >>> Might confuse things. > >>> > >>>> I agree that my proposal should be rejected _if_ the consensus is > >>>> that it adds too much extra complexity. But IMHO the more bytes on > >>>> the wire we can save, the more chance there is that Multi-Stapling > >>>> + Cached-Info will actually get deployed widely. > >>> > >>> The concept still assumes that server1 and server2 will have same > >>> binary response R for certificate X at time T, even if the client > >>> have previously > >> only > >>> seen R from server1, and instead seen response S from server2. > >>> > >>> If, at time T both R and S are valid, but R is valid longer than S, > >>> which > >> should > >>> be indicated to server2? If both, that means more (unnecessary) > >>> bytes on the wire, particularly if you have more than 2 servers > >>> (e.g. 200) with the > >> same > >>> (issuer) certificate, each with binary different valid responses. > >>> > >>> What if the client indicates R to server2 and leaves out S, but > >>> server2 > >> does > >>> not have R (and might get response Q if it requested an update)? > >>> Most > >> likely > >>> server2 would then resend response S. Result: unnecessary bytes on > >>> the wire. > >>> > >>> Personally, I think it is better to assume that the OCSP responses > >>> kept by > >> two > >>> servers are different, even if they are signed by the same issuer. > >>> It > >> might be > >>> that servers in different geographical areas connect to different > >>> OCSP responders which have responses generated at different times > >>> (or who generate on-the-fly responses). > >>> > >>> As mentioned above, the potential problems becomes even more > >>> pronounced if you are dealing with hundreds or thousands of servers > >>> (as we would likely do with servers using Comodo issued > >>> certificates, for > >> example). > >>> > >>> My advice: Keep cache lists for each server separate from the lists > >>> used > >> for > >>> other servers. That does not mean that the client cannot optimize > >>> storage > >> by > >>> combining the storage for each entry in the list, though. There is > >>> too > >> much > >>> chance of guessing wrong about what the server should know based on > >>> what the client knows. > >>> > >>> -- > >>> Sincerely, > >>> Yngve N. Pettersen > >>> > >>> Using Opera's mail client: http://www.opera.com/mail/ > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >> > > > > > -- > Sincerely, > Yngve N. Pettersen > > Using Opera's mail client: http://www.opera.com/mail/ From yngve@spec-work.net Wed Apr 10 08:14:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353F221F98A1 for ; Wed, 10 Apr 2013 08:14:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGJq1xnZvUKs for ; Wed, 10 Apr 2013 08:14:54 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id A391621F989B for ; Wed, 10 Apr 2013 08:14:53 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:50560 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPwjc-00039Y-FT; Wed, 10 Apr 2013 17:14:52 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "'Rob Stradling'" , "Piyush Jain" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> <0a1801ce35fa$10283650$3078a2f0$@ditenity.com> Date: Wed, 10 Apr 2013 17:14:51 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <0a1801ce35fa$10283650$3078a2f0$@ditenity.com> User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:14:55 -0000 On Wed, 10 Apr 2013 16:45:34 +0200, Piyush Jain wrote: >> Please keep in mind that the certificate chain sequence can be changed >> at >> any time. Any mechanism used would need to take that into consideration. > [Piyush] Not sure if I understood it correctly. TLS has strict > guidelines on "Chain sequence" was maybe the wrong expression. The point was that the server can change to a completely new set of certificates, including an unrelated certificate authority. However, some server can have certificates incorrectly ordered, and that might get fixed after a while (or it could get broken). > sequence of certificates in the chain. The certificate chain sequence > would > change only when the server certificate changes (or in some rare cases > when > intermediate CA's certificate rolls over). Right? If that happens than > certificate_list cached object held by the client would become invalid > and > consequently any stapled responses associated with the old certificate > chain > would also become invalid. My point is that the information sent to the server about which resources are cached need to connect the resources to what the server have, in such a way that if the server configuration changes the server will know that it does not have the necessary information. Since that require providing at least one hash that the server will know if it have that information, it could be that the boolean flags are unnecessary, because the server should also know that those entries are expired or were missing, etc. based on its own information, if the indicated resource is known to the server. > Let's make sure that we are on the same page regarding this before I > respond > to your other points below, otherwise we'll get past each other because > we > would be working off different set of assumptions. > >> >> Therefore, such a solution would have to link it to the fingerprint of >> the > chain >> of stapled responses. However, once you provide that information you >> don't >> need a boolean value to indicate which responses you have and that are >> valid, because the server will already have that information. >> It might be conceivable to link the information to the fingerprint of >> the >> certificate chain and then use the bools, but that would actually >> require > (a >> few) more bytes on the wire than indicating the fingerprint of the >> stapled >> response list (although: one could get past that by linking the stapled > list with >> the entry for cached certificates, but I think that would complicate > matters >> more than is necessary to save a few bytes; particularly if the client >> for > some >> reason is not caching the certificate chain). >> On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling >> wrote: >> >> > On 09/04/13 23:52, Piyush Jain wrote: >> >> I'm having a basic problem understanding OCSPResponse cachedinfo >> >> object and the need to obtain the latest cert_status from the server. >> >> >> >> Why does a TLS client care if it has the same OCSP responses (for >> >> server and any intermediate certificate) as the TLS server, as long >> >> as it has some valid OCSP responses for those certificates? IMO, all >> >> the client cares about is the fact that it can build a valid status >> >> checked path to the locally configured trust anchor. >> >> >> >> So the only thing that the client needs to tell the server is the >> >> list of certificates for which it needs the status (either because >> >> the status in the cache expired or because it never got the status >> >> from this or other server). >> >> This can be communicated easily through a list of Boolean values. The >> >> position of the value corresponds to the position of certificate in >> >> the certificate chain and the value indicates if the client wants the >> >> server to include the status of corresponding cert. >> >> This makes the cached info object for OCSP responses much smaller >> >> compared to the representation that uses hash and also allows the >> >> clients to make use of locally cached OCSP responses irrespective of >> >> where they came from. >> > >> > Thanks Piyush. I think that a "list of Boolean values" for requesting >> > cert statuses is a much better idea. :-) >> > >> > When you say "The position of the value corresponds to the position of >> > certificate in the certificate chain", I presume you're referring to >> > the >> > CachedObject(s) of type "certificate_chain" that the client sends. >> > >> > If a client were to send >1 CachedObjects of type "certificate_chain" >> > and >1 "list of Boolean values" CachedObjects, there could be >> > ambiguity over which "certificate_chain" is paired with which "list of >> > Boolean values". >> > >> > Would we simply say that the CachedObject(s) of these two types must >> > be sent in the same order? >> > Or would we need to squeeze the "list of Boolean values" into the >> > "certificate_chain" CachedObject type somehow? >> > >> >> -Piyush >> >> >> >>> -----Original Message----- >> >>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf >> >>> Of Yngve N. Pettersen >> >>> Sent: Tuesday, April 09, 2013 2:00 PM >> >>> To: Rob Stradling >> >>> Cc: tls@ietf.org >> >>> Subject: Re: [TLS] draft-ietf-tls-cached-info-14 >> >>> >> >>> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling >> >>> wrote: >> >>> >> >>>> On 08/04/13 21:07, Yngve N. Pettersen wrote: >> >>>> >> >>>>>> Example: >> >>>>>> - Client visits https://www.google.com and >> >>>>>> https://mail.google.com, each for the first time ever, and caches >> >>>>>> the certificate chains and OCSP Responses for the End-entity and >> >>>>>> Intermediate certs. Client observes that the same "Google >> >>>>>> Internet Authority" Intermediate is used in both cases. >> >>>>>> - A while later, client performs another full handshake to >> >>>>>> https://www.google.com and gets back a different OCSP Response >> >>> (with >> >>>>>> a more recent thisUpdate value) for the same Intermediate cert. >> >>>>>> - A while later, client performs another full handshake to >> >>>>>> https://mail.google.com. It sends the CachedObject for the >> >>>>>> Intermediate OCSP Response that https://www.google.com just >> >>>>>> returned, because it knows that this OCSP Response is relevant >> >>>>>> for the Intermediate cert that https://mail.google.com used last >> >>>>>> time the client connected to it, and because this OCSP Response >> >>>>>> is the freshest one that the client has available. >> >>>>> >> >>>>> What about www.co.uk and bank.co.uk? >> >>>>> >> >>>>> Such things get complicated very fast, which is why we had to >> >>>>> develop the public suffix list. >> >>>>> >> >>>>> Please, let us stay way, way, *way* out of that particular thorny >> >>>>> area. >> >>>> >> >>>> If the End-entity certs at https://www.co.uk and https://bank.co.uk >> >>>> are both issued by the same Intermediate, then what's the problem? >> >>>> Why are the domain names even relevant when deciding whether or >> not >> >>>> it's "safe" for the client to send an Intermediate cert's OCSP >> >>>> Response that a different server provided? >> >>> >> >>> Tip: If domain names are irrelevant, make sure they do not carry >> >>> meaning >> >> in >> >>> the discussion, particularly when combined with the word "safe". >> >>> Might confuse things. >> >>> >> >>>> I agree that my proposal should be rejected _if_ the consensus is >> >>>> that it adds too much extra complexity. But IMHO the more bytes on >> >>>> the wire we can save, the more chance there is that Multi-Stapling >> >>>> + Cached-Info will actually get deployed widely. >> >>> >> >>> The concept still assumes that server1 and server2 will have same >> >>> binary response R for certificate X at time T, even if the client >> >>> have previously >> >> only >> >>> seen R from server1, and instead seen response S from server2. >> >>> >> >>> If, at time T both R and S are valid, but R is valid longer than S, >> >>> which >> >> should >> >>> be indicated to server2? If both, that means more (unnecessary) >> >>> bytes on the wire, particularly if you have more than 2 servers >> >>> (e.g. 200) with the >> >> same >> >>> (issuer) certificate, each with binary different valid responses. >> >>> >> >>> What if the client indicates R to server2 and leaves out S, but >> >>> server2 >> >> does >> >>> not have R (and might get response Q if it requested an update)? >> >>> Most >> >> likely >> >>> server2 would then resend response S. Result: unnecessary bytes on >> >>> the wire. >> >>> >> >>> Personally, I think it is better to assume that the OCSP responses >> >>> kept by >> >> two >> >>> servers are different, even if they are signed by the same issuer. >> >>> It >> >> might be >> >>> that servers in different geographical areas connect to different >> >>> OCSP responders which have responses generated at different times >> >>> (or who generate on-the-fly responses). >> >>> >> >>> As mentioned above, the potential problems becomes even more >> >>> pronounced if you are dealing with hundreds or thousands of servers >> >>> (as we would likely do with servers using Comodo issued >> >>> certificates, for >> >> example). >> >>> >> >>> My advice: Keep cache lists for each server separate from the lists >> >>> used >> >> for >> >>> other servers. That does not mean that the client cannot optimize >> >>> storage >> >> by >> >>> combining the storage for each entry in the list, though. There is >> >>> too >> >> much >> >>> chance of guessing wrong about what the server should know based on >> >>> what the client knows. >> >>> >> >>> -- >> >>> Sincerely, >> >>> Yngve N. Pettersen >> >>> >> >>> Using Opera's mail client: http://www.opera.com/mail/ >> >>> _______________________________________________ >> >>> TLS mailing list >> >>> TLS@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> >> > >> >> >> -- >> Sincerely, >> Yngve N. Pettersen >> >> Using Opera's mail client: http://www.opera.com/mail/ > -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From yngve@spec-work.net Wed Apr 10 08:14:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0F021F989B for ; Wed, 10 Apr 2013 08:14:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9cXpj-ZMXCD for ; Wed, 10 Apr 2013 08:14:54 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id A396E21F989C for ; Wed, 10 Apr 2013 08:14:53 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:50560 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UPwjc-00039Y-35; Wed, 10 Apr 2013 17:14:52 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Rob Stradling" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> <5165757B.50109@comodo.com> Date: Wed, 10 Apr 2013 17:14:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <5165757B.50109@comodo.com> User-Agent: Opera Mail/12.15 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:14:55 -0000 On Wed, 10 Apr 2013 16:21:47 +0200, Rob Stradling wrote: > On 10/04/13 14:53, Yngve N. Pettersen wrote: >> Hi, >> >> Please keep in mind that the certificate chain sequence can be changed >> at any time. Any mechanism used would need to take that into >> consideration. > > It can be changed at any time on the server side, but we're talking > about the certificate chain sequence that the client received and cached > at a particular point in time. > >> Therefore, such a solution would have to link it to the fingerprint of >> the chain of stapled responses. However, once you provide that >> information you don't need a boolean value to indicate which responses >> you have and that are valid, because the server will already have that >> information. > > Isn't this exactly what Hannes proposed a couple of weeks ago? > > https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt In this case I am talking about the boolean flag proposal and how it would indicate to a server which responses it have, and particularly how to avoid confusion when/if the certificate chain is updated by the server. >> It might be conceivable to link the information to the fingerprint of >> the certificate chain and then use the bools, but that would actually >> require (a few) more bytes on the wire than indicating the fingerprint >> of the stapled response list (although: one could get past that by >> linking the stapled list with the entry for cached certificates, but I >> think that would complicate matters more than is necessary to save a few >> bytes; particularly if the client for some reason is not caching the >> certificate chain). >> >> On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling >> wrote: >> >>> On 09/04/13 23:52, Piyush Jain wrote: >>>> I'm having a basic problem understanding OCSPResponse cachedinfo >>>> object and >>>> the need to obtain the latest cert_status from the server. >>>> >>>> Why does a TLS client care if it has the same OCSP responses (for >>>> server and >>>> any intermediate certificate) as the TLS server, as long as it has >>>> some >>>> valid OCSP responses for those certificates? IMO, all the client >>>> cares about >>>> is the fact that it can build a valid status checked path to the >>>> locally >>>> configured trust anchor. >>>> >>>> So the only thing that the client needs to tell the server is the >>>> list of >>>> certificates for which it needs the status (either because the status >>>> in the >>>> cache expired or because it never got the status from this or other >>>> server). >>>> This can be communicated easily through a list of Boolean values. The >>>> position of the value corresponds to the position of certificate in >>>> the >>>> certificate chain and the value indicates if the client wants the >>>> server to >>>> include the status of corresponding cert. >>>> This makes the cached info object for OCSP responses much smaller >>>> compared >>>> to the representation that uses hash and also allows the clients to >>>> make use >>>> of locally cached OCSP responses irrespective of where they came from. >>> >>> Thanks Piyush. I think that a "list of Boolean values" for requesting >>> cert statuses is a much better idea. :-) >>> >>> When you say "The position of the value corresponds to the position of >>> certificate in the certificate chain", I presume you're referring to >>> the CachedObject(s) of type "certificate_chain" that the client sends. >>> >>> If a client were to send >1 CachedObjects of type "certificate_chain" >>> and >1 "list of Boolean values" CachedObjects, there could be >>> ambiguity over which "certificate_chain" is paired with which "list of >>> Boolean values". >>> >>> Would we simply say that the CachedObject(s) of these two types must >>> be sent in the same order? >>> Or would we need to squeeze the "list of Boolean values" into the >>> "certificate_chain" CachedObject type somehow? >>> >>>> -Piyush >>>> >>>>> -----Original Message----- >>>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>>>> Yngve N. Pettersen >>>>> Sent: Tuesday, April 09, 2013 2:00 PM >>>>> To: Rob Stradling >>>>> Cc: tls@ietf.org >>>>> Subject: Re: [TLS] draft-ietf-tls-cached-info-14 >>>>> >>>>> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling >>>>> wrote: >>>>> >>>>>> On 08/04/13 21:07, Yngve N. Pettersen wrote: >>>>>> >>>>>>>> Example: >>>>>>>> - Client visits https://www.google.com and >>>>>>>> https://mail.google.com, each for the first time ever, and caches >>>>>>>> the certificate chains and OCSP Responses for the End-entity and >>>>>>>> Intermediate certs. Client observes that the same "Google >>>>>>>> Internet >>>>>>>> Authority" Intermediate is used in both cases. >>>>>>>> - A while later, client performs another full handshake to >>>>>>>> https://www.google.com and gets back a different OCSP Response >>>>> (with >>>>>>>> a more recent thisUpdate value) for the same Intermediate cert. >>>>>>>> - A while later, client performs another full handshake to >>>>>>>> https://mail.google.com. It sends the CachedObject for the >>>>>>>> Intermediate OCSP Response that https://www.google.com just >>>>>>>> returned, because it knows that this OCSP Response is relevant for >>>>>>>> the Intermediate cert that https://mail.google.com used last time >>>>>>>> the client connected to it, and because this OCSP Response is the >>>>>>>> freshest one that the client has available. >>>>>>> >>>>>>> What about www.co.uk and bank.co.uk? >>>>>>> >>>>>>> Such things get complicated very fast, which is why we had to >>>>>>> develop >>>>>>> the public suffix list. >>>>>>> >>>>>>> Please, let us stay way, way, *way* out of that particular thorny >>>>>>> area. >>>>>> >>>>>> If the End-entity certs at https://www.co.uk and https://bank.co.uk >>>>>> are both issued by the same Intermediate, then what's the problem? >>>>>> Why are the domain names even relevant when deciding whether or not >>>>>> it's "safe" for the client to send an Intermediate cert's OCSP >>>>>> Response that a different server provided? >>>>> >>>>> Tip: If domain names are irrelevant, make sure they do not carry >>>>> meaning >>>> in >>>>> the discussion, particularly when combined with the word "safe". >>>>> Might >>>>> confuse things. >>>>> >>>>>> I agree that my proposal should be rejected _if_ the consensus is >>>>>> that >>>>>> it adds too much extra complexity. But IMHO the more bytes on the >>>>>> wire we can save, the more chance there is that Multi-Stapling + >>>>>> Cached-Info will actually get deployed widely. >>>>> >>>>> The concept still assumes that server1 and server2 will have same >>>>> binary >>>>> response R for certificate X at time T, even if the client have >>>>> previously >>>> only >>>>> seen R from server1, and instead seen response S from server2. >>>>> >>>>> If, at time T both R and S are valid, but R is valid longer than S, >>>>> which >>>> should >>>>> be indicated to server2? If both, that means more (unnecessary) >>>>> bytes on >>>>> the wire, particularly if you have more than 2 servers (e.g. 200) >>>>> with the >>>> same >>>>> (issuer) certificate, each with binary different valid responses. >>>>> >>>>> What if the client indicates R to server2 and leaves out S, but >>>>> server2 >>>> does >>>>> not have R (and might get response Q if it requested an update)? Most >>>> likely >>>>> server2 would then resend response S. Result: unnecessary bytes on >>>>> the >>>>> wire. >>>>> >>>>> Personally, I think it is better to assume that the OCSP responses >>>>> kept by >>>> two >>>>> servers are different, even if they are signed by the same issuer. It >>>> might be >>>>> that servers in different geographical areas connect to different >>>>> OCSP >>>>> responders which have responses generated at different times (or who >>>>> generate on-the-fly responses). >>>>> >>>>> As mentioned above, the potential problems becomes even more >>>>> pronounced if you are dealing with hundreds or thousands of servers >>>>> (as we >>>>> would likely do with servers using Comodo issued certificates, for >>>> example). >>>>> >>>>> My advice: Keep cache lists for each server separate from the lists >>>>> used >>>> for >>>>> other servers. That does not mean that the client cannot optimize >>>>> storage >>>> by >>>>> combining the storage for each entry in the list, though. There is >>>>> too >>>> much >>>>> chance of guessing wrong about what the server should know based on >>>>> what >>>>> the client knows. >>>>> >>>>> -- >>>>> Sincerely, >>>>> Yngve N. Pettersen >>>>> >>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> >> >> > -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Wed Apr 10 08:27:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C3021F9774 for ; Wed, 10 Apr 2013 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZLJTBJlIi55 for ; Wed, 10 Apr 2013 08:27:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E032B21F98DF for ; Wed, 10 Apr 2013 08:27:34 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r3AFRPrP000512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 17:27:25 +0200 (MEST) In-Reply-To: <0a1801ce35fa$10283650$3078a2f0$@ditenity.com> To: Piyush Jain Date: Wed, 10 Apr 2013 17:27:25 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130410152725.504F61A6A1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:27:43 -0000 Piyush Jain wrote: > > Please keep in mind that the certificate chain sequence can be changed at > > any time. Any mechanism used would need to take that into consideration. > > [Piyush] Not sure if I understood it correctly. TLS has strict guidelines on > sequence of certificates in the chain. This is the theory. In theory, theory and practice are the same, in practice, they differ. Although the SSLv3 and *ALL* TLS specs have always been very clear that the correct ording of certificates in the TLS Certificate handshake message is a MUST requirement, as well as that only the self-signed rootCA cert at the end of the path may be omitted, a number of TLS implementations are notoriously broken in that they will send arbitrary garbled paths that may include alien certs and even expired certs in Certificate handshake messages (rather than telling the server admin that the configuration is incorrect). Although this is not even mentioned in the TLS spec, a number of SSL and TLS clients will perform various hacks to accomodate for such broken TLS server implementations, ranging from simple reordering of certificate, to the extreme of using only the very first certificate from the servers TLS Certificate handshake message, throw the remaining certificates into a large pool of candidate path certificates and perform a full certificate path discovery. The latter can lead to seemingly non-deterministic behaviour with some TLS servers that omit more than the self-signed rootCA cert from the Certificate handshake message, such as intermediate CA certs, and the client behaviour changes from handshake failure (untrusted cert) to successful handshake when that "large pool" of cached certs coincidentally contains the missing intermediate cert from a prior TLS handshake with a correctly configured TLS Server whose server cert was issued by the same (intermediate) CA. I remember that in march 2001 "https://www.verisign.com" was sending and expired VeriSign rootCA certificate in the server certificate handshake message. When I reported this defect to VeriSign Support, they did (at least initially) not understand that this indicated (a) a defect (or at least significant sloppiness) in their server's SSL/TLS implementation and (b) a server configuration errror. -Martin From n.mavrogiannopoulos@gmail.com Wed Apr 10 01:16:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5427D21F85B3 for ; Wed, 10 Apr 2013 01:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bq6Ts+IcirU for ; Wed, 10 Apr 2013 01:16:48 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB2521F8629 for ; Wed, 10 Apr 2013 01:16:48 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so92192qea.21 for ; Wed, 10 Apr 2013 01:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fxCebci7naKsgLtZZI8XSm6kt6ichKNtZ3Empt9w7ho=; b=hyENmjTW5UT6GJDvwSspNs1e02WrSbe+XPiTBAMuqNSZNsJ2YlUAjHQzJAvQx7hmXa 1CAES1X52WUAyrunHXXQkgmyovPorHYriUdTRsjk8II98pGQOPEUQxNvf0bgnNpwV6tg 6iAAWuR8b/M3mhBaAC+/ksoY49zrgGka9nW4PVxXdI4PvCQFL/g8s00EyGBFWZh5m+Ni zDXL6+Mh67mcchhqBRBR34b8QUWdJhbobGU5yuno8OTgOQI5VcQgN4we8p2sUEPeLxXg GzttAA6O4ww5lAcUKwX9Ld170GADq1ObmEwjrhIp4z1FX8XcKkUj4vb9EHrdePGxSR39 iWZg== MIME-Version: 1.0 X-Received: by 10.229.169.71 with SMTP id x7mr201312qcy.109.1365581807896; Wed, 10 Apr 2013 01:16:47 -0700 (PDT) Received: by 10.229.117.16 with HTTP; Wed, 10 Apr 2013 01:16:47 -0700 (PDT) Date: Wed, 10 Apr 2013 10:16:47 +0200 Message-ID: From: Nikos Mavrogiannopoulos To: "tls@ietf.org" , sfriedl@cisco.com, andreipo@microsoft.com Content-Type: multipart/alternative; boundary=e89a8f642e8e92566504d9fd4aca X-Mailman-Approved-At: Wed, 10 Apr 2013 08:31:14 -0700 Subject: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 08:16:49 -0000 --e89a8f642e8e92566504d9fd4aca Content-Type: text/plain; charset=UTF-8 Hello, Some comments on the ALPN document. * At some point the document explains the term Protocols as: "are named by IANA registered, opaque, non-empty byte strings." This is not very explanatory. The first question that arises, is which IANA registry are these registered at? By reading the IANA considerations section I see a new registry being created with protocol entries, so at that point I can assume that this is the IANA registry intended, or not? Anyway I think the text should clarify that the IANA registry it refers to is defined in the same document. * In section 3.1, the server replies with the same extension and sends a ProtocolNameList containing a single Protocol. Why is then a list sent by the server? Why not send a single Protocol instead? Is there any use case where the client would accept more than one protocols? In that case should clients be prepared for servers that send more than one protocols? * In the same section it is mentioned: "The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages.". Why is that mentioned at all? Is there an option in TLS not to include that data in the TLS finished message hashes? regards, Nikos --e89a8f642e8e92566504d9fd4aca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
=C2=A0Some comments on the = ALPN document.

* At some point the document explains the term = Protocols as: "are=C2=A0 named by IANA registered, opaque, non-empty b= yte strings."

This is not very explanatory. The first question that arises, is = which IANA registry are these registered at? By reading the IANA considerat= ions section I see a new registry being created with protocol entries, so a= t that point I can assume that this is the IANA registry intended, or not? = Anyway I think the text should clarify that the IANA registry it refers to = is defined in the same document.

* In section 3.1, the server replies with the= same extension and sends a ProtocolNameList containing a single Protocol. = Why is then a list sent by the server? Why not send a single Protocol inste= ad? Is there any use case where the client would accept more than one proto= cols? In that case should clients be prepared for servers that send more th= an one protocols?

* In the same section it is mentioned: "The additional content ass= ociated with this extension MUST be included in the hash calculations assoc= iated with the "Finished" messages.". Why is that mentioned = at all? Is there an option in TLS not to include that data in the TLS finis= hed message hashes?

regards,
Nikos

<= /div>
--e89a8f642e8e92566504d9fd4aca-- From piyush@ditenity.com Wed Apr 10 09:32:54 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C079D21F8C03 for ; Wed, 10 Apr 2013 09:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=1.454, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PBlzUEZECkv for ; Wed, 10 Apr 2013 09:32:53 -0700 (PDT) Received: from mail-ye0-f169.google.com (mail-ye0-f169.google.com [209.85.213.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6921F8B45 for ; Wed, 10 Apr 2013 09:32:53 -0700 (PDT) Received: by mail-ye0-f169.google.com with SMTP id q14so83723yen.14 for ; Wed, 10 Apr 2013 09:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=1LJTVXqdIAfXV3G5eSyKG7vf0ZppxD2olto4493foaI=; b=CAWyvffAgJgbZsh15ooCzWnGWeaNppjcpNR1iqX0HXJp/VfGhkg8TlAZaMODpEoAA3 L2KsNgvaaHhFSoDB1ckyo3WhFi2/ch7D/lA0F4hgr1DtKQFrU59xfb2uouqJ+J9Mhalk JcbuCfe2ByRp3XocKO9ZqUqruTmDX9PPdiyKqAx63N2iUpjbqLqCrEQvopzrtuJkMv33 EaBE99gSU+ktT1K/psAAIOSvm7WJdywy5OXLANuXzKtVzb1GYR+hWxjlXAweeh68yFxw 6npDWzL6q0ihryexuIp3bFVVr8Z4vK2M+IzlJZEAhbOm64rGAaGmwJp8zCly8zG0IjVa djfA== X-Received: by 10.236.26.203 with SMTP id c51mr1610503yha.89.1365611573035; Wed, 10 Apr 2013 09:32:53 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id x33sm808143yhn.18.2013.04.10.09.32.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 09:32:52 -0700 (PDT) From: "Piyush Jain" To: References: <0a1801ce35fa$10283650$3078a2f0$@ditenity.com> <20130410152725.504F61A6A1@ld9781.wdf.sap.corp> In-Reply-To: <20130410152725.504F61A6A1@ld9781.wdf.sap.corp> Date: Wed, 10 Apr 2013 09:32:37 -0700 Message-ID: <0a7101ce3609$04346030$0c9d2090$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMu/Dic7AuqNJNca90RTSzx+63m5ZYOCoHA Content-Language: en-us X-Gm-Message-State: ALoCoQnKc/KxbAaoxUHJ/boYwvAZPomczrOvRwP/ICteKwZAD9BxGaBwavvkdBkE6JhXvZvyeg3x Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:32:54 -0000 Thanks Martin. That is really interesting information. More inline. > This is the theory. > > In theory, theory and practice are the same, in practice, they differ. > > Although the SSLv3 and *ALL* TLS specs have always been very clear that the > correct ording of certificates in the TLS Certificate handshake message is a > MUST requirement, as well as that only the self-signed rootCA cert at the > end of the path may be omitted, a number of TLS implementations are > notoriously broken in that they will send arbitrary garbled paths that may > include alien certs and even expired certs in Certificate handshake messages > (rather than telling the server admin that the configuration is incorrect). [Piyush] Isn't it a tacit assumption for TLS cached objects that certificate_list will be ordered. The question is if the broken implementations can make use of these proposed extensions effectively and if not then should we really care. > > Although this is not even mentioned in the TLS spec, a number of SSL and TLS > clients will perform various hacks to accomodate for such broken TLS server > implementations, ranging from simple reordering of certificate, to the > extreme of using only the very first certificate from the servers TLS > Certificate handshake message, throw the remaining certificates into a large > pool of candidate path certificates and perform a full certificate path > discovery. [Piyush] So what would be the cached representation of such chains? The original list that the server sent or the corrected ordered list that the client created? If it is the former, the client can still indicate the certificates for which it needs the status through a list of Boolean values. If it is the latter then server has no way to resolve the certificate_list cached object and it will need to resend all the information again. But a bigger question is how to create a spec without agreeing on a basic set of assumptions. If the practices that you describe are useful, then they should make their way to the TLS spec. If not we stop taking them into account while designing new specs. > > The latter can lead to seemingly non-deterministic behaviour with some TLS > servers that omit more than the self-signed rootCA cert from the Certificate > handshake message, such as intermediate CA certs, and the client behaviour > changes from handshake failure (untrusted cert) to successful handshake > when that "large pool" of cached certs coincidentally contains the missing > intermediate cert from a prior TLS handshake with a correctly configured TLS > Server whose server cert was issued by the same (intermediate) CA. > [Piyush] A couple of points here: 1) We were basing this discussion assuming that server follows the TLS spec correctly and provides all the required certificates in the correct order. It was limited to client using OCSP responses from different sources and was not about client using intermediate certificates from other sources. 2) Not relevant to the current discussion but still interesting. Why does it matter whether the client obtained the intermediate certificate from the same server, a different server, an ldap or http repository as long as it can build the chain to a trusted root? I appreciate your point about server not catching the error of it ways right away in case of handshake failure if some clients are smart enough to perform certificate discovery. In fact allowing the server to just send its certificate without any issuer certificates can actually optimize the TLS handshake if the client delegates the path validation and discovery to an external DPV server. > > I remember that in march 2001 "https://www.verisign.com" was sending and > expired VeriSign rootCA certificate in the server certificate handshake > message. When I reported this defect to VeriSign Support, they did (at least > initially) not understand that this indicated (a) a defect (or at least significant > sloppiness) in their server's SSL/TLS implementation and (b) a server > configuration errror. > Again, this is very interesting information. Delivering root certificate and that too expired one in TLS handshake is sloppy. I hope that the clients were not sloppy enough to start using those as trust anchors. :) Now that you mention it, it is probably a common practice for many x.509 applications. The assumption is that you are providing a bag of certificates to the peer so that he can select the right ones to build a trusted path to a pre-configured trust anchor. [Piyush] > -Martin From piyush@ditenity.com Wed Apr 10 09:35:02 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0521F8CC9 for ; Wed, 10 Apr 2013 09:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=1.309, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3dJOpHCsuBx for ; Wed, 10 Apr 2013 09:35:02 -0700 (PDT) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3064F21F8CA0 for ; Wed, 10 Apr 2013 09:35:02 -0700 (PDT) Received: by mail-gh0-f182.google.com with SMTP id z15so86249ghb.27 for ; Wed, 10 Apr 2013 09:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=yyUmB3MT/FAr3FeGkL+5F9V3ZNzjPg5g61Fmg9f2tSE=; b=iOf04NdTvpmWnogET7lsHN8mmorHClf1p8RxEyIeT3nV1m+jlfdlEm/KEZDN4lklyW BB3BvggpIaCEHKEsSj2HXqoj048502CwGpZo6oA58aaf4miYtYE+igMy18bH3g5iS0Xv Fa0hMObrcFred7qPZnQu6RQz3c+PIzlfgnbckSiNLevG7kj+1fhPo8Xj4lEc9XTACr0n k6+9SGISdO/6dWnGqQQkG06pZhIzp7CHFR4tFwo14jWnv40xwjFp9KcYBK8Aoqst/3Mf pcZC1mTc7vat0xzSk+vMzdR9a1cWWwv43wK51fb5PFDX+Nf57DwmIXoyvg/XgaBYmtwd /kCw== X-Received: by 10.236.131.1 with SMTP id l1mr1620939yhi.21.1365611701729; Wed, 10 Apr 2013 09:35:01 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id o31sm800743yhh.21.2013.04.10.09.35.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 09:35:01 -0700 (PDT) From: "Piyush Jain" To: "'Yngve N. Pettersen'" , , "'Rob Stradling'" References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <5163200D.2030300@comodo.com> <51646709.4030803@comodo.com> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> <0a1801ce35fa$10283650$3078a2f0$@ditenity.com> In-Reply-To: Date: Wed, 10 Apr 2013 09:34:46 -0700 Message-ID: <0a7301ce3609$513d71f0$f3b855d0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlAb7NsstXjqmQRSHXKYXg2JOPjAHY6j2EAi7U10ICrEPZfgKTKz73AOQ2LZoBb2wfGgHhzkwPAfgjWBgCU4m1cQJXslm/AcH7iVICHlM1kgJCjcGGAZUIKUoBeJgCX5a3gTrg Content-Language: en-us X-Gm-Message-State: ALoCoQmPQMEGb1JW647b1V5MIfToR+c64U7VHRMqpSli2qJ2Dtx6PfSyZutOvwJqf3kGsKLpdOg/ Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:35:02 -0000 > > [Piyush] Not sure if I understood it correctly. TLS has strict > > guidelines on > > "Chain sequence" was maybe the wrong expression. The point was that the > server can change to a completely new set of certificates, including an > unrelated certificate authority. [Piyush] Agreed. However, this is usually a rare event. And the cached certificate_list and stapled OCSP responses would become invalid anyway. > > However, some server can have certificates incorrectly ordered, and that > might get fixed after a while (or it could get broken). [Piyush] It probably does not matter as long as the client is assuming the same order that it received. Please note that certificate_list cache representation is a single hash. All the client is saying is that this is the certificate list (containing certificates a,b,c,d) that I have cached and btw I don't need the status for "a" and "b" but I need the status for "c" and "d". > > > sequence of certificates in the chain. The certificate chain sequence > > would change only when the server certificate changes (or in some rare > > cases when intermediate CA's certificate rolls over). Right? If that > > happens than certificate_list cached object held by the client would > > become invalid and consequently any stapled responses associated with > > the old certificate chain would also become invalid. > > My point is that the information sent to the server about which resources are > cached need to connect the resources to what the server have, in such a way > that if the server configuration changes the server will know that it does not > have the necessary information. > [Piyush] That requirement is met. If the server configuration is changed in the way that you describe above, certificate_list cache becomes invalid and consequently the OCSP response cache becomes invalid. In other words the server will send the certificate list again and all the OCSP responses again. This would be the behavior even when you fingerprint the OCSP responses. I think it becomes more intuitive if you think about the actual goal from client's perspective. Clients need to determine the status of each certificate in the server certificate chain. They don't need to make sure that the OCSPResponses that they use to make this determination are in sync with those on the server. The way I see it stapled OCSP responses are not resources on the TLS server. TLS server is just a channel that delivers these responses to the client. From Andrei.Popov@microsoft.com Wed Apr 10 10:42:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9021F8E3C for ; Wed, 10 Apr 2013 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GC+20RX4q+J for ; Wed, 10 Apr 2013 10:42:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2BE21F8E04 for ; Wed, 10 Apr 2013 10:42:54 -0700 (PDT) Received: from BL2FFO11FD007.protection.gbl (10.1.15.200) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.664.0; Wed, 10 Apr 2013 17:43:26 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Wed, 10 Apr 2013 17:42:52 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 10 Apr 2013 17:42:45 +0000 Received: from mail204-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 10 Apr 2013 17:40:27 +0000 Received: from mail204-va3 (localhost [127.0.0.1]) by mail204-va3-R.bigfish.com (Postfix) with ESMTP id EDE30B000EA for ; Wed, 10 Apr 2013 17:40:26 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zz9371Ic89bhc857h4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh9a9j1155h) Received-SPF: softfail (mail204-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR03MB068; H:BLUPR03MB068.namprd03.prod.outlook.com; LANG:en; Received: from mail204-va3 (localhost.localdomain [127.0.0.1]) by mail204-va3 (MessageSwitch) id 1365615624544804_28467; Wed, 10 Apr 2013 17:40:24 +0000 (UTC) Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.227]) by mail204-va3.bigfish.com (Postfix) with ESMTP id 8092940005D; Wed, 10 Apr 2013 17:40:24 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Apr 2013 17:40:23 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com (10.255.209.156) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.287.3; Wed, 10 Apr 2013 17:40:23 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com (10.255.209.156) by BLUPR03MB068.namprd03.prod.outlook.com (10.255.209.156) with Microsoft SMTP Server (TLS) id 15.0.670.13; Wed, 10 Apr 2013 17:40:21 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com ([169.254.12.98]) by BLUPR03MB068.namprd03.prod.outlook.com ([169.254.12.98]) with mapi id 15.00.0670.000; Wed, 10 Apr 2013 17:40:21 +0000 From: Andrei Popov To: Nikos Mavrogiannopoulos , "tls@ietf.org" , "sfriedl@cisco.com" Thread-Topic: comments on draft-ietf-tls-applayerprotoneg-00 Thread-Index: AQHONcPtSs4jEEkM50KXgwJ1gKjlFpjPsQHQ Date: Wed, 10 Apr 2013 17:40:21 +0000 Message-ID: <809fc77c0e08473a97502c346b6f4a7c@BLUPR03MB068.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.4] Content-Type: multipart/alternative; boundary="_000_809fc77c0e08473a97502c346b6f4a7cBLUPR03MB068namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BLUPR03MB068.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(76482001)(20776003)(47976001)(79102001)(51856001)(4396001)(53806001)(54356001)(33646001)(81342001)(77982001)(6806001)(512874001)(16676001)(564824004)(81542001)(59766001)(31966008)(74662001)(47446002)(69226001)(74502001)(80022001)(65816001)(71186001)(54316002)(46102001)(56816002)(50986001)(56776001)(44976002)(63696002)(18276755001)(47736001)(49866001)(18277545001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0812095267 Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:42:56 -0000 --_000_809fc77c0e08473a97502c346b6f4a7cBLUPR03MB068namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmlrb3MsDQoNCiogU2VjdGlvbiA2IOKAnElBTkEgQ29uc2lkZXJhdGlvbnPigJ0gc2F5czoN Cg0K4oCmIFdlIHByb3Bvc2UgdGhhdCB0aGlzIG5ldyByZWdpc3RyeSBiZSBjcmVhdGVkIGluIGEg bmV3IHBhZ2UgZW50aXRsZWQ6DQoiQXBwbGljYXRpb24gTGF5ZXIgUHJvdG9jb2wgTmVnb3RpYXRp b24gKEFMUE4pIFByb3RvY29sIElEcyIgYmVuZWF0aA0KdGhlIGV4aXN0aW5nIGhlYWRpbmcgb2Yg IlRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSIuDQoNClByb3RvY29sIElEcyBhcmUgZmly c3QgaW50cm9kdWNlZCBpbiBzZWN0aW9uIDMuMSDigJxUaGUgQXBwbGljYXRpb24gTGF5ZXIgUHJv dG9jb2wgTmVnb3RpYXRpb24gRXh0ZW5zaW9u4oCdLiBIZXJlIHdlIGNhbiBhZGQgYSByZWZlcmVu Y2UgdG8gc2VjdGlvbiA2IHRvIG1ha2UgdGhpcyBtb3JlIGNsZWFyLg0KDQoqIEluIEFMUE4sIHRo ZSBzZXJ2ZXIgY2Fubm90IHNlbGVjdCBtb3JlIHRoYW4gb25lIHByb3RvY29sIChzZWUgc2VjdGlv bnMgMy4xIGFuZCAzLjIpLiBUaGUgcmVhc29uIHRoZSBzZXJ2ZXIgaXMgc2VuZGluZyBhIHByb3Rv Y29sX25hbWVfbGlzdCBpcyB0aGF0IGtlZXBpbmcgY2xpZW50LXNpZGUg4oCcZXh0ZW5zaW9uX2Rh dGHigJ0gc3RydWN0dXJlIGlkZW50aWNhbCB0byB0aGUgc2VydmVyLXNpZGUg4oCcZXh0ZW5zaW9u X2RhdGHigJ0gc3RydWN0dXJlIHNpbXBsaWZpZXMgYm90aCB0aGUgZG9jdW1lbnRhdGlvbiBhbmQg dGhlIGltcGxlbWVudGF0aW9uLg0KDQoqIFRoZSB0ZXh0IGFib3V0IHRoZSBoYXNoIGNhbGN1bGF0 aW9ucyB3YXMgaW50ZW5kZWQgdG8gbWFrZSBpdCBhYnNvbHV0ZWx5IGNsZWFyIHRoYXQgdGhlIGNv bnRlbnQgb2YgdGhlIG5ldyBleHRlbnNpb24gaXMgaW5jbHVkZWQgaW4gdGhlIGhhc2ggY2FsY3Vs YXRpb25zLCBhbmQgYXZvaWQgYW55IGFtYmlndWl0eS4gVGhlIG5lZWQgZm9yIHRoaXMgY2xhcmlm aWNhdGlvbiBhcmlzZXMgZnJvbSB0aGUgZmFjdCB0aGF0IEFMUE4sIHVubGlrZSBtYW55IG90aGVy IFRMUyBleHRlbnNpb25zLCBuZWdvdGlhdGVzIHBhcmFtZXRlcnMgdGhhdCBoYXZlIG5vdGhpbmcg dG8gZG8gd2l0aCB0aGUgVExTIHByb3RvY29sIGl0c2VsZi4NCg0KVGhhbmtzLA0KDQpBbmRyZWkN Cg0KRnJvbTogTmlrb3MgTWF2cm9naWFubm9wb3Vsb3MgW21haWx0bzpuLm1hdnJvZ2lhbm5vcG91 bG9zQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTAsIDIwMTMgMToxNyBBTQ0K VG86IHRsc0BpZXRmLm9yZzsgc2ZyaWVkbEBjaXNjby5jb207IEFuZHJlaSBQb3Bvdg0KU3ViamVj dDogY29tbWVudHMgb24gZHJhZnQtaWV0Zi10bHMtYXBwbGF5ZXJwcm90b25lZy0wMA0KDQpIZWxs bywNCiBTb21lIGNvbW1lbnRzIG9uIHRoZSBBTFBOIGRvY3VtZW50Lg0KKiBBdCBzb21lIHBvaW50 IHRoZSBkb2N1bWVudCBleHBsYWlucyB0aGUgdGVybSBQcm90b2NvbHMgYXM6ICJhcmUgIG5hbWVk IGJ5IElBTkEgcmVnaXN0ZXJlZCwgb3BhcXVlLCBub24tZW1wdHkgYnl0ZSBzdHJpbmdzLiINClRo aXMgaXMgbm90IHZlcnkgZXhwbGFuYXRvcnkuIFRoZSBmaXJzdCBxdWVzdGlvbiB0aGF0IGFyaXNl cywgaXMgd2hpY2ggSUFOQSByZWdpc3RyeSBhcmUgdGhlc2UgcmVnaXN0ZXJlZCBhdD8gQnkgcmVh ZGluZyB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIEkgc2VlIGEgbmV3IHJlZ2lzdHJ5 IGJlaW5nIGNyZWF0ZWQgd2l0aCBwcm90b2NvbCBlbnRyaWVzLCBzbyBhdCB0aGF0IHBvaW50IEkg Y2FuIGFzc3VtZSB0aGF0IHRoaXMgaXMgdGhlIElBTkEgcmVnaXN0cnkgaW50ZW5kZWQsIG9yIG5v dD8gQW55d2F5IEkgdGhpbmsgdGhlIHRleHQgc2hvdWxkIGNsYXJpZnkgdGhhdCB0aGUgSUFOQSBy ZWdpc3RyeSBpdCByZWZlcnMgdG8gaXMgZGVmaW5lZCBpbiB0aGUgc2FtZSBkb2N1bWVudC4NCg0K KiBJbiBzZWN0aW9uIDMuMSwgdGhlIHNlcnZlciByZXBsaWVzIHdpdGggdGhlIHNhbWUgZXh0ZW5z aW9uIGFuZCBzZW5kcyBhIFByb3RvY29sTmFtZUxpc3QgY29udGFpbmluZyBhIHNpbmdsZSBQcm90 b2NvbC4gV2h5IGlzIHRoZW4gYSBsaXN0IHNlbnQgYnkgdGhlIHNlcnZlcj8gV2h5IG5vdCBzZW5k IGEgc2luZ2xlIFByb3RvY29sIGluc3RlYWQ/IElzIHRoZXJlIGFueSB1c2UgY2FzZSB3aGVyZSB0 aGUgY2xpZW50IHdvdWxkIGFjY2VwdCBtb3JlIHRoYW4gb25lIHByb3RvY29scz8gSW4gdGhhdCBj YXNlIHNob3VsZCBjbGllbnRzIGJlIHByZXBhcmVkIGZvciBzZXJ2ZXJzIHRoYXQgc2VuZCBtb3Jl IHRoYW4gb25lIHByb3RvY29scz8NCg0KKiBJbiB0aGUgc2FtZSBzZWN0aW9uIGl0IGlzIG1lbnRp b25lZDogIlRoZSBhZGRpdGlvbmFsIGNvbnRlbnQgYXNzb2NpYXRlZCB3aXRoIHRoaXMgZXh0ZW5z aW9uIE1VU1QgYmUgaW5jbHVkZWQgaW4gdGhlIGhhc2ggY2FsY3VsYXRpb25zIGFzc29jaWF0ZWQg d2l0aCB0aGUgIkZpbmlzaGVkIiBtZXNzYWdlcy4iLiBXaHkgaXMgdGhhdCBtZW50aW9uZWQgYXQg YWxsPyBJcyB0aGVyZSBhbiBvcHRpb24gaW4gVExTIG5vdCB0byBpbmNsdWRlIHRoYXQgZGF0YSBp biB0aGUgVExTIGZpbmlzaGVkIG1lc3NhZ2UgaGFzaGVzPw0KDQpyZWdhcmRzLA0KTmlrb3MNCg== --_000_809fc77c0e08473a97502c346b6f4a7cBLUPR03MB068namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6OTg4Mzk3ODI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0zOTA1NzA5MjQgMTIwNjAwNDM1MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjUwNzc7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjYw OTk3NTc4OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE0ODMyODgyNTYgNjI2OTQ3NzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDo1MDc3Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxOTcxOTM5MzEyOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDc0MDkxOTA2 IC0xMzAxMTI0NjkyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6NTA3NzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBOaWtvcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiogU2VjdGlvbiA2IOKAnElBTkEgQ29uc2lkZXJhdGlvbnPigJ0gc2F5czo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPuKApiBXZSBwcm9wb3NlIHRoYXQgdGhpcyBuZXcgcmVnaXN0cnkgYmUgY3JlYXRlZCBp biBhIG5ldyBwYWdlIGVudGl0bGVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mcXVv dDtBcHBsaWNhdGlvbiBMYXllciBQcm90b2NvbCBOZWdvdGlhdGlvbiAoQUxQTikgUHJvdG9jb2wg SURzJnF1b3Q7IGJlbmVhdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIGV4aXN0 aW5nIGhlYWRpbmcgb2YgJnF1b3Q7VHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpJnF1b3Q7 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UHJvdG9jb2wgSURzIGFyZSBmaXJzdCBpbnRyb2R1Y2VkIGluIHNlY3Rpb24g My4xIOKAnFRoZSBBcHBsaWNhdGlvbiBMYXllciBQcm90b2NvbCBOZWdvdGlhdGlvbiBFeHRlbnNp b27igJ0uIEhlcmUgd2UgY2FuIGFkZCBhIHJlZmVyZW5jZSB0byBzZWN0aW9uIDYgdG8gbWFrZSB0 aGlzDQogbW9yZSBjbGVhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiogSW4gQUxQTiwgdGhlIHNlcnZlciBjYW5ub3Qg c2VsZWN0IG1vcmUgdGhhbiBvbmUgcHJvdG9jb2wgKHNlZSBzZWN0aW9ucyAzLjEgYW5kIDMuMiku IFRoZSByZWFzb24gdGhlIHNlcnZlciBpcyBzZW5kaW5nIGEgcHJvdG9jb2xfbmFtZV9saXN0IGlz IHRoYXQga2VlcGluZw0KIGNsaWVudC1zaWRlIOKAnGV4dGVuc2lvbl9kYXRh4oCdIHN0cnVjdHVy ZSBpZGVudGljYWwgdG8gdGhlIHNlcnZlci1zaWRlIOKAnGV4dGVuc2lvbl9kYXRh4oCdIHN0cnVj dHVyZSBzaW1wbGlmaWVzIGJvdGggdGhlIGRvY3VtZW50YXRpb24gYW5kIHRoZSBpbXBsZW1lbnRh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiogVGhlIHRleHQgYWJvdXQgdGhlIGhhc2ggY2FsY3VsYXRpb25zIHdh cyBpbnRlbmRlZCB0byBtYWtlIGl0IGFic29sdXRlbHkgY2xlYXIgdGhhdCB0aGUgY29udGVudCBv ZiB0aGUgbmV3IGV4dGVuc2lvbiBpcyBpbmNsdWRlZCBpbiB0aGUgaGFzaCBjYWxjdWxhdGlvbnMs DQogYW5kIGF2b2lkIGFueSBhbWJpZ3VpdHkuIFRoZSBuZWVkIGZvciB0aGlzIGNsYXJpZmljYXRp b24gYXJpc2VzIGZyb20gdGhlIGZhY3QgdGhhdCBBTFBOLCB1bmxpa2UgbWFueSBvdGhlciBUTFMg ZXh0ZW5zaW9ucywgbmVnb3RpYXRlcyBwYXJhbWV0ZXJzIHRoYXQgaGF2ZSBub3RoaW5nIHRvIGRv IHdpdGggdGhlIFRMUyBwcm90b2NvbCBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5pa29z IE1hdnJvZ2lhbm5vcG91bG9zIFttYWlsdG86bi5tYXZyb2dpYW5ub3BvdWxvc0BnbWFpbC5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxMyAxOjE3IEFNPGJy Pg0KPGI+VG86PC9iPiB0bHNAaWV0Zi5vcmc7IHNmcmllZGxAY2lzY28uY29tOyBBbmRyZWkgUG9w b3Y8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gY29tbWVudHMgb24gZHJhZnQtaWV0Zi10bHMtYXBwbGF5 ZXJwcm90b25lZy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwO1NvbWUgY29tbWVu dHMgb24gdGhlIEFMUE4gZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+KiBBdCBzb21lIHBvaW50 IHRoZSBkb2N1bWVudCBleHBsYWlucyB0aGUgdGVybSBQcm90b2NvbHMgYXM6ICZxdW90O2FyZSZu YnNwOyBuYW1lZCBieSBJQU5BIHJlZ2lzdGVyZWQsIG9wYXF1ZSwgbm9uLWVtcHR5IGJ5dGUgc3Ry aW5ncy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBpcyBub3QgdmVyeSBleHBsYW5hdG9yeS4gVGhlIGZpcnN0IHF1ZXN0aW9uIHRoYXQgYXJp c2VzLCBpcyB3aGljaCBJQU5BIHJlZ2lzdHJ5IGFyZSB0aGVzZSByZWdpc3RlcmVkIGF0PyBCeSBy ZWFkaW5nIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gSSBzZWUgYSBuZXcgcmVnaXN0 cnkgYmVpbmcgY3JlYXRlZCB3aXRoIHByb3RvY29sIGVudHJpZXMsIHNvIGF0IHRoYXQgcG9pbnQg SSBjYW4gYXNzdW1lDQogdGhhdCB0aGlzIGlzIHRoZSBJQU5BIHJlZ2lzdHJ5IGludGVuZGVkLCBv ciBub3Q/IEFueXdheSBJIHRoaW5rIHRoZSB0ZXh0IHNob3VsZCBjbGFyaWZ5IHRoYXQgdGhlIElB TkEgcmVnaXN0cnkgaXQgcmVmZXJzIHRvIGlzIGRlZmluZWQgaW4gdGhlIHNhbWUgZG9jdW1lbnQu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiogSW4gc2VjdGlvbiAzLjEsIHRoZSBzZXJ2ZXIgcmVwbGllcyB3aXRoIHRoZSBzYW1lIGV4 dGVuc2lvbiBhbmQgc2VuZHMgYSBQcm90b2NvbE5hbWVMaXN0IGNvbnRhaW5pbmcgYSBzaW5nbGUg UHJvdG9jb2wuIFdoeSBpcyB0aGVuIGEgbGlzdCBzZW50IGJ5IHRoZSBzZXJ2ZXI/IFdoeSBub3Qg c2VuZCBhIHNpbmdsZSBQcm90b2NvbCBpbnN0ZWFkPyBJcyB0aGVyZSBhbnkgdXNlIGNhc2Ugd2hl cmUgdGhlIGNsaWVudA0KIHdvdWxkIGFjY2VwdCBtb3JlIHRoYW4gb25lIHByb3RvY29scz8gSW4g dGhhdCBjYXNlIHNob3VsZCBjbGllbnRzIGJlIHByZXBhcmVkIGZvciBzZXJ2ZXJzIHRoYXQgc2Vu ZCBtb3JlIHRoYW4gb25lIHByb3RvY29scz88YnI+DQo8YnI+DQoqIEluIHRoZSBzYW1lIHNlY3Rp b24gaXQgaXMgbWVudGlvbmVkOiAmcXVvdDtUaGUgYWRkaXRpb25hbCBjb250ZW50IGFzc29jaWF0 ZWQgd2l0aCB0aGlzIGV4dGVuc2lvbiBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBoYXNoIGNhbGN1 bGF0aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlICZxdW90O0ZpbmlzaGVkJnF1b3Q7IG1lc3NhZ2Vz LiZxdW90Oy4gV2h5IGlzIHRoYXQgbWVudGlvbmVkIGF0IGFsbD8gSXMgdGhlcmUgYW4gb3B0aW9u IGluIFRMUyBub3QgdG8gaW5jbHVkZSB0aGF0IGRhdGENCiBpbiB0aGUgVExTIGZpbmlzaGVkIG1l c3NhZ2UgaGFzaGVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5OaWtvczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_809fc77c0e08473a97502c346b6f4a7cBLUPR03MB068namprd03pro_-- From mrex@sap.com Wed Apr 10 12:10:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC99821F9375 for ; Wed, 10 Apr 2013 12:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owyn3HHskZTA for ; Wed, 10 Apr 2013 12:10:48 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 74E0B21F9357 for ; Wed, 10 Apr 2013 12:10:48 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r3AJAcSQ024923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 21:10:38 +0200 (MEST) In-Reply-To: <0a7101ce3609$04346030$0c9d2090$@ditenity.com> To: Piyush Jain Date: Wed, 10 Apr 2013 21:10:38 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130410191038.8B0001A6A2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 19:10:50 -0000 Piyush Jain wrote: > > Thanks Martin. That is really interesting information. > More inline. > > > This is the theory. > > > > In theory, theory and practice are the same, in practice, they differ. > > > > Although the SSLv3 and *ALL* TLS specs have always been very clear that > > the correct ording of certificates in the TLS Certificate handshake > > message is a MUST requirement, as well as that only the self-signed > > rootCA cert at the end of the path may be omitted, a number of TLS > > implementations are notoriously broken in that they will send > > arbitrary garbled paths that may include alien certs and even > > expired certs in Certificate handshake messages (rather than telling > > the server admin that the configuration is incorrect). > > [Piyush] Isn't it a tacit assumption for TLS cached objects that > certificate_list will be ordered. The question is if the broken > implementations can make use of these proposed extensions effectively > and if not then should we really care. The TLS caching extension ought to operate *STRICTLY* at the TLS PDU level (as sent over the wire), everything else will be calling for trouble. At the PDU level / wire format, the ordering of certificates is implied by the PDUs being 1-dimensional sequences of octets. Wether the certificate_list structure properly forms a certificate chain according to the TLS specification (section 7.4.2) should better be irrelevant to the TLS caching extension (KISS principle). TLSv1.2: http://tools.ietf.org/html/rfc5246#page-48 TLSv1.1: http://tools.ietf.org/html/rfc4346#page-41 TLSv1.0: http://tools.ietf.org/html/rfc2246#page-39 SSLv3: http://tools.ietf.org/html/rfc6101#page-28 certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. > > > > Although this is not even mentioned in the TLS spec, a number of SSL and > > TLS clients will perform various hacks to accomodate for such broken TLS > > server implementations, ranging from simple reordering of certificate, > > to the extreme of using only the very first certificate from the servers > > TLS Certificate handshake message, throw the remaining certificates > > into a large pool of candidate path certificates and perform a full > > certificate path discovery. > > [Piyush] So what would be the cached representation of such chains? The > original list that the server sent or the corrected ordered list that the > client created? Exactly what goes on the wire. Right when the Server composes the TLS Certificate handshake message, it ought to compare what it intends to send certificate_list in the Certificate handshake message with the hash value conveyed by the client and replace (omit the real) data when the hash matches. That is the simple, straight-forward and fail-safe approach. > > > The latter can lead to seemingly non-deterministic behaviour with some > > TLS servers that omit more than the self-signed rootCA cert from the > > Certificate handshake message, such as intermediate CA certs, and the > > client behaviour changes from handshake failure (untrusted cert) to > > successful handshake when that "large pool" of cached certs > > coincidentally contains the missing intermediate cert from a prior > > TLS handshake with a correctly configured TLS Server whose server > > cert was issued by the same (intermediate) CA. > > [Piyush] A couple of points here: > > 1) We were basing this discussion assuming that server follows the TLS spec > correctly and provides all the required certificates in the correct order. > It was limited to client using OCSP responses from different sources and was > not about client using intermediate certificates from other sources. In theory, yes. Existing TLS implementations could even fix any currently defective behaviour and sort the certificates prior to composing the TLS Certificate handshake message without fear of breaking interop, and to conform to what the TLS spec has always been requiring. For efficiency, any such certificate sorting and certificate sanity checking should probably done very early (and therefore just once) during the TLS API calls through which the TLS certificate chain is provided to the TLS implementation, rather than at the lowest level of the software stack, every time when the TLS Certificate PDU is assembled. > > 2) Not relevant to the current discussion but still interesting. Why does it > matter whether the client obtained the intermediate certificate from the > same server, a different server, an ldap or http repository as long as it > can build the chain to a trusted root? http://en.wikipedia.org/wiki/Principle_of_least_surprise (... unless you are in the fortunate position to charge an arm and a leg for support and every individual support request on top of it, and want to ensure that your customers can not understand nor predict the behaviour of your software without your support's help.) > > I appreciate your point about server not catching the error of it > ways right away in case of handshake failure if some clients are > smart enough to perform certificate discovery. On my personal scorecard of engineering goofs, a full certificate path discovery during the TLS handshake is pretty broken, adding certs obtained from other handshake is extremely broken, and the diamond level of engineering goofs is unattended/non-interactive forward AIA chasing for missing intermediate CA certs. > > In fact allowing the server to just send its certificate without any issuer > certificates can actually optimize the TLS handshake if the client delegates > the path validation and discovery to an external DPV server. Terribly BAD idea. The correct engineering approach is to use suitable existing TLS protocol features or TLS extension with the appropriate semantics for that purpose. For the Server Certificate (chain) either this one (Trusted CA Indication): http://tools.ietf.org/html/rfc3546#section-3.4 or the TLS caching extension under discussion. For the TLS client certificate, the list of certification_authorities acceptable to the TLS server can be used for the client to figure out which path CA certificates it needs to send, and which CA certificates the client can omit from the client Certificate handshake message. > > > I remember that in march 2001 "https://www.verisign.com" was sending and > > expired VeriSign rootCA certificate in the server certificate handshake > > message. When I reported this defect to VeriSign Support, they did > > (at least initially) not understand that this indicated (a) a defect > > (or at least significant sloppiness) in their server's SSL/TLS > > implementation and (b) a server configuration errror. > > > Again, this is very interesting information. Delivering root certificate and > that too expired one in TLS handshake is sloppy. Delivering the rootCA cert in the handshake is perfectly reasonable! Silently delivering an expired CA cert in the forward certification path for more than a year after it expired suggests that there are a number of serious problems with the underlying TLS implementation. > > I hope that the clients were not sloppy enough to start using those > as trust anchors. :) Actually, I would not count on clients _not_ being that dumb. The original "modest" warning popup from Browsers about problems with server certs seems to have been so "harmless" for novice users, that it seems to have been replace by a "Scary Page" in most Browsers. On top of that, some clients may allow communication peers to provide in-band a "renewed" trust-anchor with an extended certificate validity for any existing, but expired trust-anchor that is already in the clients posession, causing the certificate path validation to succeed. Depending on how many old expired trust anchors are still in the trust anchor store, and how long the client permits that in-band trust anchor update, there _might_ be a dormant security problem. > > Now that you mention it, it is probably a common practice for many x.509 > applications. The assumption is that you are providing a bag of certificates > to the peer so that he can select the right ones to build a trusted path to > a pre-configured trust anchor. I'm pretty sure that there is PKI Software out there which is broken far beyond my wildest/worst dreams. For the majority of consumers, convenience seems to be significantly more important than security, and a lot of vendors and developers not only catering to such desire but regularly add additional, extremely questionable "value" on top of that, making it a worst common practice that users at some point begin to "expect" even from reasonable implementors. -Martin From mrex@sap.com Wed Apr 10 13:26:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ABD21F930C for ; Wed, 10 Apr 2013 13:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFz8HBcLNcj2 for ; Wed, 10 Apr 2013 13:26:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3520221F92F2 for ; Wed, 10 Apr 2013 13:26:27 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r3AKQAwS011232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 22:26:11 +0200 (MEST) In-Reply-To: <809fc77c0e08473a97502c346b6f4a7c@BLUPR03MB068.namprd03.prod.outlook.com> To: Andrei Popov Date: Wed, 10 Apr 2013 22:26:10 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130410202610.D3EF31A6A2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 20:26:30 -0000 Andrei Popov wrote: > > Nikos Mavrogiannopoulos wrote: > > > > * In the same section it is mentioned: "The additional content > > associated with this extension MUST be included in the hash > > calculations associated with the "Finished" messages.". > > Why is that mentioned at all? Is there an option in TLS not > > to include that data in the TLS finished message hashes? > > * The text about the hash calculations was intended to make it > absolutely clear that the content of the new extension is included > in the hash calculations, and avoid any ambiguity. The need for this > clarification arises from the fact that ALPN, unlike many other > TLS extensions, negotiates parameters that have nothing to do with > the TLS protocol itself. I absolutely agree with Nikos, that this paragraph (4th pagagraph on) http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#page-4 The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. is completely bogus and has a creates several new ambiguities where originally (rfc2246) non existed. To the authors defense, a vaguely related (but different, and no less bogus) paragraph is part of rfc3646/rfc4366/rfc6066 (TLS Extensions): http://tools.ietf.org/html/rfc3546#section-3 http://tools.ietf.org/html/rfc6066#page-4 Note that any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages. but that doesn't make it any less bogus nor less non-sensical this time around. ;-) The governing part is the forward compatibility note at the end of rfc2246 section 7.4.1.2, which was retroactively added to the SSLv3 spec in November 1996: http://tools.ietf.org/html/rfc2246#page-36 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely. A similar note was retroactively inserted into the SSLv3 spec somewhere around Oct-Nov. 1996 _after_ SSLv3 implementations had been widely deployed: http://tools.ietf.org/html/rfc6101#page-27 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0038.html Neither excluding the entire "extra data after the compression methods" in ClientHello, nor excluding specific subsets of such extra data would be interoperable with mere "forward compatible" SSLv3 and TLS peers, so it is simply **NO** option (and therefore no ambiguity). The paragraph in rfc3546/rfc4366/rfc6066 is bogus, because - none of the TLS extensions defined in these documents adds/defines any (new handshake) messages, only (optional) "extra data following compression_methods" in the existing ClientHello and ServerHello messages. - the fact that the handshake message hash covers all data in the (Extended)ClientHello and (Extended)ServerHello handshake messages is in no way limted to the specific extensions defined in rfc3546/rfc4366/rfc6066, but a strict requirement to any conceivable TLS extension, different to what Section heading "3. Secific Extensions" and wording "any messages associated with these extensions" suggest. - the information is incorrect in that it alleges that it is involved (only) in hash calculations of the "Finished" messages. The truth is, that it is involved in all hash calculations involving "the handshake message hash", and that includes the "CertificateVerify" handshake message! The paragraph in draft-ietf-tls-applayerprotoneg-00 is not just wrong, but also ambiguous: The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#section-3 enum { application_layer_protocol_negotiation(16), (65535) } ExtensionType; The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value. opaque ProtocolName<1..2^8-1>; struct { ProtocolName protocol_name_list<2..2^16-1> } ProtocolNameList; What would "additional content associated with this extension" mean: - ProtocolNameList ? - protocol_name_list ? - extension_data (http://tools.ietf.org/html/rfc3546#section-2.3) - Extension (http://tools.ietf.org/html/rfc3546#section-2.3) In the original SSLv3 and TLS architecture, ALL contents of ALL TLS handshake messages, with the explicit exception of the "ClientHelloRequest" handshake message, are included in the handshake message hash, and therefore in calculations that use the handshake message hash, for CertificateVerify and Finished, and this is not (really) an option at discretion of TLS extensions specifications. -Martin From Andrei.Popov@microsoft.com Wed Apr 10 14:22:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DE321F8FDA for ; Wed, 10 Apr 2013 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CD-IMtSsS8n for ; Wed, 10 Apr 2013 14:22:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 741BD21F8F76 for ; Wed, 10 Apr 2013 14:22:43 -0700 (PDT) Received: from BL2FFO11FD009.protection.gbl (10.173.161.201) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.664.0; Wed, 10 Apr 2013 21:22:41 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Wed, 10 Apr 2013 21:22:41 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 10 Apr 2013 21:22:29 +0000 Received: from mail100-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Wed, 10 Apr 2013 21:21:14 +0000 Received: from mail100-co1 (localhost [127.0.0.1]) by mail100-co1-R.bigfish.com (Postfix) with ESMTP id 7677C54008E for ; Wed, 10 Apr 2013 21:21:14 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I542I1432I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah17ej9a9j1155h) Received-SPF: softfail (mail100-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR03MB067; H:BLUPR03MB068.namprd03.prod.outlook.com; LANG:en; Received: from mail100-co1 (localhost.localdomain [127.0.0.1]) by mail100-co1 (MessageSwitch) id 1365628872581582_28221; Wed, 10 Apr 2013 21:21:12 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.226]) by mail100-co1.bigfish.com (Postfix) with ESMTP id 8141C1C00C3; Wed, 10 Apr 2013 21:21:12 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Apr 2013 21:21:12 +0000 Received: from BLUPR03MB067.namprd03.prod.outlook.com (10.255.209.155) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.287.3; Wed, 10 Apr 2013 21:21:11 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com (10.255.209.156) by BLUPR03MB067.namprd03.prod.outlook.com (10.255.209.155) with Microsoft SMTP Server (TLS) id 15.0.670.13; Wed, 10 Apr 2013 21:21:09 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com ([169.254.12.98]) by BLUPR03MB068.namprd03.prod.outlook.com ([169.254.12.98]) with mapi id 15.00.0670.000; Wed, 10 Apr 2013 21:21:09 +0000 From: Andrei Popov To: "mrex@sap.com" Thread-Topic: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 Thread-Index: AQHONcPtSs4jEEkM50KXgwJ1gKjlFpjPsQHQgAA2vQCAAA4Z8A== Date: Wed, 10 Apr 2013 21:21:08 +0000 Message-ID: <0251f0f1451f4233822d7e898b4420d9@BLUPR03MB068.namprd03.prod.outlook.com> References: <809fc77c0e08473a97502c346b6f4a7c@BLUPR03MB068.namprd03.prod.outlook.com> <20130410202610.D3EF31A6A2@ld9781.wdf.sap.corp> In-Reply-To: <20130410202610.D3EF31A6A2@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:a:2:c085:5cb7:cd84:99c5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BLUPR03MB067.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAP.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(51704002)(377454001)(189002)(164054002)(199002)(24454001)(51856001)(47776003)(53806001)(69226001)(46406002)(33646001)(81342001)(63696002)(76482001)(20776003)(23726001)(44976002)(79102001)(15202345001)(46102001)(65816001)(5343635001)(4396001)(74502001)(77982001)(56816002)(31966008)(50466001)(16676001)(49866001)(5343655001)(59766001)(50986001)(81542001)(54356001)(80022001)(6806001)(47976001)(47736001)(54316002)(74662001)(47446002)(56776001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0812095267 Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 21:22:44 -0000 The purpose of the paragraph was disambiguation, and the paragraph obviousl= y failed at this, so I am OK with removing it. Thanks, Andrei -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Wednesday, April 10, 2013 1:26 PM To: Andrei Popov Cc: Nikos Mavrogiannopoulos; tls@ietf.org; sfriedl@cisco.com Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 Andrei Popov wrote: >=20 > Nikos Mavrogiannopoulos wrote: > > > > * In the same section it is mentioned: "The additional content > > associated with this extension MUST be included in the hash > > calculations associated with the "Finished" messages.". > > Why is that mentioned at all? Is there an option in TLS not > > to include that data in the TLS finished message hashes? >=20 > * The text about the hash calculations was intended to make it > absolutely clear that the content of the new extension is included > in the hash calculations, and avoid any ambiguity. The need for this > clarification arises from the fact that ALPN, unlike many other > TLS extensions, negotiates parameters that have nothing to do with > the TLS protocol itself. I absolutely agree with Nikos, that this paragraph (4th pagagraph on) http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#page-4 The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. is completely bogus and has a creates several new ambiguities where origina= lly (rfc2246) non existed. To the authors defense, a vaguely related (but different, and no less bogus) paragraph is part of rfc3646/rfc4366/rfc6066 (TLS Extensions): http://tools.ietf.org/html/rfc3546#section-3 http://tools.ietf.org/html/rfc6066#page-4 Note that any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages. =20 but that doesn't make it any less bogus nor less non-sensical this time aro= und. ;-) The governing part is the forward compatibility note at the end of rfc2246 = section 7.4.1.2, which was retroactively added to the SSLv3 spec in Novembe= r 1996: http://tools.ietf.org/html/rfc2246#page-36 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely. =20 A similar note was retroactively inserted into the SSLv3 spec somewhere aro= und Oct-Nov. 1996 _after_ SSLv3 implementations had been widely deployed: http://tools.ietf.org/html/rfc6101#page-27 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0038.html Neither excluding the entire "extra data after the compression methods" in ClientHello, nor excluding specific subsets of such extra data would be = interoperable with mere "forward compatible" SSLv3 and TLS peers, so it is = simply **NO** option (and therefore no ambiguity). The paragraph in rfc3546/rfc4366/rfc6066 is bogus, because - none of the TLS extensions defined in these documents adds/defines any (new handshake) messages, only (optional) "extra data following compression_methods" in the existing ClientHello and ServerHello messages. - the fact that the handshake message hash covers all data in the (Extended)ClientHello and (Extended)ServerHello handshake messages is in no way limted to the specific extensions defined in rfc3546/rfc4366/rfc6066, but a strict requirement to any conceivable TLS extension, different to what Section heading "3. Secific Extensions= " and wording "any messages associated with these extensions" suggest. - the information is incorrect in that it alleges that it is involved (only) in hash calculations of the "Finished" messages. The truth is, that it is involved in all hash calculations involving "the handshake message hash", and that includes the "CertificateVerify" handshake message! The paragraph in draft-ietf-tls-applayerprotoneg-00 is not just wrong, but = also ambiguous: The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#section-3 enum { application_layer_protocol_negotiation(16), (65535) } ExtensionType; The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value. opaque ProtocolName<1..2^8-1>; struct { ProtocolName protocol_name_list<2..2^16-1> } ProtocolNameList; What would "additional content associated with this extension" mean: - ProtocolNameList ? - protocol_name_list ? - extension_data (http://tools.ietf.org/html/rfc3546#section-2.3) - Extension (http://tools.ietf.org/html/rfc3546#section-2.3) In the original SSLv3 and TLS architecture, ALL contents of ALL TLS handsha= ke messages, with the explicit exception of the "ClientHelloRequest" handsh= ake message, are included in the handshake message hash, and therefore in c= alculations that use the handshake message hash, for CertificateVerify and = Finished, and this is not (really) an option at discretion of TLS extension= s specifications. -Martin From paul.hoffman@vpnc.org Wed Apr 10 14:33:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7344721F91CE for ; Wed, 10 Apr 2013 14:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scHc6M3aBZjw for ; Wed, 10 Apr 2013 14:33:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CC09A21F91CA for ; Wed, 10 Apr 2013 14:33:26 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3ALXMh2020068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 14:33:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <0251f0f1451f4233822d7e898b4420d9@BLUPR03MB068.namprd03.prod.outlook.com> Date: Wed, 10 Apr 2013 14:33:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <809fc77c0e08473a97502c346b6f4a7c@BLUPR03MB068.namprd03.prod.outlook.com> <20130410202610.D3EF31A6A2@ld9781.wdf.sap.corp> <0251f0f1451f4233822d7e898b4420d9@BLUPR03MB068.namprd03.prod.outlook.com> To: Andrei Popov X-Mailer: Apple Mail (2.1503) Cc: tls@ietf.org Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 21:33:27 -0000 On Apr 10, 2013, at 2:21 PM, Andrei Popov = wrote: > The purpose of the paragraph was disambiguation, and the paragraph = obviously failed at this, so I am OK with removing it. In the IKEv2 spec, the way we found to disambiguate what is and isn't = covered by a signature or hash was to show it in ASCII art without = explaining that the art was there for people who thought there were = options when there were not. --Paul Hoffman= From sfriedl@cisco.com Wed Apr 10 14:41:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78A21F91CF for ; Wed, 10 Apr 2013 14:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RluJgp4q2thO for ; Wed, 10 Apr 2013 14:41:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24B21F9132 for ; Wed, 10 Apr 2013 14:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6731; q=dns/txt; s=iport; t=1365630062; x=1366839662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a7I8LfmZ6ZrPPvPjTwWh9FhWb/Z0cPMBlvArxXPBma0=; b=b+yPnJX3leWLX01BW9Fsc/Zqc+to64VH3HebjuWIheIyrSnMqeMZzb79 XKbghb7LGnjMr3Ra0Vg0GmEUd4VozbgXGuVvZj4vjNgVfYnyAe1e8GNl8 zO6vjYmwY5u/mQSJt6W2dz3PX5BTSLhOyqL3nOLv2t39Q3mjsBxyWrjTc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAGTbZVGtJV2Z/2dsb2JhbABQgwY2wUKBERZ0gh8BAQEEAQI3PwwEAgEIEQEDAQEBChQJBygKFAMGCAIEAQ0FCIgMDL8tjmUmCwIFBoJaYQOUP4Nij22DC4Io X-IronPort-AV: E=Sophos;i="4.87,450,1363132800"; d="scan'208";a="197374876" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 10 Apr 2013 21:41:01 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3ALf1uv010494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 21:41:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.223]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 10 Apr 2013 16:41:01 -0500 From: "Stephan Friedl (sfriedl)" To: Andrei Popov , "mrex@sap.com" Thread-Topic: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 Thread-Index: AQHONcPHTKqBPypIjkSY2WsJQq3d/5jQDTyAgAAuVACAAA9cAP//ruwA Date: Wed, 10 Apr 2013 21:41:00 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B8D525@xmb-aln-x02.cisco.com> References: <809fc77c0e08473a97502c346b6f4a7c@BLUPR03MB068.namprd03.prod.outlook.com> <20130410202610.D3EF31A6A2@ld9781.wdf.sap.corp> <0251f0f1451f4233822d7e898b4420d9@BLUPR03MB068.namprd03.prod.outlook.com> In-Reply-To: <0251f0f1451f4233822d7e898b4420d9@BLUPR03MB068.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.37.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 21:41:05 -0000 Agreed, dropping the paragraph is 100% fine with me. I consulted a number = of TLS extension RFCs, including RFC6066, and saw that point made a couple = times so I included it as well. It struck me as superfluous at the time bu= t I agree that it raises ambiguities that ought not be raised. Thanks for the feedback! Best Wishes, Stephan -----Original Message----- From: Andrei Popov [mailto:Andrei.Popov@microsoft.com]=20 Sent: Wednesday, April 10, 2013 3:21 PM To: mrex@sap.com Cc: Nikos Mavrogiannopoulos; tls@ietf.org; Stephan Friedl (sfriedl) Subject: RE: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 The purpose of the paragraph was disambiguation, and the paragraph obviousl= y failed at this, so I am OK with removing it. Thanks, Andrei -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Wednesday, April 10, 2013 1:26 PM To: Andrei Popov Cc: Nikos Mavrogiannopoulos; tls@ietf.org; sfriedl@cisco.com Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 Andrei Popov wrote: >=20 > Nikos Mavrogiannopoulos wrote: > > > > * In the same section it is mentioned: "The additional content > > associated with this extension MUST be included in the hash > > calculations associated with the "Finished" messages.". > > Why is that mentioned at all? Is there an option in TLS not > > to include that data in the TLS finished message hashes? >=20 > * The text about the hash calculations was intended to make it > absolutely clear that the content of the new extension is included > in the hash calculations, and avoid any ambiguity. The need for this > clarification arises from the fact that ALPN, unlike many other > TLS extensions, negotiates parameters that have nothing to do with > the TLS protocol itself. I absolutely agree with Nikos, that this paragraph (4th pagagraph on) http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#page-4 The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. is completely bogus and has a creates several new ambiguities where origina= lly (rfc2246) non existed. To the authors defense, a vaguely related (but different, and no less bogus) paragraph is part of rfc3646/rfc4366/rfc6066 (TLS Extensions): http://tools.ietf.org/html/rfc3546#section-3 http://tools.ietf.org/html/rfc6066#page-4 Note that any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages. =20 but that doesn't make it any less bogus nor less non-sensical this time aro= und. ;-) The governing part is the forward compatibility note at the end of rfc2246 = section 7.4.1.2, which was retroactively added to the SSLv3 spec in Novembe= r 1996: http://tools.ietf.org/html/rfc2246#page-36 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely. =20 A similar note was retroactively inserted into the SSLv3 spec somewhere aro= und Oct-Nov. 1996 _after_ SSLv3 implementations had been widely deployed: http://tools.ietf.org/html/rfc6101#page-27 Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0038.html Neither excluding the entire "extra data after the compression methods" in ClientHello, nor excluding specific subsets of such extra data would be = interoperable with mere "forward compatible" SSLv3 and TLS peers, so it is = simply **NO** option (and therefore no ambiguity). The paragraph in rfc3546/rfc4366/rfc6066 is bogus, because - none of the TLS extensions defined in these documents adds/defines any (new handshake) messages, only (optional) "extra data following compression_methods" in the existing ClientHello and ServerHello messages. - the fact that the handshake message hash covers all data in the (Extended)ClientHello and (Extended)ServerHello handshake messages is in no way limted to the specific extensions defined in rfc3546/rfc4366/rfc6066, but a strict requirement to any conceivable TLS extension, different to what Section heading "3. Secific Extensions= " and wording "any messages associated with these extensions" suggest. - the information is incorrect in that it alleges that it is involved (only) in hash calculations of the "Finished" messages. The truth is, that it is involved in all hash calculations involving "the handshake message hash", and that includes the "CertificateVerify" handshake message! The paragraph in draft-ietf-tls-applayerprotoneg-00 is not just wrong, but = also ambiguous: The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages. http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#section-3 enum { application_layer_protocol_negotiation(16), (65535) } ExtensionType; The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value. opaque ProtocolName<1..2^8-1>; struct { ProtocolName protocol_name_list<2..2^16-1> } ProtocolNameList; What would "additional content associated with this extension" mean: - ProtocolNameList ? - protocol_name_list ? - extension_data (http://tools.ietf.org/html/rfc3546#section-2.3) - Extension (http://tools.ietf.org/html/rfc3546#section-2.3) In the original SSLv3 and TLS architecture, ALL contents of ALL TLS handsha= ke messages, with the explicit exception of the "ClientHelloRequest" handsh= ake message, are included in the handshake message hash, and therefore in c= alculations that use the handshake message hash, for CertificateVerify and = Finished, and this is not (really) an option at discretion of TLS extension= s specifications. -Martin From internet-drafts@ietf.org Thu Apr 11 02:47:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3459A21F8EDF; Thu, 11 Apr 2013 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS0S2T13nKRD; Thu, 11 Apr 2013 02:47:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF0B21F884A; Thu, 11 Apr 2013 02:47:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130411094722.9852.4491.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2013 02:47:22 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 09:47:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-07.txt Pages : 9 Date : 2013-04-11 Abstract: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-exte= nsion-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yngve@spec-work.net Thu Apr 11 02:51:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADEB21F8EDF for ; Thu, 11 Apr 2013 02:51:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os9QTjy7Iu0h for ; Thu, 11 Apr 2013 02:51:39 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6C821F8ED8 for ; Thu, 11 Apr 2013 02:51:39 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:53480 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UQEAM-0002bt-42 for tls@ietf.org; Thu, 11 Apr 2013 11:51:38 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <20130411094722.9852.4491.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2013 11:51:34 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130411094722.9852.4491.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 09:51:40 -0000 Hello all, The draft have been updated based on input from IESG discusses/comments, and the Appsdir review. Changes: - abstract slightly reworded - update about benefits of stapling (reducing privacy concerns) - renamed CertificateStatusRequestList to CertificateStatusRequestListV2 to avoid confusion with RFC 6066 - clarifications regarding responderID and extensions fields in request - clarification regarding definitions from RFC 6066 and updates of definitions found in RFC 6066 - rewrote the text regarding handling of inconclusive OCSP responses - Added a note in the security considerations section about arbitrary data in requests. On Thu, 11 Apr 2013 11:47:22 +0200, wrote: > > 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 : The TLS Multiple Certificate Status Request Extension > Author(s) : Yngve N. Pettersen > Filename : draft-ietf-tls-multiple-cert-status-extension-07.txt > Pages : 9 > Date : 2013-04-11 > > Abstract: > This document defines the Transport Layer Security (TLS) Certificate > Status Version 2 Extension to allow clients to specify and support > several certificate status methods. (The use of the Certificate > Status extension is commonly referred to as "OCSP stapling".) Also > defined is a new method based on the Online Certificate Status > Protocol (OCSP) that servers can use to provide status information > not just about the server's own certificate, but also the status of > intermediate certificates in the chain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-multiple-cert-status-extension-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Thu Apr 11 03:48:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14B21F8D82 for ; Thu, 11 Apr 2013 03:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m33LwT2baytV for ; Thu, 11 Apr 2013 03:48:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2926321F8C45 for ; Thu, 11 Apr 2013 03:48:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r3BAmMx9000699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Apr 2013 12:48:22 +0200 (MEST) In-Reply-To: <20130410202610.D3EF31A6A2@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 11 Apr 2013 12:48:21 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130411104821.E6A551A6A4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 10:48:25 -0000 Ooops -- I need to correct my previous posting: Martin Rex wrote: > > The paragraph in rfc3546/rfc4366/rfc6066 is bogus, because > > - none of the TLS extensions defined in these documents adds/defines > any (new handshake) messages, only (optional) "extra data following > compression_methods" in the existing ClientHello and ServerHello > messages. rfc3546/rfc4366/rfc6066 _do_ define two new TLS handshake messages: "certificate_url(21)" and "certificate_status(22)", for use by the TLS extensions "client_certificate_url(2)" and "status_request(5)" respectively, not just "extra data following compression_methods" in the existing ClientHello and ServerHello handshake messages. I'm sorry for the confusion. -Martin From internet-drafts@ietf.org Thu Apr 11 15:16:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B684C21F898A; Thu, 11 Apr 2013 15:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6ZC2AIkNadH; Thu, 11 Apr 2013 15:16:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 214DB21F86F7; Thu, 11 Apr 2013 15:16:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130411221602.24275.31852.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2013 15:16:02 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:16:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-08.txt Pages : 10 Date : 2013-04-11 Abstract: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-exte= nsion-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yngve@spec-work.net Thu Apr 11 15:20:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2E321F8758 for ; Thu, 11 Apr 2013 15:20:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy8t-f4q4I42 for ; Thu, 11 Apr 2013 15:20:24 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3DF21F8935 for ; Thu, 11 Apr 2013 15:20:24 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:51353 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UQPqx-0005ae-7b for tls@ietf.org; Fri, 12 Apr 2013 00:20:23 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <20130411221602.24275.31852.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 00:20:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130411221602.24275.31852.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:20:25 -0000 Hello all, A minor update based on an IESG request. - Changed to referencing 2560bis as normative - 2560 is informative reference about the OCSP nonce text, 2560bis clarification reference added. On Fri, 12 Apr 2013 00:16:02 +0200, wrote: > > 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 : The TLS Multiple Certificate Status Request Extension > Author(s) : Yngve N. Pettersen > Filename : draft-ietf-tls-multiple-cert-status-extension-08.txt > Pages : 10 > Date : 2013-04-11 > > Abstract: > This document defines the Transport Layer Security (TLS) Certificate > Status Version 2 Extension to allow clients to specify and support > several certificate status methods. (The use of the Certificate > Status extension is commonly referred to as "OCSP stapling".) Also > defined is a new method based on the Online Certificate Status > Protocol (OCSP) that servers can use to provide status information > not just about the server's own certificate, but also the status of > intermediate certificates in the chain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-multiple-cert-status-extension-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From n.mavrogiannopoulos@gmail.com Sun Apr 14 02:29:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361721F8D82 for ; Sun, 14 Apr 2013 02:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWiqKCqQuDD1 for ; Sun, 14 Apr 2013 02:29:27 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 300A721F85D4 for ; Sun, 14 Apr 2013 02:29:27 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so3694144wgh.18 for ; Sun, 14 Apr 2013 02:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=HenP2ed1KLbztAwjqvTBmMWSzkN38XywWvK9cA+T4ko=; b=gBIda/iHGK9gdIG40asOD3QP477i8A/AQT73krMfmCUnzRktOt7LDqvqBB7O2aVIHD VsY40Ad5Ww/66MBAzLQedtxZ2KfLYRh8FbNVmO3QlL6BSpaEbRWMVRPMLzA8s04e1AWx G2x2/bI+O8JryzqmAX1ZvBdigEIHIi1cGxdJHQWi8zB7UWy9uj3YS/knQ2I0zkAvG8tO VfYzTePA45KzOQyNyiItqfm7dlyMdWMk4Zb1uGWH1VSHxL91jNjrtGOhdWG6H0Wu3Hfs 0K7jGPDObliwoCKvtCKH9TOdKjcAFRFkRhELeGuUbSW4F0tPxGCGPfB9CdRqHB7ALWON U53g== X-Received: by 10.194.104.137 with SMTP id ge9mr20444253wjb.52.1365931766223; Sun, 14 Apr 2013 02:29:26 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id fv2sm7948394wib.6.2013.04.14.02.29.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 02:29:25 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <516A76EE.1030501@gnutls.org> Date: Sun, 14 Apr 2013 11:29:18 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] TLS CBC ciphersuites fix X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 09:29:28 -0000 Hello, I don't know if the issues in CBC ciphersuites topic was discussed in the previous WG meeting (couldn't find the minutes), and I don't know if there is already a selected solution, but here is a summary of the 3 proposed (in the list) fixes to the CBC issue so far, as well as my thoughts on each one (note that I co-authored II). =================== I. http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01 Specifies ciphersuites using CBC to be used with the TLS 1.2 AEAD construction. It utilizes the encrypt-then-MAC construction. * Pros: 1. Provides ciphersuites that can be used to replace the existing existing CBC ciphersuites. * Cons: 1. The new ciphersuites only work in implementations supporting TLS 1.2 2. It adds 5 new ciphersuites using AEAD and various HMAC-SHA variants. Cannot be used to replace all known CBC ciphersuites. II. http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00 Modifies all ciphersuites to use a new padding mechanism that does not have the shortcomings of CBC padding. That is, padded data are part of the plaintext. * Pros: 1. Fixes the known issues in all the existing CBC ciphersuites. 2. May be used from SSL 3.0 3. May protect from key-recovery in a weak MAC construction 4. It adds the ability of variable padding to all TLS ciphersuites * Cons: 1. May not protect from a MAC that has data-dependent timing 2. Modifies all TLS ciphersuites, even those not affected by the attack. III. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-01 Negotiates an encrypt-then-MAC mode for all TLS ciphersuites. * Pros: 1. Fixes the known issues in all the existing CBC ciphersuites. 2. May be used from SSL 3.0 (though the text mentions TLS 1.0 only) 3. May protect from a MAC that has data-dependent timing * Cons: 1. Modifies all TLS ciphersuites (except the AEAD), even those not affected by the attack. 2. May not protect from key-recovery in a weak MAC construction =================== Please feel free to add an pros or cons I missed. I find solution (I) inadequate to replace the CBC ciphersuites in any practical scenarios. That is because that solution only works for TLS 1.2 implementations leaving all the older ones vulnerable. What I like most in solution (II) is the variable padding to any TLS ciphersuite which can be used as a traffic analysis countermeasure. The other thing I like is that it fixes the issue at hand by doing minimal changes by preserving the original construction used in TLS (MAC-then-encrypt). Solution (III) what I like most is that it fixes the issue at hand and potentially any other timing issues that may arise from a MAC that has data-dependencies. What I don't like is the radical change, i.e., a switch to another encryption mode which leaves the MAC unencrypted. Maybe it should be combined with a deprecation of HMAC-MD5, and possibly a truncation of the MAC to deter key recovery (remember that the TLS handshake MAC is already truncated to 96-bits exactly for that reason). Any other thoughts on those issues? Is the WG actually adopting a fix to that issue, or should implementors work it out outside the WG? regards, Nikos From paul.hoffman@vpnc.org Sun Apr 14 08:24:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B122821F90CE for ; Sun, 14 Apr 2013 08:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyCnvUEEIfcM for ; Sun, 14 Apr 2013 08:24:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CFCAA21F869C for ; Sun, 14 Apr 2013 08:24:27 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3EFOP5h077860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 14 Apr 2013 08:24:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <516A76EE.1030501@gnutls.org> Date: Sun, 14 Apr 2013 08:24:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <713CF92A-A2CA-45D1-8057-350DBB2CBB85@vpnc.org> References: <516A76EE.1030501@gnutls.org> To: "tls@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: [TLS] Informal minutes from Orlando X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 15:24:28 -0000 On Apr 14, 2013, at 2:29 AM, Nikos Mavrogiannopoulos = wrote: > I don't know if the issues in CBC ciphersuites topic was discussed in > the previous WG meeting (couldn't find the minutes) I volunteered to take minutes at the meeting, and sent them to the = chairs immediately after. They did not post them, so they are not part = of the official IETF proceedings. Below is what I sent them. --Paul Hoffman TLS WG Minutes from Paul Hoffman Stuff from slides is not reproduced here; see = https://datatracker.ietf.org/meeting/86/materials.html#tls draft-ietf-tls-cached-info, Hannes Tschofenig One open issue Instead of sending the fingerprint, server just sends empty = Certificate payload More elegant from an implementation standpoint Adam Langley: Do we hash them all, always? Doesn't want to paint ourselves in the corner Not optimizing how much you would send. Ekr: Server hello lists all of what will be omitted Joe: Could add types for omitting intermediate = certificates only Next version will be out next week Next prototocol negotiation HTTPbis WG wants this so that someone can tell which version of = HTTP is being used draft-friedl-tls-applayerprotoneg, Andrei Popov Hiding things from snooping should be generic for all = data draft-agl-tls-nextprotoneg, Adam Langley NPN is used for negotiating SPDY today IANA will certainly change extension number that was = picked (Looking at previous slides' chart): Client sends its = message "here" Wish to avoid sending anything in the cleartext Does not receive the same guarantees that TLS provides Uncomfortable grey area between "confidentail" = and "secure" ALPN reflects everything else we do in the normal TLS = handshake But that makes it less robust If the TLS WG goes with this, NPN will be dropped Also wanting put other stuff in the = protected-but-not-secure road Burning a round trip in renegotiation is not viable Martin Stiemerling: Why would someone blocking not base = on the server's list? Adam: server doesn't have to actually list = anything Client can pick whatever it wants, even = what isn't=20 Ekr, wearing chair hat: The specification must allow = negotiation Yoav Nir: We like creating frameworks for solving = problems Why should we have any negotiation of HTTP Mark Nottingham: The request from HTTPbis WG was to have = this be open-ended Roberto Peon: Negotiation is needed during protocol = development Ekr: The negotiation needs to advertise and the other side can = select Adam: Had a different design Adam: Want a common advertisment so that middleboxes = cannot use the advertisement to block Mark: The list doesn't need to be complete Hannes: Privacy concerns drive the protocol design Adam: not really a privacy concern because the the = security is complete; think robustness instead Gabriel Montenegro: Twitter today doesn't negotiate: it goes = straight to SPDY Doesn't like the encryption without the final handshake Adam: Because False Start is being used, you have nearly = the same security guarantees Martin: The problem is that we have different servers wanting to = different things Advertisements help us to determine that Mark: What is the contentious point? Ekr: We have two designs with very different properties NPN violates the TLS state machine Wants to have significant parts of the handshake covered Maybe we can do this today Cullen Jennings: Concerned how many firewalls block what they do = not understands Thus would rather expose instead of hide Not a real privacy loss Andrei: Slippery slope of partial protection from passive attack False start is predicated on a strong cipher, so not = really comparable You don't want to restrict the ciphers; Adam: wants to restrict it to strong ciphers to make = people upgrade Ted Hardie: in Tor bridge ALPN lets you do an early stop, in NPN = it terminates later Adam: Was just using Tor as an example Ekr: For Tor, now it is just a cross-protocol attack Joe Salowey: Concerned about the middle-ground Wants to protect the handshake in a more robust way Brian Dickson: What is the list of protocols? Adam: ASCII strings Brian: client may be shoehorning itself Adam: We don't care for SPDY, but that doesn't help my = case Mark: Doesn't want this to drag out HTTP1 and 2 are semantically equivalent Tokens have roughly the semantics of a TCP port For Tor, it could be hidden much lower in HTTP Personal bias was towards NPN, but is now neutral Maybe wants the server to choose Dan Harkins: Doesn't like either because it's not the job of TLS Ekr: Server picks is the way things are done in TLS Martin: How do the guarantees on NPN affect MITM attacks? Adam: Good/bad thing about NPN is that works with = proxies We are already sending data with False Start so = it is not different Ekr: The client must verify the server certificate = before emitting the NPN client message This moves the host name check up Roberto Peon: Data from doing different protocols over 80: bad; = other port, almost as bad; 443: no problem at all If we make it easy for people to see it, we'll have to = design this again later, doesn't want to that Ekr: Doesn't agree that hiding the selected protocol is = better Intermediary will break client hello based on = TLS 1.1 Andrei: Devising a protection scheme for one piece of data is = not good; be more systematic Will lead to double encryption Adam: Agrees, and thus put it in Encrypted Extension = block=20 Andrei: Maybe use Marsh Ray's proposal Cullen: APLN will get through firewalls better Straw poll: ALPN hummed slightly louder Russ Housley: Donkey between hay Counting: 25 ALPN 12 NPN Ekr: We still want to work on hiding more Sean: that will be TLS 1.3 TLS authorization using DTCP certificate draft-dthakore-tls-authz, D. Thakore Additional authentication type that is mostly for audio-visual = content Update to IPR will have licensing terms Chairs will figure out why it has not been published Adam: RFC 5878 has a lot of problems that prevented it working = for CT Errata have been submitted Currently individual submission, will figure out with Sean Will have a later glance in the WG TLS over LLCP draft-urien-tls-llcp, Pascal Urien All about NFC (near field communication) Wants to put TLS between SNEP and LLCP There is an implementation available Wants advice from WG on how to make profile Ekr: break this into two drafts: LLCP and TLS issues Hannes: LWIG has implementation guidance Lots of other LWIG drafts and COAP drafts deal with this From housley@vigilsec.com Sun Apr 14 08:44:08 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5C621F9128 for ; Sun, 14 Apr 2013 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No3Eo4sXMfdD for ; Sun, 14 Apr 2013 08:44:07 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0A81821F9122 for ; Sun, 14 Apr 2013 08:44:07 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C76ECF24070; Sun, 14 Apr 2013 11:44:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ciFY6IM22+al; Sun, 14 Apr 2013 11:43:58 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5A39E9A411A; Sun, 14 Apr 2013 11:44:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <713CF92A-A2CA-45D1-8057-350DBB2CBB85@vpnc.org> Date: Sun, 14 Apr 2013 11:44:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B64309B-1996-4E1C-ADC6-B3DE5D4416E9@vigilsec.com> References: <516A76EE.1030501@gnutls.org> <713CF92A-A2CA-45D1-8057-350DBB2CBB85@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Cc: "tls@ietf.org" Subject: Re: [TLS] Informal minutes from Orlando X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 15:44:08 -0000 http://www.ietf.org/proceedings/86/minutes/minutes-86-tls On Apr 14, 2013, at 11:24 AM, Paul Hoffman wrote: > On Apr 14, 2013, at 2:29 AM, Nikos Mavrogiannopoulos = wrote: >=20 >> I don't know if the issues in CBC ciphersuites topic was discussed in >> the previous WG meeting (couldn't find the minutes) >=20 > I volunteered to take minutes at the meeting, and sent them to the = chairs immediately after. They did not post them, so they are not part = of the official IETF proceedings. Below is what I sent them. >=20 > --Paul Hoffman >=20 > TLS WG > Minutes from Paul Hoffman > Stuff from slides is not reproduced here; see = https://datatracker.ietf.org/meeting/86/materials.html#tls >=20 > draft-ietf-tls-cached-info, Hannes Tschofenig > One open issue > Instead of sending the fingerprint, server just sends empty = Certificate payload > More elegant from an implementation standpoint > Adam Langley: Do we hash them all, always? > Doesn't want to paint ourselves in the corner > Not optimizing how much you would send. > Ekr: Server hello lists all of what will be omitted > Joe: Could add types for omitting intermediate = certificates only > Next version will be out next week >=20 > Next prototocol negotiation > HTTPbis WG wants this so that someone can tell which version of = HTTP is being used > draft-friedl-tls-applayerprotoneg, Andrei Popov > Hiding things from snooping should be generic for all = data > draft-agl-tls-nextprotoneg, Adam Langley > NPN is used for negotiating SPDY today > IANA will certainly change extension number that was = picked > (Looking at previous slides' chart): Client sends its = message "here" > Wish to avoid sending anything in the cleartext > Does not receive the same guarantees that TLS provides > Uncomfortable grey area between "confidentail" = and "secure" > ALPN reflects everything else we do in the normal TLS = handshake > But that makes it less robust > If the TLS WG goes with this, NPN will be dropped > Also wanting put other stuff in the = protected-but-not-secure road > Burning a round trip in renegotiation is not viable > Martin Stiemerling: Why would someone blocking not base = on the server's list? > Adam: server doesn't have to actually list = anything > Client can pick whatever it wants, even = what isn't=20 > Ekr, wearing chair hat: The specification must allow = negotiation > Yoav Nir: We like creating frameworks for solving = problems > Why should we have any negotiation of HTTP > Mark Nottingham: The request from HTTPbis WG was to have = this be open-ended > Roberto Peon: Negotiation is needed during protocol = development > Ekr: The negotiation needs to advertise and the other side can = select > Adam: Had a different design > Adam: Want a common advertisment so that middleboxes = cannot use the advertisement to block > Mark: The list doesn't need to be complete > Hannes: Privacy concerns drive the protocol design > Adam: not really a privacy concern because the the = security is complete; think robustness instead > Gabriel Montenegro: Twitter today doesn't negotiate: it goes = straight to SPDY > Doesn't like the encryption without the final handshake > Adam: Because False Start is being used, you have nearly = the same security guarantees > Martin: The problem is that we have different servers wanting to = different things > Advertisements help us to determine that > Mark: What is the contentious point? > Ekr: We have two designs with very different properties > NPN violates the TLS state machine > Wants to have significant parts of the handshake covered > Maybe we can do this today > Cullen Jennings: Concerned how many firewalls block what they do = not understands > Thus would rather expose instead of hide > Not a real privacy loss > Andrei: Slippery slope of partial protection from passive attack > False start is predicated on a strong cipher, so not = really comparable > You don't want to restrict the ciphers; > Adam: wants to restrict it to strong ciphers to make = people upgrade > Ted Hardie: in Tor bridge ALPN lets you do an early stop, in NPN = it terminates later > Adam: Was just using Tor as an example > Ekr: For Tor, now it is just a cross-protocol attack > Joe Salowey: Concerned about the middle-ground > Wants to protect the handshake in a more robust way > Brian Dickson: What is the list of protocols? > Adam: ASCII strings > Brian: client may be shoehorning itself > Adam: We don't care for SPDY, but that doesn't help my = case > Mark: Doesn't want this to drag out > HTTP1 and 2 are semantically equivalent > Tokens have roughly the semantics of a TCP port > For Tor, it could be hidden much lower in HTTP > Personal bias was towards NPN, but is now neutral > Maybe wants the server to choose > Dan Harkins: Doesn't like either because it's not the job of TLS > Ekr: Server picks is the way things are done in TLS > Martin: How do the guarantees on NPN affect MITM attacks? > Adam: Good/bad thing about NPN is that works with = proxies > We are already sending data with False Start so = it is not different > Ekr: The client must verify the server certificate = before emitting the NPN client message > This moves the host name check up > Roberto Peon: Data from doing different protocols over 80: bad; = other port, almost as bad; 443: no problem at all > If we make it easy for people to see it, we'll have to = design this again later, doesn't want to that > Ekr: Doesn't agree that hiding the selected protocol is = better > Intermediary will break client hello based on = TLS 1.1 > Andrei: Devising a protection scheme for one piece of data is = not good; be more systematic > Will lead to double encryption > Adam: Agrees, and thus put it in Encrypted Extension = block=20 > Andrei: Maybe use Marsh Ray's proposal > Cullen: APLN will get through firewalls better > Straw poll: ALPN hummed slightly louder > Russ Housley: Donkey between hay > Counting: 25 ALPN 12 NPN > Ekr: We still want to work on hiding more > Sean: that will be TLS 1.3 >=20 > TLS authorization using DTCP certificate > draft-dthakore-tls-authz, D. Thakore > Additional authentication type that is mostly for audio-visual = content > Update to IPR will have licensing terms > Chairs will figure out why it has not been published > Adam: RFC 5878 has a lot of problems that prevented it working = for CT > Errata have been submitted > Currently individual submission, will figure out with Sean > Will have a later glance in the WG >=20 > TLS over LLCP > draft-urien-tls-llcp, Pascal Urien > All about NFC (near field communication) > Wants to put TLS between SNEP and LLCP > There is an implementation available > Wants advice from WG on how to make profile > Ekr: break this into two drafts: LLCP and TLS issues > Hannes: LWIG has implementation guidance > Lots of other LWIG drafts and COAP drafts deal with this >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From paul.hoffman@vpnc.org Sun Apr 14 08:54:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1C21F8554 for ; Sun, 14 Apr 2013 08:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNUWG1mYKr9a for ; Sun, 14 Apr 2013 08:54:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A65A921F8523 for ; Sun, 14 Apr 2013 08:54:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3EFsHnI078504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Apr 2013 08:54:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <6B64309B-1996-4E1C-ADC6-B3DE5D4416E9@vigilsec.com> Date: Sun, 14 Apr 2013 08:54:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80992DA6-04DC-48CE-9879-54228E045E36@vpnc.org> References: <516A76EE.1030501@gnutls.org> <713CF92A-A2CA-45D1-8057-350DBB2CBB85@vpnc.org> <6B64309B-1996-4E1C-ADC6-B3DE5D4416E9@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1503) Cc: "tls@ietf.org" Subject: Re: [TLS] Informal minutes from Orlando X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 15:54:19 -0000 On Apr 14, 2013, at 8:44 AM, Russ Housley wrote: > http://www.ietf.org/proceedings/86/minutes/minutes-86-tls Ah, excellent. I assumed they hadn't because they hadn't had the WG = review them first. Fortunately, we have time to fix the line-wrapping problem before the = final proceedings. :-) --Paul Hoffman= From iesg-secretary@ietf.org Mon Apr 15 11:24:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590C221F968D; Mon, 15 Apr 2013 11:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOtQJL3COvpx; Mon, 15 Apr 2013 11:24:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BD621F9694; Mon, 15 Apr 2013 11:24:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130415182446.18545.97271.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 11:24:46 -0700 Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'The TLS Multiple Certificate Status Request Extension' to Proposed Standard (draft-ietf-tls-multiple-cert-status-extension-08.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:24:48 -0000 The IESG has approved the following document: - 'The TLS Multiple Certificate Status Request Extension' (draft-ietf-tls-multiple-cert-status-extension-08.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ Technical Summary This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. Working Group Summary In general working group consensus was smooth. There were no major sticking points. Document Quality There are a number of implementers who plan to implement this protocol extension. Personnel Shepherd - Joe Salowey; AD - Sean Turner. From iesg-secretary@ietf.org Mon Apr 15 11:24:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE45821F9691 for ; Mon, 15 Apr 2013 11:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYB-1ngBscp0; Mon, 15 Apr 2013 11:24:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E06C21F968E; Mon, 15 Apr 2013 11:24:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-tls-multiple-cert-status-extension X-IETF-Draft-revision: 08 Message-ID: <20130415182447.18545.82408.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 11:24:47 -0700 Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'The TLS Multiple Certificate Status Request Extension' to Proposed Standard (draft-ietf-tls-multiple-cert-status-extension-08.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:24:48 -0000 The IESG has approved the following document: - 'The TLS Multiple Certificate Status Request Extension' (draft-ietf-tls-multiple-cert-status-extension-08.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ Technical Summary This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. Working Group Summary In general working group consensus was smooth. There were no major sticking points. Document Quality There are a number of implementers who plan to implement this protocol extension. Personnel Shepherd - Joe Salowey; AD - Sean Turner. From turners@ieca.com Tue Apr 16 07:06:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F31921F971A for ; Tue, 16 Apr 2013 07:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.764 X-Spam-Level: X-Spam-Status: No, score=-101.764 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwAC2bdf5LsD for ; Tue, 16 Apr 2013 07:06:23 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.106.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8127D21F96FE for ; Tue, 16 Apr 2013 07:06:23 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 38A879A5FF73C; Tue, 16 Apr 2013 09:06:23 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 289AB9A5FF6FF for ; Tue, 16 Apr 2013 09:06:23 -0500 (CDT) Received: from [108.45.16.214] (port=54590 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1US6Wc-0007by-QG; Tue, 16 Apr 2013 09:06:22 -0500 Message-ID: <516D5ADE.3050506@ieca.com> Date: Tue, 16 Apr 2013 10:06:22 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: tls@ietf.org, draft-ietf-tls-oob-pubkey@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:54590 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:06:24 -0000 I'd like to discuss some of these before issuing an IETF LC. There's no implied importance based on the order. 0) abstract: I'd delete the 2nd paragraph it really sounds like marketing. The third paragraph is also a repeat of what's in the 1st paragraph - I'd just delete it. Finally, need to be clear that you're also defining two new TLS extensions: This document specifies a new certificate type and two TLS extensions, one for the client and one for the server, for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. 1) s1 does a good job of motivating the need for server side keys but falls a little short on client keys. Why does the intro to the bullet list mention how the client can get the server's certificate with the last bullet also talking about the client's key? Also, is the paragraph after the bullets just an explicit example of the last bullet? Seems like the first sentence should be: Traditionally, TLS client and server public keys ... and then maybe: Alternative methods are available that allow a TLS clients/servers to obtain the TLS servers/client public key: o TLS clients can obtain the TLS server public key from a DNSSEC secured resource records using DANE [RFC6698]. o The TLS client or server public key is obtained from a [PKIX] certificate chain from an Lightweight Directory Access Protocol (LDAP) [LDAP] server or web page. o The TLS client and server public key is provisioned into the operating system firmware image, and updated via software updates. For example: * Some smart objects use the UDP-based Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] to interact with a Web server to upload sensor data at a regular intervals, such as temperature readings. CoAP [I-D.ietf-core-coap] can utilize DTLS for securing the client-to-server communication. As part of the manufacturing process, the embeded device may be configured with the address and the public key of a dedicated CoAP server, as well as a public key for the client itself. 2) s1: The last paragraph needs to indicate that this document defines two new certificate extensions: This document registers a new value to the IANA certificate types registry for the support of raw public keys. It also defines two new TLS extensions, "client_certificate_type" and "server_certificate_type". 3) I think the introduction needs to make it very clear that without the out-of-band binding between the public key and the entity that no authentication is actually being performed. Add something like the following to the end of s1: The mechanism defined herein only provides authentication when an out-of-band mechanism is also used to bind the public key to the entity presenting the key. 4) s3: r/raw public key certificates/raw public keys 5) wrt Figure 3 maybe we can just list the ones we know about? And, RFC 5480 updated 3279 wrt ECDSA public keys so it needs to point there: [RFC3279] and [RFC5480] define the following OIDs: Key Type | Document | OID ---------------------+----------------------------+------------------- RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 .....................|............................|................... Digital Signature | | Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 .....................|............................|................... Elliptic Curve | | Digital Signature | | Algorithm (ECDSA) | Section 2.1.1 of RFC 5480 | 1.2.840.10045.2.1 ---------------------+----------------------------+------------------- Figure 3: Example Algorithm Identifiers. and add 5480 as reference. Grumble: would have listed RSASSA-PSS but it's not supported. 6) And on those references, I think the references for 3279 and 5480 end up normative. All are standards track so no downref issues. 7) s3: I think it's not just an algorithm it sometimes includes additional parameters. Also need to include the AlgorithmIdentifier syntax. I think that means some slight tweaking: The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 5280 [PKIX] and does not only contain the raw keys, such as the public exponent and the modulus of an RSA public key, but also an algorithm identifier. The algorithm identifier can also include parameters. The structure, as shown in Figure 2, is encoded in an ASN.1 format and therefore contains length information as well. An example is provided in Appendix A. SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Figure 2: SubjectPublicKeyInfo ASN.1 Structure. ref: [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. 8) I'm thinking we need to say DER encoded in the above as well: an DER encoded ASN.1 [X.690] format here's the reference: [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 9) s4.1: Are some words missing from the following: In order to indicate the support of out-of-band raw public keys, clients MUST include the 'client_certificate_type' and 'server_certificate_type' extensions extended client hello message. extensions "in an" extended client hello message? 10) s4.2: Maybe reword this slightly: OLD: If the client indicated the support of raw public keys in the 'client_certificate_type' extension in the client hello and the server is able to provide such raw public key then the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload. NEW: If the client hello indicates support of raw public keys in the 'client_certificate_type' extension and the server also supports raw public keys then the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload. But, a more important question is the meaning of that paragraph above. Doesn't that override the "sorted by client preference" from s3? 11) s6: Got some questions about the following: This information will be needed to make authorization decisions. Without a secure binding, man-in-the-middle attacks may be the consequence. 1st isn't that authentication. 2nd isn't it masquerade attacks? 3rd it's not really a may it's more an is likely to be? 12) In s6, it indicates: This document assumes that such binding can be made out-of-band and we list a few examples in Section 1. This statement begs the question as to whether there needs to be a requirement on protocols that use this extension to specify the method used to provide the out-of-band binding. In other words something like: Specifications that make use of the extension MUST specify the mechanism by which the identity and the public key are bound. Otherwise, authentication is not possible. 13) How are we supposed to check whether key is still considered "good"? If you can't that might be okay, but you need to mention that there's no mechanism to support this yet or that that also needs to be done out-of-band. 14) Are there any other extensions that don't make sense to negotiate if raw keys are chosen? For example, if the the client and server settle on raw keys do either of the ocsp stapling extensions make sense anymore? 15) In s7, ask IANA to point the Certificate's Type Registry to this draft. spt From turners@ieca.com Tue Apr 16 07:09:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4106821F9356 for ; Tue, 16 Apr 2013 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iZBnk+ux7am for ; Tue, 16 Apr 2013 07:09:52 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.144.3]) by ietfa.amsl.com (Postfix) with ESMTP id 86BB921F9354 for ; Tue, 16 Apr 2013 07:09:52 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id AD0D7CC7270E2; Tue, 16 Apr 2013 09:09:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 8756BCC727024 for ; Tue, 16 Apr 2013 09:09:48 -0500 (CDT) Received: from [108.45.16.214] (port=54619 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1US6Zz-0000oj-PU; Tue, 16 Apr 2013 09:09:51 -0500 Message-ID: <516D5BAF.30304@ieca.com> Date: Tue, 16 Apr 2013 10:09:51 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: <20130411221602.24275.31852.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:54619 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:09:53 -0000 Yngve, Thanks for all the quick turn arounds. It definitely helps the process when the authors are as responsive as you are. spt On 4/11/13 6:20 PM, Yngve N. Pettersen wrote: > Hello all, > > A minor update based on an IESG request. > > - Changed to referencing 2560bis as normative > - 2560 is informative reference about the OCSP nonce text, 2560bis > clarification reference added. > > > On Fri, 12 Apr 2013 00:16:02 +0200, wrote: > >> >> 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 : The TLS Multiple Certificate Status Request >> Extension >> Author(s) : Yngve N. Pettersen >> Filename : >> draft-ietf-tls-multiple-cert-status-extension-08.txt >> Pages : 10 >> Date : 2013-04-11 >> >> Abstract: >> This document defines the Transport Layer Security (TLS) Certificate >> Status Version 2 Extension to allow clients to specify and support >> several certificate status methods. (The use of the Certificate >> Status extension is commonly referred to as "OCSP stapling".) Also >> defined is a new method based on the Online Certificate Status >> Protocol (OCSP) that servers can use to provide status information >> not just about the server's own certificate, but also the status of >> intermediate certificates in the chain. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-08 >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-multiple-cert-status-extension-08 >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From Bert.Greevenbosch@huawei.com Sun Apr 21 18:23:40 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6F21F875C for ; Sun, 21 Apr 2013 18:23:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riVbuNqDgztE for ; Sun, 21 Apr 2013 18:23:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31BDD21F87B7 for ; Sun, 21 Apr 2013 18:23:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASB10658; Mon, 22 Apr 2013 01:23:33 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Apr 2013 02:23:09 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Apr 2013 02:23:31 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Mon, 22 Apr 2013 09:23:25 +0800 From: Bert Greevenbosch To: Sean Turner , "tls@ietf.org" , "draft-ietf-tls-oob-pubkey@tools.ietf.org" Thread-Topic: [TLS] AD review of draft-ietf-tls-oob-pubkey Thread-Index: AQHOOqugRs5hBntoEky0lAT8pzuh/ZjhbddA Date: Mon, 22 Apr 2013 01:23:25 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> References: <516D5ADE.3050506@ieca.com> In-Reply-To: <516D5ADE.3050506@ieca.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 01:23:40 -0000 Hi Sean, all, 13) How are we supposed to check whether key is still considered "good"?=20 If you can't that might be okay, but you need to mention that there's=20 no mechanism to support this yet or that that also needs to be done=20 out-of-band. That indeed is a problem. I have made a first attempt at solving this throu= gh the following draft: http://datatracker.ietf.org/doc/draft-greevenbosch-tls-ocsp-lite/ The draft should not be confused with the Lightweight OCSP Profile from RFC= 5019. I guess a new name is needed. Also the draft is quite simple, it just asks a server about the revocation = status of the public key. The current solution has scalability issues, so i= t would certainly need some work to get that right. The raw public key was designed to remove the processing burden of a full X= .509 certificate, making it easy to use in constrained environments. (CoAP = refers to it.) I think revocation status checking should be similarly simpl= e for the receiving entity. Best regards, Bert From rsalz@akamai.com Mon Apr 22 08:15:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4B621E8053 for ; Mon, 22 Apr 2013 08:15:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ltiuvO47EbW for ; Mon, 22 Apr 2013 08:15:07 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5419121E8045 for ; Mon, 22 Apr 2013 08:15:07 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A1019CFCC5; Mon, 22 Apr 2013 15:15:06 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 8DAAFCFC8F; Mon, 22 Apr 2013 15:15:06 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub7.dfw01.corp.akamai.com [172.27.25.73]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 72BE1205D; Mon, 22 Apr 2013 15:15:06 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.178]) by ustx2ex-cashub7.dfw01.corp.akamai.com ([172.27.25.73]) with mapi; Mon, 22 Apr 2013 10:15:05 -0500 From: "Salz, Rich" To: Bert Greevenbosch , Sean Turner , "tls@ietf.org" , "draft-ietf-tls-oob-pubkey@tools.ietf.org" Date: Mon, 22 Apr 2013 10:15:05 -0500 Thread-Topic: [TLS] AD review of draft-ietf-tls-oob-pubkey Thread-Index: AQHOOqugRs5hBntoEky0lAT8pzuh/ZjhbddAgAD0/5A= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> References: <516D5ADE.3050506@ieca.com> <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:15:08 -0000 Yes, O*CS*P light is a bad name. :) Have you looked at what SSH is doing for key management issues? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From Bert.Greevenbosch@huawei.com Tue Apr 23 01:23:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7DB21F95F3 for ; Tue, 23 Apr 2013 01:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdIHVG7cG7N2 for ; Tue, 23 Apr 2013 01:23:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DC08921F95F0 for ; Tue, 23 Apr 2013 01:23:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASC32271; Tue, 23 Apr 2013 08:23:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 09:22:42 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 09:23:09 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.007; Tue, 23 Apr 2013 16:23:03 +0800 From: Bert Greevenbosch To: "Salz, Rich" , Sean Turner , "tls@ietf.org" Thread-Topic: Revocation and authentication of raw public key (was: [TLS] AD review of draft-ietf-tls-oob-pubkey) Thread-Index: AQHOP/vF40lchfqJYku3e/BludfGHw== Date: Tue, 23 Apr 2013 08:23:02 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> References: <516D5ADE.3050506@ieca.com> <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 08:23:19 -0000 SGVsbG8gUmljaCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrLiBQbGVhc2UgZmluZCBt eSByZXNwb25zZSBiZWxvdy4NCg0KPiBZZXMsIE8qQ1MqUCBsaWdodCBpcyBhIGJhZCBuYW1lLiA6 KQ0KDQpSaWdodCwgdGhhdCBzaG91bGQgYmUgY2hhbmdlZC4NCg0KPiBIYXZlIHlvdSBsb29rZWQg YXQgd2hhdCBTU0ggaXMgZG9pbmcgZm9yIGtleSBtYW5hZ2VtZW50IGlzc3Vlcz8NCg0KVGhhbmtz IGZvciB5b3VyIGhpbnQuIEluZGVlZCBTU0ggc3BlY2lmaWVzIHNvbWV0aGluZyBxdWl0ZSBzaW1p bGFyIHRvIGEgcmF3IHB1YmxpYyBrZXkgaW4gUkZDIDQ3MTYuDQoNCkkgdW5kZXJzdGFuZCB0aGF0 IFNTSCByZWxpZXMgb24gdGhlIGZvbGxvd2luZyBtZXRob2RzIGZvciBhdXRoZW50aWNhdGlvbjoN Cg0KKDEpIFByZS1zaGFyZWQga25vd2xlZGdlIG9mIHB1YmxpYyBrZXkuIEZvciBleGFtcGxlLCBh ZnRlciBmaXJzdCByZWdpc3RyYXRpb24gdGhlIGNsaWVudCBrbm93cyB0aGUgc2VydmVyIHB1Ymxp YyBrZXksIHNvIGlmIHRoZSBwdWJsaWMga2V5IGNoYW5nZXMgaW4gYSBsYXRlciBzZXNzaW9uIGl0 IGlzIHN1c3BlY3QuDQooMikgTWFudWFsIHZlcmlmaWNhdGlvbiBvZiB0aGUgaGFzaCBvZiB0aGUg cHVibGljIGtleSwgd2hpY2ggaXMgZGVsaXZlcmVkIHRocm91Z2ggYSBzZXBhcmF0ZSBjaGFubmVs Lg0KKDMpIFBhc3N3b3JkIHZlcmlmaWNhdGlvbiAtPiBhZnRlciBzZXNzaW9uIHNldHVwIHRoZSBj bGllbnQgc2VuZHMgYSBwYXNzd29yZCB0byBlbnN1cmUgdGhlIHNlcnZlciBpdCBpcyBsZWdpdGlt YXRlLg0KDQpUaGUgU1NIIHNwZWNpZmljYXRpb25zIChlLmcuIFJGQyA0MjUxKSBleHBsaWNpdGx5 IHBvaW50IG91dCB0aGF0IGZvciB0aGUgc2FrZSBvZiBlYXN5IGRlcGxveW1lbnQsIGF1dGhlbnRp Y2F0aW9uIG9mIG5hbWUtdG8ta2V5IGFzc29jaWF0aW9uIG1heSBiZSBvbWl0dGVkLCBhY2NlcHRp bmcgdGhlIHJpc2sgb2YgYSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2suDQoNClJGQyA0MjUxIGFs c28gbWVudGlvbnMgdGhlIHBvc3NpYmlsaXR5IHRvIHVzZSBhIHRydXN0ZWQgY2VydGlmaWNhdGUg YXV0aG9yaXR5IChDQSkgZm9yIHRoZSBuYW1lLXRvLWtleSBhc3NvY2lhdGlvbi4gSXQgbm90ZXMg dGhhdCB0aGlzIGNhbiBiZSBkb25lIHRocm91Z2ggS2VyYmVyb3Mgb3IgYSBzZWN1cmUgRE5TIGxv b2t1cC4NCg0KSSB0aGluayBuYW1lLXRvLWtleSBhc3NvY2lhdGlvbiBpcyBoYWxmIG9mIHRoZSBw cm9ibGVtLCB3aGVyZWFzIHJldm9jYXRpb24gaXMgdGhlIHNlY29uZCBoYWxmLiBTU0ggc2VlbXMg dG8gZm9jdXMgb24gdGhlIGZpcnN0IGhhbGYsIHdoZXJlYXMgT0NTUC1saXRlIGZvY3VzZXMgbWFp bmx5IG9uIHRoZSBzZWNvbmQgaGFsZi4NCg0KSG93IGRvIHlvdSBlbnZpc2lvbiB1c2luZyBTU0gg Zm9yIHJhdyBwdWJsaWMga2V5cz8NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQpCZXJ0DQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNhbHosIFJpY2ggW21haWx0bzpy c2FsekBha2FtYWkuY29tXSANClNlbnQ6IDIwMTPE6jTUwjIyyNUgMjM6MTUNClRvOiBCZXJ0IEdy ZWV2ZW5ib3NjaDsgU2VhbiBUdXJuZXI7IHRsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi10bHMtb29i LXB1YmtleUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFtUTFNdIEFEIHJldmlldyBvZiBk cmFmdC1pZXRmLXRscy1vb2ItcHVia2V5DQoNClllcywgTypDUypQIGxpZ2h0IGlzIGEgYmFkIG5h bWUuIDopDQoNCkhhdmUgeW91IGxvb2tlZCBhdCB3aGF0IFNTSCBpcyBkb2luZyBmb3Iga2V5IG1h bmFnZW1lbnQgaXNzdWVzPw0KDQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdp bmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg== From paul@nohats.ca Tue Apr 23 06:28:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9836721F96BA for ; Tue, 23 Apr 2013 06:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ussqbsEC0H4t for ; Tue, 23 Apr 2013 06:28:05 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7A21F84A1 for ; Tue, 23 Apr 2013 06:28:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zw57g2tN0z9ZN; Tue, 23 Apr 2013 09:27:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XV-FAQTXdJYV; Tue, 23 Apr 2013 09:27:58 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 23 Apr 2013 09:27:58 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7C61680EC7; Tue, 23 Apr 2013 09:27:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6F29D80E19; Tue, 23 Apr 2013 09:27:59 -0400 (EDT) Date: Tue, 23 Apr 2013 09:27:59 -0400 (EDT) From: Paul Wouters To: Bert Greevenbosch In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> Message-ID: References: <516D5ADE.3050506@ieca.com> <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tls@ietf.org" Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 13:28:05 -0000 On Tue, 23 Apr 2013, Bert Greevenbosch wrote: > I think name-to-key association is half of the problem, whereas revocation is the second half. SSH seems to focus on the first half, whereas OCSP-lite focuses mainly on the second half. Revocation is only required in the indirect path. That is, supplier A signs something for consumer B, and enduser C needs to verify B. Now A needs a method to tell C about revocation of B. When you use raw public keys, the authentication happens out of band. If there are no three players, with two of them talking only indirectly, no OCSP-like mechanism is required. For instance, using DNS(SEC) with raw keys there is only B and C. When B loses trust in their key, they simple remove it from DNS(SEC) to communicate this to A. The same applies to SSHFP records in DNS(SEC) or ActiveDirectory. OCSP was only needed before because there were three parties. While it is still possible an out of band method to validate TLS keys to require three parties, any revocation list mechanism should be part of the out of band method specification. I am not sure what out of band method this OCSP-lite case covers. If there is a specification of that out of band method, then that specification should perhaps include this OCSP-lite specification as part of it. I don't see a value of specifying a generic revocation method. I see danger in such a specification if it _introduces_ a third player where there should not be one for a specific out of band authentication method. Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can tune the behaviour of when TLS raw keys are valid or not. No OCSP variant is neccessary. The same is true for content based on ActiveDirectory/LDAP or Radius/Diameter where there is already a central control mechanism for relaying this information. Paul From rsalz@akamai.com Tue Apr 23 09:05:51 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3862321F94D9 for ; Tue, 23 Apr 2013 09:05:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhWRxhtTc3iJ for ; Tue, 23 Apr 2013 09:05:50 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBF21F93FC for ; Tue, 23 Apr 2013 09:05:50 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BC3E9D0478; Tue, 23 Apr 2013 16:05:49 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id A7DB4D0407; Tue, 23 Apr 2013 16:05:49 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 85F60202F; Tue, 23 Apr 2013 16:05:49 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.178]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Tue, 23 Apr 2013 10:05:49 -0600 From: "Salz, Rich" To: Bert Greevenbosch , Sean Turner , "tls@ietf.org" Date: Tue, 23 Apr 2013 10:05:48 -0600 Thread-Topic: Revocation and authentication of raw public key (was: [TLS] AD review of draft-ietf-tls-oob-pubkey) Thread-Index: AQHOP/vF40lchfqJYku3e/BludfGH5jj+I0A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7B3114A16@USMBX1.msg.corp.akamai.com> References: <516D5ADE.3050506@ieca.com> <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:05:51 -0000 I thought Peter Gutman had an I-D on SSH key management, but I can't find i= t now (it could have been years since I looked). -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From turners@ieca.com Tue Apr 23 10:16:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11F721F95FA for ; Tue, 23 Apr 2013 10:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0CaIVXSH1dS for ; Tue, 23 Apr 2013 10:16:41 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.59.10]) by ietfa.amsl.com (Postfix) with ESMTP id C0AF321F96D3 for ; Tue, 23 Apr 2013 10:16:40 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 68D5CFBFFA32C; Tue, 23 Apr 2013 12:16:31 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id E5D78FBFFA0D3 for ; Tue, 23 Apr 2013 12:16:30 -0500 (CDT) Received: from [108.18.169.23] (port=55254 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UUgpb-0007Ur-Mt for tls@ietf.org; Tue, 23 Apr 2013 12:16:39 -0500 Message-ID: <5176C1F6.4040806@ieca.com> Date: Tue, 23 Apr 2013 13:16:38 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.169.23]:55254 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:16:42 -0000 Hi, I've been asked to shepherd this document. It's a normative reference for the core COAP WG specification. My question is whether this draft should include an MTI curve or whether that should be left up to the application. I ask because no other EC TLS cipher suite picks a curve. spt From paul.hoffman@vpnc.org Tue Apr 23 10:53:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D821F95EB for ; Tue, 23 Apr 2013 10:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbTtfx7gfk+N for ; Tue, 23 Apr 2013 10:53:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 872B921F934C for ; Tue, 23 Apr 2013 10:53:36 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3NHrXnS022466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Apr 2013 10:53:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <5176C1F6.4040806@ieca.com> Date: Tue, 23 Apr 2013 10:53:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5176C1F6.4040806@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1503) Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:53:38 -0000 On Apr 23, 2013, at 10:16 AM, Sean Turner wrote: > My question is whether this draft should include an MTI curve or = whether that should be left up to the application. I ask because no = other EC TLS cipher suite picks a curve. The current draft (draft-mcgrew-tls-aes-ccm-ecc-06) does include a = mandatory-to-implement curve for interoperability, but allows other = curves as well. That seems useful for interoperability; otherwise, the = application that is specifying the ciphersuites must specify their own = mandatory-to-implement curve. The current draft allows them to just = point at the spec without having to add more text in order to get = interoperability. Either way leads to the same result, but putting a conservative = mandatory-to-implement curve in the ciphersuite document makes things a = bit easier for people writing profiles. --Paul Hoffman= From mcgrew@cisco.com Tue Apr 23 10:58:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B74621F9629 for ; Tue, 23 Apr 2013 10:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n36ODpVjxnF for ; Tue, 23 Apr 2013 10:58:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFCB21F9627 for ; Tue, 23 Apr 2013 10:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1293; q=dns/txt; s=iport; t=1366739924; x=1367949524; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=q3gvnB5rZqO+UqxVJbSXwlTyg8a/045HURQ70DQcyLw=; b=gfH4ndzb2o1xRtJyXHCwOl/DmaP1Qfbf1rIqzLgvTXrBy7IwaHQeQ0DV +lmFU7jGpstg9doWVvhiYtNxrJrbo9pB361gcu0Qe/p/fhD0s6MYe9X0i s7XWqSYhyJChzpttHz23lI0VEZyLG6tgTl75UboaBxYa6m/Fiz1fWe0HL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANzKdlGtJXG+/2dsb2JhbABRgwY2wSCBBBZ0gh8BAQEEAQEBNzQLEgEIGAoUNwslAgQOBQiIDAyuH48jBI53MQeCaGEDk0uUbIMOgig X-IronPort-AV: E=Sophos;i="4.87,536,1363132800"; d="scan'208";a="202115158" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 23 Apr 2013 17:58:43 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3NHwhQb011083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Apr 2013 17:58:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 12:58:43 -0500 From: "David McGrew (mcgrew)" To: Sean Turner Thread-Topic: [TLS] draft-mcgrew-tls-aes-ccm-ecc Thread-Index: AQHOQEZjmsBy24P+u0iYIIFwCOUHbpjkajcA//++XgA= Date: Tue, 23 Apr 2013 17:58:43 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B1841378A@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D8F657AFE62664D846C64D400D16008@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" , Paul Hoffman Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:58:45 -0000 Hi Sean, On 4/23/13 1:53 PM, "Paul Hoffman" wrote: >On Apr 23, 2013, at 10:16 AM, Sean Turner wrote: > >> My question is whether this draft should include an MTI curve or >>whether that should be left up to the application. I ask because no >>other EC TLS cipher suite picks a curve. > >The current draft (draft-mcgrew-tls-aes-ccm-ecc-06) does include a >mandatory-to-implement curve for interoperability, but allows other >curves as well. That seems useful for interoperability; otherwise, the >application that is specifying the ciphersuites must specify their own >mandatory-to-implement curve. The current draft allows them to just point >at the spec without having to add more text in order to get >interoperability. > >Either way leads to the same result, but putting a conservative >mandatory-to-implement curve in the ciphersuite document makes things a >bit easier for people writing profiles. I agree with Paul's points. ECC has a lot of options, and having a MTI subset promotes interoperability. David, speaking as an WG participant and not the doc author > >--Paul Hoffman >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From housley@vigilsec.com Tue Apr 23 14:05:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BF021F93C7 for ; Tue, 23 Apr 2013 14:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAvjmtgNAw7g for ; Tue, 23 Apr 2013 14:05:10 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB4121F93C4 for ; Tue, 23 Apr 2013 14:05:10 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D0F7CF24070; Tue, 23 Apr 2013 17:05:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id L8o8S8GC03aQ; Tue, 23 Apr 2013 17:04:50 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0274DF2406E; Tue, 23 Apr 2013 17:05:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <5176C1F6.4040806@ieca.com> Date: Tue, 23 Apr 2013 17:05:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E93BE0F-C4AD-4C81-B92B-04916D3CD289@vigilsec.com> References: <5176C1F6.4040806@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1085) Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:05:10 -0000 Sean: I do not think this out to include the MTI curve. I would greatly = prefer that COAP make use of one of the curves that is already = specified. I think a strong reason is needed to specify more curves; = the specification of too many will reduce interoperability. Russ On Apr 23, 2013, at 1:16 PM, Sean Turner wrote: > Hi, >=20 > I've been asked to shepherd this document. It's a normative reference = for the core COAP WG specification. >=20 > My question is whether this draft should include an MTI curve or = whether that should be left up to the application. I ask because no = other EC TLS cipher suite picks a curve. >=20 > spt From wtc@google.com Tue Apr 23 14:32:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D0E21F940E for ; Tue, 23 Apr 2013 14:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssa+81cNY2z1 for ; Tue, 23 Apr 2013 14:32:36 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBEA21F93FF for ; Tue, 23 Apr 2013 14:32:36 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id bn7so1276454ieb.41 for ; Tue, 23 Apr 2013 14:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NQFebEAq9OLQMcaPtRmONM2uy1brkPQJNT4O+P7raQA=; b=lTOQ8kB/4AbdKgM5QdwKs5gc1FxTP9PaUO0u96L+KUvRZHslcML+ebF3p7s08yxxkO sO3JNysdaZd4YqupiShEQQ89XQVFrjuhfJWCZB4x2cFl3LaNrOFAHAHXLviJdXLWgLNl 7rO6tca6UM/We776EBIhe4GLop9iRPNAW2BchQ3TI2m+r/eyXxZGmK6/6YphcN3dfndO ocELapbd08vcrBCkuFX7thdhtZMfYyJsetX7eovUqHKoSUcLf80qdLPTAyiVyJaeTCMQ C3KkTrYV+9aEiiwfL/kVMrmsAe6J8tneg8MBTqRRxOWziftUZFLxlVwT4k05PoEbrOMf fEVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=NQFebEAq9OLQMcaPtRmONM2uy1brkPQJNT4O+P7raQA=; b=Z22qH496rIPjFPhxXdqFsFq35nyFS+t7pRN/utO7HvCNui9A1H+3oweM/7YIdD2vsT Vl40M5C9627PovrvqbbSdz2rqmNLiH3L0qYwYQVKGkLiw3KjkmRTUGi2/jqnH4q8HP7V fOBp3eU1/b/l3uAkj4JcLaNRzMuqteGF6dLif2n9tttqBjAfnRywjuV4ERvplCVoDZfX Gff2y69OeRHZ4N1i+rnoD3m6l85nQTiWMjhsf1H7wufc0kN4tDA730CwJ5DG7lgGilAt 1oFp9lzzANCTnut3rHdwVAB4HD8tt1S2CMRo8xeLLPt0Z32aZuWoTV9cjdvfsRtZ5/EN Wghw== MIME-Version: 1.0 X-Received: by 10.50.66.162 with SMTP id g2mr6897283igt.84.1366752751778; Tue, 23 Apr 2013 14:32:31 -0700 (PDT) Received: by 10.231.178.197 with HTTP; Tue, 23 Apr 2013 14:32:31 -0700 (PDT) In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B1841378A@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B1841378A@xmb-rcd-x04.cisco.com> Date: Tue, 23 Apr 2013 14:32:31 -0700 Message-ID: From: Wan-Teh Chang To: "David McGrew (mcgrew)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlsiliEG0mEXDrdn4TKPByL1MmP+zde2MSHMGMmjZK/FTKsWvCfdzsgBOuEf7q9rJofO7Qdk1PHFvfTH9FcDilQ8tx+ePTVRFZV8+L81BtljwJdQ/jw65ipwXq0y9x4H5LGmG8Ce7S1sdEVVKi9dRB1ZgncdUVQqVcfAg3nnMMrVL19cex/WEf+Tc4oQ9SQwdOwKBAt Cc: "tls@ietf.org" , Paul Hoffman Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:32:37 -0000 Hi David, I have two questions about the _CCM_8 cipher suites in the -06 draft. 1. I think the Security Considerations section should discuss when it is safe to use the _CCM_8 cipher suites, or state that it is always safe to use them. 2. NIST SP 800-38C Appendix B.2 seems to say it is always safe to use a MAC length (Tlen) of 64 with CCM. In contrast, NIST SP 800-38D Appendix C seems to say that for GCM, 64-bit authentication tags are only appropriate under some constraints. Does this mean there are some fundamental differences between CCM and GCM regarding the use of a 64-bit MAC/tag? Thanks, Wan-Teh From agl@google.com Tue Apr 23 14:40:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C4021F9349 for ; Tue, 23 Apr 2013 14:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAUbxqIWRo6i for ; Tue, 23 Apr 2013 14:40:57 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 614EA21F8E87 for ; Tue, 23 Apr 2013 14:40:57 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so1302088iec.14 for ; Tue, 23 Apr 2013 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Nu0lOqxAWisEXBDxFRfnS5mgfcwZIJtvm4bi0zQvQ5w=; b=Mc7Aj8rum7/9fzTn8F9nAxM90fncQ9QGVcq7ISZZZt5OvksliSU7goDKaZdkwygVN1 8gF+tN383s2KQglmsJTvAoUkbw82hW5iRKFM1128lbZXq3pDc/c9QhHwPYkokDmuPJQ1 d0uvU6IYC8sERzPlewywdEjIdwiW00nfZaSWsOgPD/LiVM6H6EFJLSt4Yr1gIEf2g2/H orUQjNkMCQvszvJmxNoz24U1BhEECMJ9BBw2vnVmwzbHZ6gt4rIbLMIUQaaJAMyNN/Xr y2WJoeoiJIVEYzX0A6jBD6iO+e1rzNYhMvaJ1ww202o0KilpY+50GL9iyEhYmmr6SGik TgyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Nu0lOqxAWisEXBDxFRfnS5mgfcwZIJtvm4bi0zQvQ5w=; b=WbCQUX6BbTPac97cnBnWwgwzyK+vDjg9NRc+AWcFRvV21GhFsBNlr85N2ZMDz5U2Vo TacHh8Y8qSak1JqHolX04oBgthRJr1UZDyEJEnXpnW4c5iVe9WAf+Mb7V1SOvP/gjvtk y9SI0UvWhzpHzsha3AD5dCahjmxRO50dH0PMB9iHDatw4iQm/KhBtilVj8WgwLCDYFgy CGkqP3gMy8YsJsvYwlGvByf8LHrNV6UyxMPUqa2xRW8ohLGvvulgt+ADvKMWPM/TJy5W oWHXzx/ypPLWkAQL+eupipZKCHvZR5L4oDOmBLo5BFtUEsYKmgXSLMTL8SUXpUvNAjhV OUew== MIME-Version: 1.0 X-Received: by 10.50.192.165 with SMTP id hh5mr12305534igc.89.1366753256966; Tue, 23 Apr 2013 14:40:56 -0700 (PDT) Received: by 10.231.12.134 with HTTP; Tue, 23 Apr 2013 14:40:56 -0700 (PDT) In-Reply-To: References: <747787E65E3FBD4E93F0EB2F14DB556B1841378A@xmb-rcd-x04.cisco.com> Date: Tue, 23 Apr 2013 17:40:56 -0400 Message-ID: From: Adam Langley To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk9AnD1/Cynr64bdyb1VOsJ/jxwYz6SwecYiTFWylXkeQf2P+z+gkCk9775Z5z061oj04FVm1yxjSG4/k4s6wZ0e9+AphYdDgicpbAdaIWwgbxrjsVIt00BEKJPrpp0/aUM6Wykrqh7OsvZSmaPu5+wz76UKongLMNHhCYBZyY+z//PmnruZzd+c1YDnVOcesT0HmcK Cc: "tls@ietf.org" , Paul Hoffman Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:40:58 -0000 On Tue, Apr 23, 2013 at 5:32 PM, Wan-Teh Chang wrote: > Does this mean there are some > fundamental differences between CCM and GCM regarding the use of a > 64-bit MAC/tag? I believe that short GCM tags have the weaknesses described in [1], section 4 and 5. CCM uses CBC-MAC and so I believe that the forgery probability goes as one would expect of an n-bit tag. [1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf Cheers AGL From yngve@spec-work.net Tue Apr 23 16:13:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBB521F96E9 for ; Tue, 23 Apr 2013 16:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TEXT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQ8yCnLiVhTy for ; Tue, 23 Apr 2013 16:13:50 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id C2ED321F96F2 for ; Tue, 23 Apr 2013 16:13:49 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:59758 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUmPB-0000r5-L0; Wed, 24 Apr 2013 01:13:45 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes In-Reply-To: References: <515F428E.2010900@gnutls.org> To: "Trevor Perrin" Date: Wed, 24 Apr 2013 01:13:35 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: User-Agent: Opera Mail/12.15 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 23:13:51 -0000 [Resending since it was originally not sent to the group] On Tue, 09 Apr 2013 01:21:56 +0200, Trevor Perrin wrote: > On Mon, Apr 8, 2013 at 12:51 PM, Yngve N. Pettersen > wrote: >> On Mon, 08 Apr 2013 20:34:59 +0200, Trevor Perrin >> wrote: >> >>> Hi Yngve, >>> >>> Thanks for the reference to your rollback prevention draft [1]. I've >>> also seen the Eric Rescorla and Adam Langley proposals [2,3]. >>> >>> These all seem practical ways to enable a TLS-capable party suffering >>> an SSLv3 fallback to detect that the other party is TLS-capable. >>> >>> I'd love to see any of them deployed, so such connections could be >>> rejected. Browser makers could aso preload their browser with a list >>> of TLS-capable sites (such as their own), and disable SSLv3 fallback >>> for them. >> >> >> Opera 12.x already deploy the one I've described (It was also deployed >> in >> Opera 10.50 to 11.0x). > > Interesting! > > To make sure I understand: > - You're saying Opera 12.x will refuse to connect to RFC > 5746-supporting sites if there's a TLS-intolerant middlebox in the > way? Opera will roll back all the way to SSL v3 when it does not know the server's capabilities. If it detect that the server support RFC 5746 it will, restart the handshake using its highest enabled/supported version plus extensions. If the handshake then fails it will report a handshake failure to the user; it will not roll back. Opera caches this result (the highest startable version) for 30 days. > - According to [1,2], about half of all TLS servers are RFC > 5746-supporting? Could I infer that Opera is providing > rollback/MITM/middlebox protection to roughly half of all TLS > connections made by its users? The patch coverage in my sample according to my last numbers (from December 24, 2012) is 75% of servers are patched for renego. That number does not necessarily translate into the same percentage of connections or actively used servers. Essentially, the scheme establishes a connection with one attempt for 98.5% of servers; the remaining servers might require 1-4 more connections to establish a connection or detect a renego "protected" rollback attempt (the sequence for TLS 1.2, if enabled is TLS 1.2+ext->TLS 1.0+ext->TLS 1.0->SSLv3) > If so, that's an impressive step, and great news! Do you think other > browsers will follow suit? No idea, but I know Google is a bit concerned about those middleboxes. >>> Hopefully these actions would force TLS-intolerant middleboxes to be >>> replaced, so browsers could stop having to work-around them and this >>> problem would disappear. >> >> >> I hope my proposal might manage that, but I don't think EKR and Adam's >> proposals will, since they try to work around the broken servers and >> middleboxes, and do not confront them. > > Not sure that's true. From Eric's draft [3]: > """ > If the SCSV value is present and is not equal to > ClientHello.client_version, then the server MUST terminate the > handshake with a fatal "handshake_failure" alert. > """ > > From Adam's post [4]: > """ > the semantics of TLS_CAPABLE_SCSV would be that servers would reject > any SSLv3 handshakes that included this ciphersuite with a fatal > error. > """ > > They have the client explicitly signal TLS capability via an SCSV, > whereas you have the client infer the server's TLS capability from > presence of renegotiation_info. It seems I misremembered how their system worked, but I am still concerned about how well it will scale as new versions of TLS are added. However, I am also concerned about the timeframe for deploying their system. we are currently 3 years into deploying a significant protocol security fix (the renego patch), with 75% of servers patched, and a growth of 8.5 percentage points in the preceeding 12 months, which indicates we have at least 3 more years before closing in on 100% coverage (unless clients start putting on the squeeze by removing padlocks, displaying warnings messages, etc.) After 4-5 years of Certificate Status Extension deployment, coverage is still just 7.6%. After 13 years the SSL v3-only server coverage is still 0.88%, but falling. How long do you think it will take to deploy an SCSV based rollback protection? My guess: not less than it will take to get rid of SSL v3. > So their mechanism only works if both clients and servers support it. > Your mechanism can be rolled out unilaterally in a browser, at the > cost of a higher connection-failure rate (as you've said, ~1/700 > servers return renegotiation_info while being TLS intolerant; whether > rejecting these servers is a "feature" or "bug" is another question > :-) I do think, if all clients were to deploy my method, that the actively used servers with the problem would be gone in weeks; the middleboxes would take longer, but probably not very long. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Tue Apr 23 16:33:34 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9E421F9631 for ; Tue, 23 Apr 2013 16:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huD21qGdP6fp for ; Tue, 23 Apr 2013 16:33:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59C21F962E for ; Tue, 23 Apr 2013 16:33:33 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r3NNXWmC018464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Apr 2013 01:33:32 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Wed, 24 Apr 2013 01:33:31 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130423233331.EB4451A6CF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 23:33:34 -0000 Yngve N. Pettersen wrote: > >> > >> I hope my proposal might manage that, but I don't think EKR and Adam's > >> proposals will, since they try to work around the broken servers and > >> middleboxes, and do not confront them. > > > > Not sure that's true. From Eric's draft [3]: > > """ > > If the SCSV value is present and is not equal to > > ClientHello.client_version, then the server MUST terminate the > > handshake with a fatal "handshake_failure" alert. > > """ > > > > From Adam's post [4]: > > """ > > the semantics of TLS_CAPABLE_SCSV would be that servers would reject > > any SSLv3 handshakes that included this ciphersuite with a fatal > > error. > > """ What I extremely dislike about both of these ideas is (a) they both try to actively increase the interop failures, rather than decrease it (b) they both ignore the various kinds of breakage out there in the installed base that may require ClientHello.client_version to have a specific value to make broken servers happy, rather than the value actually desired by the client. (c) Keep in mind that there is not just old breakage out there, e.g. Microsoft shipped new breakage with Win7/Win2008R2 where they goofed the RSA premaster protocol version check on the renegotiation handshake. For any kind of alternative TLS version negotiation, the server ought to entirely ignore the existing ClientHello.client_version, and use the new version signaling alone for determining the highest common protocol version. -Martin From yngve@spec-work.net Tue Apr 23 17:24:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5EC21F88EA for ; Tue, 23 Apr 2013 17:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3rQw2zMOYQx for ; Tue, 23 Apr 2013 17:24:21 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id E6FB121F881F for ; Tue, 23 Apr 2013 17:24:20 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:60299 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUnVT-0003Gt-T5; Wed, 24 Apr 2013 02:24:19 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <20130423233331.EB4451A6CF@ld9781.wdf.sap.corp> Date: Wed, 24 Apr 2013 02:24:11 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130423233331.EB4451A6CF@ld9781.wdf.sap.corp> User-Agent: Opera Mail/12.15 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:24:21 -0000 On Wed, 24 Apr 2013 01:33:31 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> >> >> I hope my proposal might manage that, but I don't think EKR and >> Adam's >> >> proposals will, since they try to work around the broken servers and >> >> middleboxes, and do not confront them. >> > >> > Not sure that's true. From Eric's draft [3]: >> > """ >> > If the SCSV value is present and is not equal to >> > ClientHello.client_version, then the server MUST terminate the >> > handshake with a fatal "handshake_failure" alert. >> > """ >> > >> > From Adam's post [4]: >> > """ >> > the semantics of TLS_CAPABLE_SCSV would be that servers would reject >> > any SSLv3 handshakes that included this ciphersuite with a fatal >> > error. >> > """ > > What I extremely dislike about both of these ideas is > > (a) they both try to actively increase the interop failures, > rather than decrease it > > (b) they both ignore the various kinds of breakage out there > in the installed base that may require ClientHello.client_version > to have a specific value to make broken servers happy, rather than > the value actually desired by the client. > > (c) Keep in mind that there is not just old breakage out there, > e.g. Microsoft shipped new breakage with Win7/Win2008R2 where > they goofed the RSA premaster protocol version check on the > renegotiation handshake. > > For any kind of alternative TLS version negotiation, the server ought to > entirely ignore the existing ClientHello.client_version, and use the > new version signaling alone for determining the highest common protocol > version. Martin, how do you propose to get *rid* of the broken servers, if clients are not allowed to demonstrate their brokenness? My point is that the old broken server will "never" go away as long as clients allow them to function, and new servers will be released in broken condition because clients are not telling them that they are broken during whatever interoperability testing the vendor did before they released the product. As a result, the problem will never go away. Please note that my proposal allow clients to roll back the version with *non*-Renego patched servers, as before, while requiring clients to never roll back the version and extensions with Renego patched servers. As indicated earlier, 75% of all servers are now patched for Renego, but they make up only ~10% of of the version/extension intolerant servers (which in total make up about 1.5% of all servers, a number that is gradually decreasing as more servers are Renego patched). Thus my proposal aims to reduce the breakage, except with the small percentage of servers that are recently upgraded to a versions that ought to have been fixed for the intolerance issue. The number of such servers is also so low that it should not be an insurmountable task to get them quickly fixed. (the intermediate networks boxes is a different issue) -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Tue Apr 23 18:59:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2963E21F87C5 for ; Tue, 23 Apr 2013 18:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMhO2cvs1mNP for ; Tue, 23 Apr 2013 18:59:25 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 34FFF21F8766 for ; Tue, 23 Apr 2013 18:59:25 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r3O1xNLX014543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Apr 2013 03:59:23 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Wed, 24 Apr 2013 03:59:23 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130424015923.B39761A6CF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 01:59:26 -0000 Yngve N. Pettersen wrote: > > Martin Rex wrote: > > > > For any kind of alternative TLS version negotiation, the server ought to > > entirely ignore the existing ClientHello.client_version, and use the > > new version signaling alone for determining the highest common protocol > > version. > > Martin, how do you propose to get *rid* of the broken servers, if clients > are not allowed to demonstrate their brokenness? > > My point is that the old broken server will "never" go away as long as > clients allow them to function, and new servers will be released in broken > condition because clients are not telling them that they are broken during ... writes the one who has been shipping a multi-stage reconnect fallback for years. The Engineering part of IETF is about creating and maintaining interop, the IETF is no manufacturer cartel for enforcing planned obsolescense! A non-marginal fraction of the problematic servers are not really broken, primarily they're old and based on an old version of the specification. What concerns me *MUCH* more is the reconnect fallback hacks in several recent TLS clients (primarily Web Browsers), because that is what is causing most of the interop problems (=failed TLS handshakes). That negotiating TLSv1.2 by sending ClientHello.client_version = {03,03} is an EXTREMELY dumb idea given the installed base should have been (and still is) painfully obvious for everyone who cared to check, so I really fail to understand why such ostrich behaviour was published as rfc5246 in the first place. Actually the problem already existed in 2006, when rfc4346 was published. Surprise, surprise, ignoring the problem didn't make it go away. When revising a protocol, it is a bad idea to perform it in a fashion that only works in a fantasy fairy-tale, but instead take into account what is going to be interoperable with the real world. What is really needed, is a negotiation of TLSv1.2 protocol&features that does not need ClientHello.client_version = {03,03}, but instead can use ClientHello.client_version = {03,01}. This would get rid of most of the TLS handshake failures and obviate the TLS reconnect fallback hacks in clients. Now _that_ would be really an improvement! But while doing that, we also SHOULD REALLY fix the semantics that are currently specified in rfc5246 for the SignatureAlgorithm TLS extension: strip all the crap between the contents of that extension and signature algorithms in the certificates. -Martin From paduffy@cisco.com Tue Apr 23 22:23:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A024F21F93B3 for ; Tue, 23 Apr 2013 22:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z47sIXZqkDi for ; Tue, 23 Apr 2013 22:23:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2E21F944C for ; Tue, 23 Apr 2013 22:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1327; q=dns/txt; s=iport; t=1366781026; x=1367990626; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HlHVGNtCC8nm43qYXe8ALbOd+pNbAu64do78pl1qcyA=; b=VJItQ61M5DgfT3axTjQEA4FOPLIb/zUzhLjedn0BRAYkNK7aoUDWqfMw GZQLmRQWwr95MO4EgXS0vU5o5vV2QombhHxcWEXbJAWZ46zzuqtU5X13P 7/hYYTWUDCQ75eWRDG6pnaqyaCOJTXfBfiuwqfPhUjuWxMurEnD45rE1C 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANtrd1GtJXHB/2dsb2JhbABQgwY2Ab5PgQwWdIIfAQEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIEAywR4x/BI8oB4NJA5cahgyLEYMBKSA X-IronPort-AV: E=Sophos;i="4.87,540,1363132800"; d="scan'208";a="202309595" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 24 Apr 2013 05:23:45 +0000 Received: from [10.86.255.104] ([10.86.255.104]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3O5NiIp017578; Wed, 24 Apr 2013 05:23:45 GMT Message-ID: <51776C60.3090601@cisco.com> Date: Wed, 24 Apr 2013 01:23:44 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sean Turner References: <5176C1F6.4040806@ieca.com> <8E93BE0F-C4AD-4C81-B92B-04916D3CD289@vigilsec.com> In-Reply-To: <8E93BE0F-C4AD-4C81-B92B-04916D3CD289@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 05:23:47 -0000 Hi Sean I agree with the comments offered by Paul, Russ, and David. FYI, whatever normative dependency exists between CoAP and this draft, several efforts of the Zigbee Alliance also have normative references to this draft (Zigbee IP and Smart Energy Profile 2). The draft was triggered by SEP2's extensive vetting for an ECC standard for LLNs. The Zigbee products are undergoing certification and initial deployments are expected to begin this year. Cheers On 4/23/2013 5:05 PM, Russ Housley wrote: > Sean: > > I do not think this out to include the MTI curve. I would greatly prefer that COAP make use of one of the curves that is already specified. I think a strong reason is needed to specify more curves; the specification of too many will reduce interoperability. > > Russ > > > On Apr 23, 2013, at 1:16 PM, Sean Turner wrote: > >> Hi, >> >> I've been asked to shepherd this document. It's a normative reference for the core COAP WG specification. >> >> My question is whether this draft should include an MTI curve or whether that should be left up to the application. I ask because no other EC TLS cipher suite picks a curve. >> >> spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ynir@checkpoint.com Wed Apr 24 01:47:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95A21F8ECE for ; Wed, 24 Apr 2013 01:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywv5lfUxKFqI for ; Wed, 24 Apr 2013 01:47:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFAB21F8EC1 for ; Wed, 24 Apr 2013 01:47:27 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3O8lPRU014981; Wed, 24 Apr 2013 11:47:25 +0300 X-CheckPoint: {51779B3D-C-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 24 Apr 2013 11:47:25 +0300 From: Yoav Nir To: "" Thread-Topic: [TLS] SCSVs and SSLv3 fallback Thread-Index: AQHOMXe9vLGGrL29KEC+QldzTnP8YJjGdnAAgAFg3ACAAB0uAIAAC1oAgAACGwCAAAfhAIAACK2AgABaT4CAAH5xAIAAT6EAgAAjG4CAAxxZgIAAFXqAgAA6sgCAF5CjgIAABZKAgAAOKICAABqZgIAAcf+A Date: Wed, 24 Apr 2013 08:47:24 +0000 Message-ID: References: <20130424015923.B39761A6CF@ld9781.wdf.sap.corp> In-Reply-To: <20130424015923.B39761A6CF@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1121327bc0bbbccdcb6b9f93741f6b009da6303823 Content-Type: text/plain; charset="us-ascii" Content-ID: <93E7BA454A31E041AF5B4095402A9AEE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] SCSVs and SSLv3 fallback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 08:47:29 -0000 On Apr 24, 2013, at 4:59 AM, Martin Rex wrote: > Yngve N. Pettersen wrote: >>=20 >> Martin Rex wrote: >>>=20 >>> For any kind of alternative TLS version negotiation, the server ought t= o >>> entirely ignore the existing ClientHello.client_version, and use the >>> new version signaling alone for determining the highest common protocol >>> version. >>=20 >> Martin, how do you propose to get *rid* of the broken servers, if client= s =20 >> are not allowed to demonstrate their brokenness? >>=20 >> My point is that the old broken server will "never" go away as long as = =20 >> clients allow them to function, and new servers will be released in brok= en =20 >> condition because clients are not telling them that they are broken duri= ng =20 >=20 > ... writes the one who has been shipping a multi-stage reconnect fallback > for years. What else can Opera do? Ship a browser that works on only 90% of the web? I= think they're doing as much as they can to combat new kinds of brokenness.= If Microsoft had had this attitude when they had a 98% of the browser mark= et, we would be seeing a lot less brokenness today. > The Engineering part of IETF is about creating and maintaining interop, > the IETF is no manufacturer cartel for enforcing planned obsolescense! The IETF is not a manufacturer's cartel. But if people want to change the w= ay TLS clients behave (for whatever reason), this is the place to discuss i= t, and maybe document it. > A non-marginal fraction of the problematic servers are not really broken, > primarily they're old and based on an old version of the specification. What old version of the specification had renegotiation info, but didn't ha= ve proper version negotiation? Going strictly by the RFCs a lot more hands= hakes would be dropped. > What concerns me *MUCH* more is the reconnect fallback hacks in several > recent TLS clients (primarily Web Browsers), because that is what is > causing most of the interop problems (=3Dfailed TLS handshakes). >=20 > That negotiating TLSv1.2 by sending ClientHello.client_version =3D {03,03= } > is an EXTREMELY dumb idea given the installed base should have been > (and still is) painfully obvious for everyone who cared to check, so > I really fail to understand why such ostrich behaviour was published > as rfc5246 in the first place. >=20 > Actually the problem already existed in 2006, when rfc4346 was published. > Surprise, surprise, ignoring the problem didn't make it go away. >=20 > When revising a protocol, it is a bad idea to perform it in a fashion > that only works in a fantasy fairy-tale, but instead take into account > what is going to be interoperable with the real world. >=20 > What is really needed, is a negotiation of TLSv1.2 protocol&features > that does not need ClientHello.client_version =3D {03,03}, but instead > can use ClientHello.client_version =3D {03,01}. This would get rid > of most of the TLS handshake failures and obviate the TLS reconnect > fallback hacks in clients. Now _that_ would be really an improvement! Are you proposing a TLS 1.2 SCSV? If Mozilla hadn't made the decisions to i= nclude Camelia in the list of ciphersuites, we would probably have quite a = few servers out there that didn't tolerate unknown ciphersuites. As it is, = ClientHello.client_version =3D {03,03} works quite well for the vast, vast = majority of web sites. The ostrich wins, and they lived happily ever after. > But while doing that, we also SHOULD REALLY fix the semantics that are > currently specified in rfc5246 for the SignatureAlgorithm TLS extension: > strip all the crap between the contents of that extension and > signature algorithms in the certificates. >=20 >=20 > -Martin From robert.cragie@gridmerge.com Wed Apr 24 10:07:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6894921F95FB for ; Wed, 24 Apr 2013 10:07:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BszjpxjjqS0i for ; Wed, 24 Apr 2013 10:07:25 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id A1CD021F95F4 for ; Wed, 24 Apr 2013 10:07:24 -0700 (PDT) Received: from [94.116.123.191] (helo=[10.38.141.164]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1UV3AA-00047P-UR for tls@ietf.org; Wed, 24 Apr 2013 18:07:22 +0100 Message-ID: <5178114C.4020406@gridmerge.com> Date: Wed, 24 Apr 2013 18:07:24 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: tls@ietf.org References: <5176C1F6.4040806@ieca.com> <8E93BE0F-C4AD-4C81-B92B-04916D3CD289@vigilsec.com> <51776C60.3090601@cisco.com> In-Reply-To: <51776C60.3090601@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040902060302020305060108" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 17:07:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040902060302020305060108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Sean, I too agree with the comments provided by Paul Hoffman, Russ, David and=20 Paul Duffy and also feel the conservative MTI curves specified in the=20 draft promote interoperability. Robert On 24/04/2013 06:23, Paul Duffy wrote: > Hi Sean > > I agree with the comments offered by Paul, Russ, and David. > > FYI, whatever normative dependency exists between CoAP and this draft, = > several efforts of the Zigbee Alliance also have normative references=20 > to this draft (Zigbee IP and Smart Energy Profile 2). The draft was=20 > triggered by SEP2's extensive vetting for an ECC standard for LLNs. =20 > The Zigbee products are undergoing certification and initial=20 > deployments are expected to begin this year. > > Cheers > > > > On 4/23/2013 5:05 PM, Russ Housley wrote: >> Sean: >> >> I do not think this out to include the MTI curve. I would greatly=20 >> prefer that COAP make use of one of the curves that is already=20 >> specified. I think a strong reason is needed to specify more curves; = >> the specification of too many will reduce interoperability. >> >> Russ >> >> >> On Apr 23, 2013, at 1:16 PM, Sean Turner wrote: >> >>> Hi, >>> >>> I've been asked to shepherd this document. It's a normative=20 >>> reference for the core COAP WG specification. >>> >>> My question is whether this draft should include an MTI curve or=20 >>> whether that should be left up to the application. I ask because no = >>> other EC TLS cipher suite picks a curve. >>> >>> spt >> _______________________________________________ >> 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 > --------------ms040902060302020305060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA0MjQxNzA3MjRaMCMGCSqGSIb3DQEJBDEWBBRn52A0RG5+QRvMo6+4rdyI6Nqr5zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAKFsu+dqILUARgOdJyAGcv1v+Sxo0f1/kE8j70O8UabPcdg4 gn+BOcD9ErgmdLCTCF8FrNTILRRbdmG9Y2zm0RGIz0fzmzqNSI7NUDjuDDrr3jaUpy3DY5Le EZUaPpogCYTrxUZOLm2wBKQH5pmyhIN5csL+EXjH7VgMx08Naeozn8VvJM9t/jJhOpS3Kv92 LG0ZeqJsqCaOb3mTLMx9hQ8YrBCQexVKGUMjBYl62ebELE53GVbfNCiqyO4OLZZOSb1gg9Ri QwvTbvr5WxO//kmBEYEhc3y/cbDtD791QQaHsCgMRku1nmJiFmjPV6u/So6Prejs5Qi8t22r yxfv2fcAAAAAAAA= --------------ms040902060302020305060108-- From Bert.Greevenbosch@huawei.com Thu Apr 25 01:19:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A8B21F9406 for ; Thu, 25 Apr 2013 01:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caqTMHJmQmOE for ; Thu, 25 Apr 2013 01:19:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC66A21F8E6A for ; Thu, 25 Apr 2013 01:19:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQU13900; Thu, 25 Apr 2013 08:19:43 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Apr 2013 09:18:59 +0100 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Apr 2013 09:19:33 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.007; Thu, 25 Apr 2013 16:19:12 +0800 From: Bert Greevenbosch To: Paul Wouters Thread-Topic: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) Thread-Index: AQHOQCfJJzrk5rNHc0etJNdCKSbDnZjmfbsQ Date: Thu, 25 Apr 2013 08:19:11 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D718516@szxeml558-mbx.china.huawei.com> References: <516D5ADE.3050506@ieca.com> <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tls@ietf.org" Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 08:19:49 -0000 SGkgUGF1bCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrLg0KDQpJbmRlZWQgYW4gT1ND UC1saXRlIHJlc3BvbmRlciB3b3VsZCBiZSBzaW1pbGFyIHRvIGEgVHJ1c3QgQXV0aG9yaXR5IChU QSkgaW4gdGhhdCBpdCBpcyBhIHRoaXJkIHBhcnR5IHRoYXQgY2FuIGNvbmZpcm0gb3IgaW52YWxp ZGF0ZSBhIHJhdyBwdWJsaWMga2V5Lg0KDQpNeSBjb25jZXJuIGlzLCB0aGF0IHdoZW4gb21pdHRp bmcgdGhlIGNlcnRpZmljYXRlIGFuZCBlc3BlY2lhbGx5IHRoZSBUQSwgYW55b25lIGNhbiBnZW5l cmF0ZSBhIHJhdyBwdWJsaWMga2V5LiBOb3cgaW5kZWVkIHRoZXJlIGFyZSBtdWx0aXBsZSB3YXlz IHRvIHRhY2tsZSB0aGlzIHByb2JsZW0gdGhvdWdoIG91dC1vZi1iYW5kIG1lY2hhbmlzbXM7IGFu IGV4YW1wbGUgaW4gQ29BUCBpcyBnaXZlbiBieSBhIGJhcmNvZGUgc2Nhbm5lciB0aGF0IGlzIHVz ZWQgdG8gcGh5c2ljYWxseSBzY2FuIHRoZSBwdWJsaWMga2V5LiBJbiB0aGF0IGNhc2UgdGhlIHRy dXN0IGxpZXMgaW4gdGhlIGZhY3QgdGhhdCB0aGUgYmFyY29kZSBpcyBjb25zaWRlcmVkIGF1dGhl bnRpYy4NCg0KTmV2ZXJ0aGVsZXNzLCB3aGVuIHlvdSBkbyBhdXRvbWF0aWMgZXhjaGFuZ2UgYXMg ZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXRscy1vb2ItcHVia2V5LCB5b3UgbmVlZCBzb21ldGhpbmcg dGhhdCBhdXRoZW50aWNhdGVzIHRoZSBrZXkuIFRoaXMgaG9sZHMgZXZlbiBtb3JlIGFzIGEgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkgc2lnbmF0dXJlIHRoYXQgYXV0aGVudGljYXRlcyB0aGUgY2Vy dGlmaWNhdGUgaXMgbm90IGF2YWlsYWJsZS4NCg0KPHF1b3RlPg0KRm9yIGluc3RhbmNlLCB1c2lu ZyBETlMoU0VDKSB3aXRoIHJhdyBrZXlzIHRoZXJlIGlzIG9ubHkgQiBhbmQgQy4gV2hlbg0KQiBs b3NlcyB0cnVzdCBpbiB0aGVpciBrZXksIHRoZXkgc2ltcGxlIHJlbW92ZSBpdCBmcm9tIEROUyhT RUMpIHRvDQpjb21tdW5pY2F0ZSB0aGlzIHRvIEEuIFRoZSBzYW1lIGFwcGxpZXMgdG8gU1NIRlAg cmVjb3JkcyBpbiBETlMoU0VDKQ0Kb3IgQWN0aXZlRGlyZWN0b3J5Lg0KDQouLi4NCg0KVXNpbmcg VExTIHJhdyBrZXlzIGZyb20gRE5TU0VDLCBUaGUgUlJTSUcvVFRMIGFuZCBETlMgdHJ1c3QgYW5j aG9ycyBjYW4NCnR1bmUgdGhlIGJlaGF2aW91ciBvZiB3aGVuIFRMUyByYXcga2V5cyBhcmUgdmFs aWQgb3Igbm90LiBObyBPQ1NQIHZhcmlhbnQNCmlzIG5lY2Nlc3NhcnkuIFRoZSBzYW1lIGlzIHRy dWUgZm9yIGNvbnRlbnQgYmFzZWQgb24gQWN0aXZlRGlyZWN0b3J5L0xEQVANCm9yIFJhZGl1cy9E aWFtZXRlciB3aGVyZSB0aGVyZSBpcyBhbHJlYWR5IGEgY2VudHJhbCBjb250cm9sIG1lY2hhbmlz bQ0KZm9yIHJlbGF5aW5nIHRoaXMgaW5mb3JtYXRpb24uDQo8L3F1b3RlPg0KDQpJIHVuZGVyc3Rh bmQgdGhhdCB5b3UgbWVhbiBCIGxvc2VzIGl0cyB0cnVzdCBpbiBpdHMgb3duIGtleT8gVGhlbiB5 ZXMsIGFzIGEgZ29vZCBjaXRpemVuIEIgY291bGQgY29tbXVuaWNhdGUgdGhpcyB0aHJvdWdoIHRo ZXNlIG1lYW5zLiBBbmQgaWYgQiBpcyBiYWQgYW5kIGl0IGlzIGZvdW5kIG91dCwgdGhlbiB0aGUg RE5TKFNFQykgY2FuIHJlbW92ZSBCJ3Mga2V5LiBJZiBCIG5ldmVyIHdhcyB0byBiZSB0cnVzdGVk LCB0aGUgRE5TKFNFQykgd291bGQgbm90IGJlIGFibGUgdG8gcHJvdmlkZSBpdHMga2V5LiBJbiBh bGwgdGhlc2UgY2FzZXMgdGhlIEROUyhTRUMpIGlzIHRoZSB0aGlyZCBwYXJ0eSBwcm92aWRpbmcg YXV0aGVudGljYXRpb24gYW5kIHJldm9jYXRpb24uDQoNCkFsc28sIGluIGEgY2xpZW50L3NlcnZl ciBtb2RlbCwgSSBhbSBub3Qgc3VyZSBpZiB0aGUgY2xpZW50J3MgcmF3IHB1YmxpYyBrZXkgY2Fu IGJlIHZlcmlmaWVkIHdpdGggRE5TKFNFQykuIERvZXMgYSBjbGllbnQgbm9ybWFsbHkgaGF2ZSBh IEROUyBlbnRyeSwgZS5nLiBhIG5hbWUgdGhhdCBjYW4gYmUgbG9va2VkIHVwIHRocm91Z2ggRE5T PyBJbiBUTFMsIHRoZSBjbGllbnQgcHJvdmlkZXMgaXRzIGNvbXBsZXRlIGNlcnRpZmljYXRlIGNo YWluLCB3aGljaCBpcyBmb3IgdGhlIHNlcnZlciB0byB2ZXJpZnkuIFBhcnQgb2YgdGhpcyB2ZXJp ZmljYXRpb24gbm9ybWFsbHkgaXMgcmV2b2NhdGlvbiBjaGVja2luZywgZS5nLiB0aHJvdWdoIE9D U1Agb3IgQ1JMIGxpc3RzLiBEb2VzIHRoYXQgbWVhbiB0aGF0IHdoZW4gdXNpbmcgRE5TKFNFQykg YXMgdGhlIG91dC1vZi1iYW5kIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBvZiB0aGUgcmF3IHB1 YmxpYyBrZXksIGVhY2ggY2xpZW50IG5lZWRzIHRvIGJlIHJlZ2lzdGVyZWQgd2l0aCB0aGUgRE5T KFNFQyk/DQoNCjxxdW90ZT4NCk9DU1Agd2FzIG9ubHkgbmVlZGVkIGJlZm9yZSBiZWNhdXNlIHRo ZXJlIHdlcmUgdGhyZWUgcGFydGllcy4gV2hpbGUgaXQNCmlzIHN0aWxsIHBvc3NpYmxlIGFuIG91 dCBvZiBiYW5kIG1ldGhvZCB0byB2YWxpZGF0ZSBUTFMga2V5cyB0byByZXF1aXJlDQp0aHJlZSBw YXJ0aWVzLCBhbnkgcmV2b2NhdGlvbiBsaXN0IG1lY2hhbmlzbSBzaG91bGQgYmUgcGFydCBvZiB0 aGUgb3V0DQpvZiBiYW5kIG1ldGhvZCBzcGVjaWZpY2F0aW9uLiBJIGFtIG5vdCBzdXJlIHdoYXQg b3V0IG9mIGJhbmQgbWV0aG9kIHRoaXMNCk9DU1AtbGl0ZSBjYXNlIGNvdmVycy4gSWYgdGhlcmUg aXMgYSBzcGVjaWZpY2F0aW9uIG9mIHRoYXQgb3V0IG9mIGJhbmQNCm1ldGhvZCwgdGhlbiB0aGF0 IHNwZWNpZmljYXRpb24gc2hvdWxkIHBlcmhhcHMgaW5jbHVkZSB0aGlzIE9DU1AtbGl0ZQ0Kc3Bl Y2lmaWNhdGlvbiBhcyBwYXJ0IG9mIGl0Lg0KPC9xdW90ZT4NCg0KSW5kZWVkIHRoYXQgaXMgdGhl IGlkZWEuIFRoZSBPQ1NQLWxpdGUgaXMgYW4gb3V0LW9mLWJhbmQgbWV0aG9kIGZvciBhdXRoZW50 aWNhdGlvbiBvZiB0aGUgcmF3IHB1YmxpYyBrZXkgaW4gaXRzZWxmLiBUaGUgYWR2YW50YWdlIG9m IHRoZSBPQ1NQLWxpdGUgYXBwcm9hY2ggaXMgdGhhdCBpdCBkb2VzIG5vdCBuZWVkIEROUyhTRUMp IHRvIGVzdGFibGlzaCBzZWN1cmUgY29tbXVuaWNhdGlvbi4gVGhpcyBtYXkgZXNwZWNpYWxseSBi ZSB1c2VmdWwgZm9yIGVuZHBvaW50cyB0aGF0IGRvIG5vdCBoYXZlIGEgZG9tYWluIG5hbWUsIGFu ZCBhcmUgZGlyZWN0bHkgaWRlbnRpZmllZCBieSB0aGVpciBJUCBhZGRyZXNzLiBHb2FsIG9mIE9D U1AtbGl0ZSBpcyB0byBrZWVwIHZlcmlmaWNhdGlvbiBmb3IgdGhlIGNsaWVudCBhcyBlYXN5IGFz IHBvc3NpYmxlLCBpLmUuIHB1dCBtb3N0IG9mIHRoZSBidXJkZW4gb24gdGhlIE9DU1AtbGl0ZSBy ZXNwb25kZXIuDQoNCldoYXQgZG8geW91IHRoaW5rPw0KIA0KQmVzdCByZWdhcmRzLA0KQmVydA0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIFdvdXRlcnMgW21haWx0 bzpwYXVsQG5vaGF0cy5jYV0gDQpTZW50OiAyMDEzxOo01MIyM8jVIDIxOjI4DQpUbzogQmVydCBH cmVldmVuYm9zY2gNCkNjOiBTYWx6LCBSaWNoOyBTZWFuIFR1cm5lcjsgdGxzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW1RMU10gUmV2b2NhdGlvbiBhbmQgYXV0aGVudGljYXRpb24gb2YgcmF3IHB1 YmxpYyBrZXkgKHdhczogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdGxzLW9vYi1wdWJrZXkpDQoN Ck9uIFR1ZSwgMjMgQXByIDIwMTMsIEJlcnQgR3JlZXZlbmJvc2NoIHdyb3RlOg0KDQo+IEkgdGhp bmsgbmFtZS10by1rZXkgYXNzb2NpYXRpb24gaXMgaGFsZiBvZiB0aGUgcHJvYmxlbSwgd2hlcmVh cyByZXZvY2F0aW9uIGlzIHRoZSBzZWNvbmQgaGFsZi4gU1NIIHNlZW1zIHRvIGZvY3VzIG9uIHRo ZSBmaXJzdCBoYWxmLCB3aGVyZWFzIE9DU1AtbGl0ZSBmb2N1c2VzIG1haW5seSBvbiB0aGUgc2Vj b25kIGhhbGYuDQoNClJldm9jYXRpb24gaXMgb25seSByZXF1aXJlZCBpbiB0aGUgaW5kaXJlY3Qg cGF0aC4gVGhhdCBpcywgc3VwcGxpZXIgQQ0Kc2lnbnMgc29tZXRoaW5nIGZvciBjb25zdW1lciBC LCBhbmQgZW5kdXNlciBDIG5lZWRzIHRvIHZlcmlmeSBCLiBOb3cgQQ0KbmVlZHMgYSBtZXRob2Qg dG8gdGVsbCBDIGFib3V0IHJldm9jYXRpb24gb2YgQi4NCg0KV2hlbiB5b3UgdXNlIHJhdyBwdWJs aWMga2V5cywgdGhlIGF1dGhlbnRpY2F0aW9uIGhhcHBlbnMgb3V0IG9mIGJhbmQuIElmDQp0aGVy ZSBhcmUgbm8gdGhyZWUgcGxheWVycywgd2l0aCB0d28gb2YgdGhlbSB0YWxraW5nIG9ubHkgaW5k aXJlY3RseSwNCm5vIE9DU1AtbGlrZSBtZWNoYW5pc20gaXMgcmVxdWlyZWQuDQoNCkZvciBpbnN0 YW5jZSwgdXNpbmcgRE5TKFNFQykgd2l0aCByYXcga2V5cyB0aGVyZSBpcyBvbmx5IEIgYW5kIEMu IFdoZW4NCkIgbG9zZXMgdHJ1c3QgaW4gdGhlaXIga2V5LCB0aGV5IHNpbXBsZSByZW1vdmUgaXQg ZnJvbSBETlMoU0VDKSB0bw0KY29tbXVuaWNhdGUgdGhpcyB0byBBLiBUaGUgc2FtZSBhcHBsaWVz IHRvIFNTSEZQIHJlY29yZHMgaW4gRE5TKFNFQykNCm9yIEFjdGl2ZURpcmVjdG9yeS4NCg0KT0NT UCB3YXMgb25seSBuZWVkZWQgYmVmb3JlIGJlY2F1c2UgdGhlcmUgd2VyZSB0aHJlZSBwYXJ0aWVz LiBXaGlsZSBpdA0KaXMgc3RpbGwgcG9zc2libGUgYW4gb3V0IG9mIGJhbmQgbWV0aG9kIHRvIHZh bGlkYXRlIFRMUyBrZXlzIHRvIHJlcXVpcmUNCnRocmVlIHBhcnRpZXMsIGFueSByZXZvY2F0aW9u IGxpc3QgbWVjaGFuaXNtIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBvdXQNCm9mIGJhbmQgbWV0aG9k IHNwZWNpZmljYXRpb24uIEkgYW0gbm90IHN1cmUgd2hhdCBvdXQgb2YgYmFuZCBtZXRob2QgdGhp cw0KT0NTUC1saXRlIGNhc2UgY292ZXJzLiBJZiB0aGVyZSBpcyBhIHNwZWNpZmljYXRpb24gb2Yg dGhhdCBvdXQgb2YgYmFuZA0KbWV0aG9kLCB0aGVuIHRoYXQgc3BlY2lmaWNhdGlvbiBzaG91bGQg cGVyaGFwcyBpbmNsdWRlIHRoaXMgT0NTUC1saXRlDQpzcGVjaWZpY2F0aW9uIGFzIHBhcnQgb2Yg aXQuDQoNCkkgZG9uJ3Qgc2VlIGEgdmFsdWUgb2Ygc3BlY2lmeWluZyBhIGdlbmVyaWMgcmV2b2Nh dGlvbiBtZXRob2QuIEkgc2VlDQpkYW5nZXIgaW4gc3VjaCBhIHNwZWNpZmljYXRpb24gaWYgaXQg X2ludHJvZHVjZXNfIGEgdGhpcmQgcGxheWVyIHdoZXJlDQp0aGVyZSBzaG91bGQgbm90IGJlIG9u ZSBmb3IgYSBzcGVjaWZpYyBvdXQgb2YgYmFuZCBhdXRoZW50aWNhdGlvbg0KbWV0aG9kLg0KDQpV c2luZyBUTFMgcmF3IGtleXMgZnJvbSBETlNTRUMsIFRoZSBSUlNJRy9UVEwgYW5kIEROUyB0cnVz dCBhbmNob3JzIGNhbg0KdHVuZSB0aGUgYmVoYXZpb3VyIG9mIHdoZW4gVExTIHJhdyBrZXlzIGFy ZSB2YWxpZCBvciBub3QuIE5vIE9DU1AgdmFyaWFudA0KaXMgbmVjY2Vzc2FyeS4gVGhlIHNhbWUg aXMgdHJ1ZSBmb3IgY29udGVudCBiYXNlZCBvbiBBY3RpdmVEaXJlY3RvcnkvTERBUA0Kb3IgUmFk aXVzL0RpYW1ldGVyIHdoZXJlIHRoZXJlIGlzIGFscmVhZHkgYSBjZW50cmFsIGNvbnRyb2wgbWVj aGFuaXNtDQpmb3IgcmVsYXlpbmcgdGhpcyBpbmZvcm1hdGlvbi4NCg0KUGF1bA0K From pgut001@cs.auckland.ac.nz Thu Apr 25 06:54:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538B121F84CA for ; Thu, 25 Apr 2013 06:54:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-5AI9l5ftVk for ; Thu, 25 Apr 2013 06:54:17 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2821F8BDD for ; Thu, 25 Apr 2013 06:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1366898057; x=1398434057; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8stiDCUuuE788BgDRH6pOPZlWwgfY11eB1sIKUB5Vxg=; b=IQFL86vvBJ8sy6F7WaDt2c1VkfXgN9GqcEjMFKSoGmuyllI9nu7UOyvj Dkgr+QdU1tTLTE3tCvrkL3wXBko1XM1PdNNmvJ6IydxG0heJYF8O37sHg UMQvU8bVRa8rCaUAOYQP5K0Ts2TH6UuWgXsHpKkfznyZcVdsqbVGqTBfc s=; X-IronPort-AV: E=Sophos;i="4.87,551,1363086000"; d="scan'208";a="182992679" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Apr 2013 01:54:02 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.4]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 01:54:02 +1200 From: Peter Gutmann To: "Salz, Rich" , Bert Greevenbosch , Sean Turner , "tls@ietf.org" Thread-Topic: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) Thread-Index: Ac5BvFcbnh9wD4SzROiHAsxbG9wIWw== Date: Thu, 25 Apr 2013 13:54:01 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D4642E@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 13:54:18 -0000 "Salz, Rich" writes:=0A= =0A= >I thought Peter Gutman had an I-D on SSH key management, but I can't find = it=0A= >now (it could have been years since I looked).=0A= =0A= It was on key continuity management in general:=0A= =0A= http://tools.ietf.org/html/draft-gutmann-keycont-01=0A= =0A= I ended up using it as the basis for a book chapter, I'd probably have to= =0A= reverse the book text back into the draft to complete it, if there's any=0A= interest.=0A= =0A= Peter.= From internet-drafts@ietf.org Thu Apr 25 14:08:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0421F9605; Thu, 25 Apr 2013 14:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CINmc0FK98QR; Thu, 25 Apr 2013 14:08:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D6221F8233; Thu, 25 Apr 2013 14:08:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425210823.1147.90793.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 14:08:23 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-applayerprotoneg-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:08:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Transport Layer Security (TLS) Application Layer Protoco= l Negotiation Extension Author(s) : Stephan Friedl Andrei Popov Adam Langley Emile Stephan Filename : draft-ietf-tls-applayerprotoneg-01.txt Pages : 8 Date : 2013-04-25 Abstract: This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-applayerprotoneg-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sfriedl@cisco.com Thu Apr 25 14:19:08 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A4C21F8FF2 for ; Thu, 25 Apr 2013 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgcgnGs47Os4 for ; Thu, 25 Apr 2013 14:19:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91B21F8FCF for ; Thu, 25 Apr 2013 14:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5950; q=dns/txt; s=iport; t=1366924747; x=1368134347; h=from:to:subject:date:message-id:mime-version; bh=8qpDdCPtkB8wxvjYlJsq9qonmiELSbF8kttld6l2dbw=; b=afw1PvDMrxBgsD7mHfSpBKv0iTgt1TGR+qG3WY9U7dv1wHxjxCDxyE37 0RF8H6oWHdSCmpKLGfHnOJ3eSUWlN/vBmd5gSRZ7dIb808tUUDVgLukEM fPsPKOI/zD67+hh30P3WPJb8t1qLkTVUwgO/Q4f/BemLLVH57rtoGK72J Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYGAIiceVGtJXG//2dsb2JhbABRgkJENr4xgQQWbQeCIQEELV4BKlYmAQQbiAyeVKADjwSDJWEDqD6DDoIo X-IronPort-AV: E=Sophos;i="4.87,553,1363132800"; d="scan'208,217";a="202985184" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 25 Apr 2013 21:19:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3PLJ6kZ031311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 25 Apr 2013 21:19:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 16:19:06 -0500 From: "Stephan Friedl (sfriedl)" To: "tls@ietf.org" Thread-Topic: New Revision: draft-ietf-tls-applayerprotoneg-01 Posted Thread-Index: Ac5B+oPWLKUAIyveSXqvg908sXzhVA== Date: Thu, 25 Apr 2013 21:19:05 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B9C35D@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.37.98] Content-Type: multipart/alternative; boundary="_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B9C35Dxmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [TLS] New Revision: draft-ietf-tls-applayerprotoneg-01 Posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:19:08 -0000 --_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B9C35Dxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have posted a new revision of draft-ietf-tls-applayerprotoneg-01. Chang= es to this version include: 1. Revised Introduction 2. Addition of HTTP/2 in the references section 3. Removal of paragraph on hash calculations (in response to WG feedb= ack) 4. Clean up of some references within the document and reference form= ats 5. Addition of Adam Langley from Google as a co-author 6. Addition of Emile Stephan from France Telecom - Orange as a co-aut= hor We are very interested in any review comments or feedback that we can use t= o further improve the draft. Best Wishes, Stephan Friedl --_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B9C35Dxmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have posted a new revision of draft-ietf-tls-appl= ayerprotoneg-01.  Changes to this version include:

 

1.     &= nbsp; Revised Introduction

2.     &= nbsp; Addition of HTTP/2 in the references section

3.     &= nbsp; Removal of paragraph on hash calculations (in respo= nse to WG feedback)

4.     &= nbsp; Clean up of some references within the document and= reference formats

5.     &= nbsp; Addition of Adam Langley from Google as a co-author=

6.     &= nbsp; Addition of Emile Stephan from France Telecom ̵= 1; Orange as a co-author

 

We are very interested in any review comments or fee= dback that we can use to further improve the draft.

 

Best Wishes,

 

Stephan Friedl

 

--_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B9C35Dxmbalnx02ciscoc_-- From trevp@trevp.net Thu Apr 25 18:59:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8A21F970F for ; Thu, 25 Apr 2013 18:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Erpq5ZAXlZkY for ; Thu, 25 Apr 2013 18:59:27 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5321F96C5 for ; Thu, 25 Apr 2013 18:59:26 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so3359709lbi.11 for ; Thu, 25 Apr 2013 18:59:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=HaycBSPp0fTrzz1WG/9PJX4bl9gg/UhVzREEOz3ifl4=; b=VnOP2u0ouLCpGo+YrLNhwG46aWcVyz43jOYoxWdZPkqEX2leriz4LLmN7iQW2EipZk FkknuavkbySIg9lxfxZ+ws/PMg/YPVBRhgop4LFelbkpZX4y8LeZBhh0B+9Uz4j/MA4u sLt/SvTlya28Y1O5PqWknrdUue+rTzFXcRw0TgdIDuAgUC8f5VZqPWiaheUf6jMSX47D Z4iZS2XxNwGNsaSaSmR2V0F37rfixuAJVp7awIUugf30RbwrvoGiS5nrUeK15H6+K1AV wD2k2apjDupJKFXivV/qNtC396EbUn2l51JX9A7iH5oq0cQy7GZpw53ieMjm2gmvYxOM meNg== MIME-Version: 1.0 X-Received: by 10.112.150.228 with SMTP id ul4mr8760911lbb.132.1366941565628; Thu, 25 Apr 2013 18:59:25 -0700 (PDT) Received: by 10.114.62.47 with HTTP; Thu, 25 Apr 2013 18:59:25 -0700 (PDT) X-Originating-IP: [66.215.127.122] In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D718516@szxeml558-mbx.china.huawei.com> References: <516D5ADE.3050506@ieca.com> <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com> <2A0EFB9C05D0164E98F19BB0AF3708C7B311446B@USMBX1.msg.corp.akamai.com> <46A1DF3F04371240B504290A071B4DB63D716CC2@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D718516@szxeml558-mbx.china.huawei.com> Date: Thu, 25 Apr 2013 18:59:25 -0700 Message-ID: From: Trevor Perrin To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=047d7b342d2872c53d04db39e2cc X-Gm-Message-State: ALoCoQnhge2p692GXbGmSOfMdPcTWxZPfz1QUsR156TzEpzuiKHEx3PlnU4ZCDHAlapABTrX5h+J Cc: "tls@ietf.org" Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 01:59:28 -0000 --047d7b342d2872c53d04db39e2cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bert, You may be interested in TACK [1]. TACK allows a client to verify a server's identity based on client knowledge of a "TACK signing key" which signs the server's TLS key(s). These signatures are presented in the TLS handshake along with an expiration time and revocation info for earlier signatures. This enables the server operator to use a "more-secure" offline signing key to revoke and replace the "more-exposed" TLS keys, akin to your OCSP-lite proposal. TACK was designed to be compact and simple to verify, and requires no X.509 certs, so it would work well with draft-ietf-tls-oob-pubkey. Trevor [1] http://datatracker.ietf.org/doc/draft-perrin-tls-tack/ On Thu, Apr 25, 2013 at 1:19 AM, Bert Greevenbosch < Bert.Greevenbosch@huawei.com> wrote: > Hi Paul, > > Thank you for your feedback. > > Indeed an OSCP-lite responder would be similar to a Trust Authority (TA) > in that it is a third party that can confirm or invalidate a raw public k= ey. > > My concern is, that when omitting the certificate and especially the TA, > anyone can generate a raw public key. Now indeed there are multiple ways = to > tackle this problem though out-of-band mechanisms; an example in CoAP is > given by a barcode scanner that is used to physically scan the public key= . > In that case the trust lies in the fact that the barcode is considered > authentic. > > Nevertheless, when you do automatic exchange as defined in > draft-ietf-tls-oob-pubkey, you need something that authenticates the key. > This holds even more as a Certification Authority signature that > authenticates the certificate is not available. > > > For instance, using DNS(SEC) with raw keys there is only B and C. When > B loses trust in their key, they simple remove it from DNS(SEC) to > communicate this to A. The same applies to SSHFP records in DNS(SEC) > or ActiveDirectory. > > ... > > Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can > tune the behaviour of when TLS raw keys are valid or not. No OCSP variant > is neccessary. The same is true for content based on ActiveDirectory/LDAP > or Radius/Diameter where there is already a central control mechanism > for relaying this information. > > > I understand that you mean B loses its trust in its own key? Then yes, as > a good citizen B could communicate this through these means. And if B is > bad and it is found out, then the DNS(SEC) can remove B's key. If B never > was to be trusted, the DNS(SEC) would not be able to provide its key. In > all these cases the DNS(SEC) is the third party providing authentication > and revocation. > > Also, in a client/server model, I am not sure if the client's raw public > key can be verified with DNS(SEC). Does a client normally have a DNS entr= y, > e.g. a name that can be looked up through DNS? In TLS, the client provide= s > its complete certificate chain, which is for the server to verify. Part o= f > this verification normally is revocation checking, e.g. through OCSP or C= RL > lists. Does that mean that when using DNS(SEC) as the out-of-band > authentication mechanism of the raw public key, each client needs to be > registered with the DNS(SEC)? > > > OCSP was only needed before because there were three parties. While it > is still possible an out of band method to validate TLS keys to require > three parties, any revocation list mechanism should be part of the out > of band method specification. I am not sure what out of band method this > OCSP-lite case covers. If there is a specification of that out of band > method, then that specification should perhaps include this OCSP-lite > specification as part of it. > > > Indeed that is the idea. The OCSP-lite is an out-of-band method for > authentication of the raw public key in itself. The advantage of the > OCSP-lite approach is that it does not need DNS(SEC) to establish secure > communication. This may especially be useful for endpoints that do not ha= ve > a domain name, and are directly identified by their IP address. Goal of > OCSP-lite is to keep verification for the client as easy as possible, i.e= . > put most of the burden on the OCSP-lite responder. > > What do you think? > > Best regards, > Bert > > > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: 2013=E5=B9=B44=E6=9C=8823=E6=97=A5 21:28 > To: Bert Greevenbosch > Cc: Salz, Rich; Sean Turner; tls@ietf.org > Subject: Re: [TLS] Revocation and authentication of raw public key (was: > AD review of draft-ietf-tls-oob-pubkey) > > On Tue, 23 Apr 2013, Bert Greevenbosch wrote: > > > I think name-to-key association is half of the problem, whereas > revocation is the second half. SSH seems to focus on the first half, > whereas OCSP-lite focuses mainly on the second half. > > Revocation is only required in the indirect path. That is, supplier A > signs something for consumer B, and enduser C needs to verify B. Now A > needs a method to tell C about revocation of B. > > When you use raw public keys, the authentication happens out of band. If > there are no three players, with two of them talking only indirectly, > no OCSP-like mechanism is required. > > For instance, using DNS(SEC) with raw keys there is only B and C. When > B loses trust in their key, they simple remove it from DNS(SEC) to > communicate this to A. The same applies to SSHFP records in DNS(SEC) > or ActiveDirectory. > > OCSP was only needed before because there were three parties. While it > is still possible an out of band method to validate TLS keys to require > three parties, any revocation list mechanism should be part of the out > of band method specification. I am not sure what out of band method this > OCSP-lite case covers. If there is a specification of that out of band > method, then that specification should perhaps include this OCSP-lite > specification as part of it. > > I don't see a value of specifying a generic revocation method. I see > danger in such a specification if it _introduces_ a third player where > there should not be one for a specific out of band authentication > method. > > Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can > tune the behaviour of when TLS raw keys are valid or not. No OCSP variant > is neccessary. The same is true for content based on ActiveDirectory/LDAP > or Radius/Diameter where there is already a central control mechanism > for relaying this information. > > Paul > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b342d2872c53d04db39e2cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Bert,

You = may be interested in TACK [1].

TACK allows a clien= t to verify a server's identity based on client knowledge of a "TA= CK signing key" which signs the server's TLS key(s). =C2=A0These s= ignatures are presented in the TLS handshake along with an expiration time = and revocation info for earlier signatures. =C2=A0

This enables the server operator to use a "more-se= cure" offline signing key to revoke and replace the "more-exposed= " TLS keys, akin to your OCSP-lite proposal.

TACK was designed to be compact and simple to verify, and requires no X.509= certs, so it would work well with draft-ietf-tls-oob-pubkey.

Trevor



=


On Thu,= Apr 25, 2013 at 1:19 AM, Bert Greevenbosch <Bert.Greevenbosc= h@huawei.com> wrote:
Hi Paul,

Thank you for your feedback.

Indeed an OSCP-lite responder would be similar to a Trust Authority (= TA) in that it is a third party that can confirm or invalidate a raw public= key.

My concern is, that when omitting the certificate and especially the TA, an= yone can generate a raw public key. Now indeed there are multiple ways to t= ackle this problem though out-of-band mechanisms; an example in CoAP is giv= en by a barcode scanner that is used to physically scan the public key. In = that case the trust lies in the fact that the barcode is considered authent= ic.

Nevertheless, when you do automatic exchange as defined in draft-ietf-tls-o= ob-pubkey, you need something that authenticates the key. This holds even m= ore as a Certification Authority signature that authenticates the certifica= te is not available.

<quote>
For instance, using DNS(SEC) with raw keys there is only = B and C. When
B loses trust in their key, they simple remove it from DNS(SEC) to
communicate this to A. The same applies to SSHFP records in DNS(SEC)
or ActiveDirectory.

...

Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can
tune the behaviour of when TLS raw keys are valid or not. No OCSP variant is neccessary. The same is true for content based on ActiveDirectory/LDAP or Radius/Diameter where there is already a central control mechanism
for relaying this information.
</quote>

I understand that you mean B loses its trust in its own key? Then yes, as a= good citizen B could communicate this through these means. And if B is bad= and it is found out, then the DNS(SEC) can remove B's key. If B never = was to be trusted, the DNS(SEC) would not be able to provide its key. In al= l these cases the DNS(SEC) is the third party providing authentication and = revocation.

Also, in a client/server model, I am not sure if the client's raw publi= c key can be verified with DNS(SEC). Does a client normally have a DNS entr= y, e.g. a name that can be looked up through DNS? In TLS, the client provid= es its complete certificate chain, which is for the server to verify. Part = of this verification normally is revocation checking, e.g. through OCSP or = CRL lists. Does that mean that when using DNS(SEC) as the out-of-band authe= ntication mechanism of the raw public key, each client needs to be register= ed with the DNS(SEC)?

<quote>
OCSP was only needed before because there were three part= ies. While it
is still possible an out of band method to validate TLS keys to require
three parties, any revocation list mechanism should be part of the out
of band method specification. I am not sure what out of band method this OCSP-lite case covers. If there is a specification of that out of band
method, then that specification should perhaps include this OCSP-lite
specification as part of it.
</quote>

Indeed that is the idea. The OCSP-lite is an out-of-band method for authent= ication of the raw public key in itself. The advantage of the OCSP-lite app= roach is that it does not need DNS(SEC) to establish secure communication. = This may especially be useful for endpoints that do not have a domain name,= and are directly identified by their IP address. Goal of OCSP-lite is to k= eep verification for the client as easy as possible, i.e. put most of the b= urden on the OCSP-lite responder.

What do you think?

Best regards,
Bert


-----Original Message-----
From: Paul Wouters [mailto:paul@nohats.ca]
Sent: 2013=E5=B9=B44=E6=9C=8823=E6=97=A5 21:28
To: Bert Greevenbosch
Cc: Salz, Rich; Sean Turner; tls@ietf.org
Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD= review of draft-ietf-tls-oob-pubkey)

On Tue, 23 Apr 2013, Bert Greevenbosch wrote:

> I think name-to-key association is half of the problem, whereas revoca= tion is the second half. SSH seems to focus on the first half, whereas OCSP= -lite focuses mainly on the second half.

Revocation is only required in the indirect path. That is, supplier A
signs something for consumer B, and enduser C needs to verify B. Now A
needs a method to tell C about revocation of B.

When you use raw public keys, the authentication happens out of band. If there are no three players, with two of them talking only indirectly,
no OCSP-like mechanism is required.

For instance, using DNS(SEC) with raw keys there is only B and C. When
B loses trust in their key, they simple remove it from DNS(SEC) to
communicate this to A. The same applies to SSHFP records in DNS(SEC)
or ActiveDirectory.

OCSP was only needed before because there were three parties. While it
is still possible an out of band method to validate TLS keys to require
three parties, any revocation list mechanism should be part of the out
of band method specification. I am not sure what out of band method this OCSP-lite case covers. If there is a specification of that out of band
method, then that specification should perhaps include this OCSP-lite
specification as part of it.

I don't see a value of specifying a generic revocation method. I see danger in such a specification if it _introduces_ a third player where
there should not be one for a specific out of band authentication
method.

Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can
tune the behaviour of when TLS raw keys are valid or not. No OCSP variant is neccessary. The same is true for content based on ActiveDirectory/LDAP or Radius/Diameter where there is already a central control mechanism
for relaying this information.

Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7b342d2872c53d04db39e2cc-- From ben@digicert.com Fri Apr 26 08:38:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AD621F98FC; Fri, 26 Apr 2013 08:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg-ELC2Fa4aG; Fri, 26 Apr 2013 08:38:16 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id B925421F9878; Fri, 26 Apr 2013 08:38:16 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 3339B8FA06F; Fri, 26 Apr 2013 09:38:16 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1366990696; bh=tktCkSB986hr4t9RLfaDq4ZSOz9UgPB7tguKsZKI9BA=; h=Reply-To:From:To:Subject:Date; b=aB2VywHusVTstChXgC3yILIzlF+hj8+/uA9kdIbxXL/IYSf31XyF/yPCR9kmqWDth +Q0nN79XC4nyVbCNpsq8vkxph5coYesnmVgFDjHQQ978s0Ax6tRBf+ooNtstpSwcdx KLPH+X8UkRosKOdkhtnNsVuOPzqWMscEohDqZFZc= From: "Ben Wilson" To: , "'wpkops WG'" Date: Fri, 26 Apr 2013 09:38:14 -0600 Organization: DigiCert Message-ID: <013e01ce4294$11167300$33435900$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01CE4261.C67C5120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5Ck77q3fI6OmsYRlKmrR2GROPpyA== Content-Language: en-us Subject: [TLS] Implementations of OCSP Stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:38:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01CE4261.C67C5120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Excuse the cross-posting, but if you know of anyone currently implementing OCSP stapling, could you send me their contact information off-list? Thanks in advance, Ben ------=_NextPart_000_013F_01CE4261.C67C5120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Excuse the = cross-posting, but if you know of anyone currently implementing OCSP = stapling, could you send me their contact information = off-list?

Thanks in = advance,

Ben

------=_NextPart_000_013F_01CE4261.C67C5120-- From hammondjohnson@hushmail.com Sat Apr 27 14:08:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6021F826B for ; Sat, 27 Apr 2013 14:08: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbkG+q0oh4B8 for ; Sat, 27 Apr 2013 14:08:43 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED5D21F8414 for ; Sat, 27 Apr 2013 14:08:23 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 79F83E7D52 for ; Sat, 27 Apr 2013 17:52:31 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:52:31 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 44975E6736; Sat, 27 Apr 2013 17:52:31 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:52:31 -0400 To: tls@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175231.44975E6736@smtp.hushmail.com> Subject: [TLS] Biggest Fake Conference in Computer Science X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:08:44 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From dsun218@gmail.com Mon Apr 22 18:57:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6088411E80F2 for ; Mon, 22 Apr 2013 18:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBCZNh5DUgIY for ; Mon, 22 Apr 2013 18:57:32 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3611E80F1 for ; Mon, 22 Apr 2013 18:57:31 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so113539vcb.33 for ; Mon, 22 Apr 2013 18:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Ao7+/5JK52hD1cKkbijJxfkRtpQnCqH/k9YZdWvqiYQ=; b=ApLSXojPx+eXNzZ08z12j4gCnHvG95MJpE5fM7FoMIx7UQQUzkwXN4bvZJgaPEB/I5 04aRcL5GaYfb02evbQZzmDkQeaXBLT0xmxWUDjFBpv9uNHmuBNzL1h9NQObLlFG/5VB8 U5YlcHMat+siZkh8TksqAgP458rYf38wkQE9IZD7VkKQmAX5x9PhfsAtHJymRYCYVI9/ ddaH3Hg5+HBc0/9ondI1WMKL+V7vLtf07jUE5QJIX9UVpQ6f7nUIWNu7Qk6MikVVC0Oz 35hHIZjdc5FXgL86Irc3eAZQhum72lbJNldRnT+DEEVSeujuVofrJhC9C5mgQ3wMZp0e EINg== MIME-Version: 1.0 X-Received: by 10.52.76.103 with SMTP id j7mr18079687vdw.90.1366682251402; Mon, 22 Apr 2013 18:57:31 -0700 (PDT) Received: by 10.52.21.115 with HTTP; Mon, 22 Apr 2013 18:57:31 -0700 (PDT) Date: Mon, 22 Apr 2013 21:57:31 -0400 Message-ID: From: Dan Sun To: tls@ietf.org Content-Type: multipart/alternative; boundary=bcaec50162331ecc5404dafd8287 X-Mailman-Approved-At: Mon, 29 Apr 2013 22:18:52 -0700 Subject: [TLS] HTTPS vs HTTP Data Increase X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 02:44:27 -0000 --bcaec50162331ecc5404dafd8287 Content-Type: text/plain; charset=ISO-8859-1 Hello, As more and more applications being migrated over TLS, besides encoding /decoding cost and additional RTT on the network, I am wondering how much additional byte are created roughly by encrypting the clear text over TLS compared to HTTP? There must be some work already done from this angle but hardly to find it on the web. Could you share some good references or white papers for this KPI? Sorry to bother you in this mail list. But this is where the most expertise is. Appreciate your help! Dan --bcaec50162331ecc5404dafd8287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

As more and more applications being migrated over TLS, besides encoding /de= coding cost and additional RTT on the network, I am wondering how much addi= tional byte are created roughly by encrypting the clear text over TLS compa= red to HTTP?

There must be some work already done from this ang= le but hardly to find it on the web. Could you share some good references o= r white papers for this KPI?

Sorry to bother you in this mail list. But this is= where the most expertise is.

Appreciate your hel= p!

Dan

--bcaec50162331ecc5404dafd8287-- From jreddy@ti.com Wed Apr 24 15:54:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326D321F914C for ; Wed, 24 Apr 2013 15:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZCCZJGWTsnA for ; Wed, 24 Apr 2013 15:54:45 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31621F8550 for ; Wed, 24 Apr 2013 15:54:43 -0700 (PDT) Received: from dflxv15.itg.ti.com ([128.247.5.124]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id r3OMsgHM001528 for ; Wed, 24 Apr 2013 17:54:42 -0500 Received: from DLEE71.ent.ti.com (dlee71.ent.ti.com [157.170.170.114]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id r3OMsgod022764 for ; Wed, 24 Apr 2013 17:54:42 -0500 Received: from DLEE09.ent.ti.com ([fe80::d03e:3cf4:73ad:d589]) by DLEE71.ent.ti.com ([fe80::4dce:5c82:1ad0:d462%28]) with mapi id 14.02.0342.003; Wed, 24 Apr 2013 17:54:42 -0500 From: "Reddy, Joseph" To: "tls@ietf.org" Thread-Topic: [TLS] draft-mcgrew-tls-aes-ccm-ecc Thread-Index: Ac5BPqQrnFBC367YR4KC1ktcuwMgEQ== Date: Wed, 24 Apr 2013 22:54:41 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CBA5851@DLEE09.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: multipart/alternative; boundary="_000_2AA5AC69E924D149A8D63EB676AF87DB2CBA5851DLEE09entticom_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 29 Apr 2013 22:18:52 -0700 Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:54:49 -0000 --_000_2AA5AC69E924D149A8D63EB676AF87DB2CBA5851DLEE09entticom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 -Regards, Joseph Hi Sean, I too agree with the comments provided by Paul Hoffman, Russ, David and Pau= l Duffy and also feel the conservative MTI curves specified in the draft pr= omote interoperability. Robert On 24/04/2013 06:23, Paul Duffy wrote: Hi Sean I agree with the comments offered by Paul, Russ, and David. FYI, whatever normative dependency exists between CoAP and this draft, seve= ral efforts of the Zigbee Alliance also have normative references to this d= raft (Zigbee IP and Smart Energy Profile 2). The draft was triggered by SEP= 2's extensive vetting for an ECC standard for LLNs. The Zigbee products are= undergoing certification and initial deployments are expected to begin thi= s year. Cheers On 4/23/2013 5:05 PM, Russ Housley wrote: Sean: I do not think this out to include the MTI curve. I would greatly prefer th= at COAP make use of one of the curves that is already specified. I think a = strong reason is needed to specify more curves; the specification of too ma= ny will reduce interoperability. Russ On Apr 23, 2013, at 1:16 PM, Sean Turner wrote: Hi, I've been asked to shepherd this document. It's a normative reference for t= he core COAP WG specification. My question is whether this draft should include an MTI curve or whether th= at should be left up to the application. I ask because no other EC TLS ciph= er suite picks a curve. spt _______________________________________________ TLS mailing list TLS at ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS at ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_2AA5AC69E924D149A8D63EB676AF87DB2CBA5851DLEE09entticom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
+1
 
-Regards, Joseph
 
 
 
 
= Hi Sean,
=  
= I too agree with the comments provided by Paul Hoffman, Russ, David and Pau= l Duffy and also feel the conservative MTI curves specified in the draft pr= omote interoperability.
=  
= Robert
=  
= On 24/04/2013 06:23, Paul Duffy wrote:
= Hi Sean
=  
= I agree with the comments offered by Paul, Russ, and David.
=  
= FYI, whatever normative dependency exists between CoAP and this draft, seve= ral efforts of the Zigbee Alliance also have normative references to this d= raft (Zigbee IP and Smart Energy Profile 2). The draft was triggered by SEP2's extensive vetting for an ECC standard= for LLNs. The Zigbee products are undergoing certification and initial dep= loyments are expected to begin this year.
=  
= Cheers
=  
=  
=  
= On 4/23/2013 5:05 PM, Russ Housley wrote:
= Sean:
=  
= I do not think this out to include the MTI curve. I would greatly prefer th= at COAP make use of one of the curves that is already specified. I think a = strong reason is needed to specify more curves; the specification of too many will reduce interoperability. =
=  
= Russ
=  
=  
= On Apr 23, 2013, at 1:16 PM, Sean Turner wrote:
=  
= Hi,
=  
= I've been asked to shepherd this document. It's a normative reference for t= he core COAP WG specification.
=  
= My question is whether this draft should include an MTI curve or whether th= at should be left up to the application. I ask because no other EC TLS ciph= er suite picks a curve.
=  
= spt
= _______________________________________________
= TLS mailing list
= TLS at ietf.org
= = https://www.ietf.org/mailman/listinfo/tls
=  
=  
= _______________________________________________
= TLS mailing list
= TLS at ietf.org
= = https://www.ietf.org/mailman/listinfo/tls
=  
=  
=  
 
 
 --_000_2AA5AC69E924D149A8D63EB676AF87DB2CBA5851DLEE09entticom_-- From n.mavrogiannopoulos@gmail.com Tue Apr 30 06:12:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075AD21F9B4C for ; Tue, 30 Apr 2013 06:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qycNcf5p1dZO for ; Tue, 30 Apr 2013 06:12:02 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1821F9B61 for ; Tue, 30 Apr 2013 06:12:01 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id bn16so1552407qab.20 for ; Tue, 30 Apr 2013 06:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mnIeUw7jXNmgx9lvktxJs3nw+2GtQpASaGrqKTwDZVU=; b=kCiDLHYLd/T5Z/Ral/8pI++qITzA1mkzcQNpDQeBnnFlBJkDU0CMEPGDzkvY7uIeOn pH/5jnBRnRPmTeWD0jh00Xc9WW85DVWnVpHJ+D4HGKBZNVliHrBhDBYOxatuXPJ4RU13 1vtxCYlvUWe76a2MgQK8nMCIgfsbmR8lCRQ8LYJlv84aX2qRbNDUnBZInCIY5lB4E0IC LA6C9L2fvwKsVpvN9P46NTklH1qBKAw8FXK5q5qQTipwhKwsjccQbAevNle0KBnMS5/+ JgDp7YWJ5v5BLWh/XJvjuDCdVG1lM4xMubMTVJqwvXQmuRS9TQP70Cl8QYg86qr17v1o e+Xw== MIME-Version: 1.0 X-Received: by 10.49.81.200 with SMTP id c8mr67271543qey.50.1367327520511; Tue, 30 Apr 2013 06:12:00 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.117.16 with HTTP; Tue, 30 Apr 2013 06:12:00 -0700 (PDT) In-Reply-To: <5176C1F6.4040806@ieca.com> References: <5176C1F6.4040806@ieca.com> Date: Tue, 30 Apr 2013 16:12:00 +0300 X-Google-Sender-Auth: HLdXQ60BtuSWguyJ7shv4PILPZg Message-ID: From: Nikos Mavrogiannopoulos To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:12:03 -0000 On Tue, Apr 23, 2013 at 8:16 PM, Sean Turner wrote: > Hi, > I've been asked to shepherd this document. It's a normative reference for > the core COAP WG specification. > My question is whether this draft should include an MTI curve or whether > that should be left up to the application. I ask because no other EC TLS > cipher suite picks a curve. Having a standard curve one can rely on promotes interoperability, but that cannot be easily done on a single ciphersuite. That is because this mandatory curve applies to the certificate as well, and it is often not feasible to require multiple certificates for each ciphersuite (assuming another ciphersuite will define a different set of mandatory curves). For that it could be more useful if the suggested curves were published as an update to RFC4492. As such I am not in favor for this specific ciphersuite to select a mandatory curve, but rather to define a smaller set of mandatory curves that apply for all TLS ciphersuites. regards, Nikos From Jeff.Hodges@KingsMountain.com Tue Apr 30 14:05:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6421F8D8E for ; Tue, 30 Apr 2013 14:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.646 X-Spam-Level: X-Spam-Status: No, score=-101.646 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLtExxtX0WhD for ; Tue, 30 Apr 2013 14:05:09 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 0CC8121F98F7 for ; Tue, 30 Apr 2013 14:02:20 -0700 (PDT) Received: (qmail 25932 invoked by uid 0); 30 Apr 2013 21:01:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 30 Apr 2013 21:01:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=K31rSaYO81+LypTAjx3z1Pc6oN3gmEKfKasGa8FHkZ8=; b=29Gk8V4pgoqE1KhuYKy133zbeSpBrpEdg8SvSs2fAa7Yjo8L9y6msxJSmHkngBYuACkJ75jklHpYAfq0lHos912orKl0bDMb2F4nbZsdIhCamdBEnX+w1vgvE0TlJk82; Received: from [216.113.168.128] (port=9619 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXHgR-00010z-NT; Tue, 30 Apr 2013 15:01:55 -0600 Message-ID: <51803144.5040206@KingsMountain.com> Date: Tue, 30 Apr 2013 14:01:56 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF TLS WG Subject: Re: [TLS] whither draft-agl-tls-nextprotoneg? EncryptedExtensions? (was: Update on Origin-Bound Certificates: Now called "Channel ID") X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 21:05:15 -0000 AGL replied.. > On Sun, Nov 11, 2012 at 8:30 PM, Paul Hoffman wrote: >> >> Is is possible for you to do a separate Internet-Draft on >> EncryptedExtensions, and then point to it from draft-balfanz-tls-channelid? >> I ask because there are probably other future extensions that will want to >> use that extension... > > EncryptedExtensions is also used in the NPN. I'd be happy to split it off if > the WG were to adopt something that required it. So whither draft-agl-tls-nextprotoneg (in light of draft-ietf-tls-applayerprotoneg)? Informational? After perusing both draft-agl-tls-nextprotoneg and draft-balfanz-tls-channelid, I tend to agree with PaulH that EncryptedExtensions ought to be a stand-alone spec that is referenced by TLS extension specs as needed. HTH, =JeffH From alangley@gmail.com Tue Apr 30 14:08:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6270021F85C3 for ; Tue, 30 Apr 2013 14:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMEvf6rIupIJ for ; Tue, 30 Apr 2013 14:08:09 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id CA04421F93C6 for ; Tue, 30 Apr 2013 14:06:24 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id t11so939732lbd.5 for ; Tue, 30 Apr 2013 14:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6kEV2NY0Teu47eOpzEKGjcf9qaqgnsZTfqrk+Dt0kKk=; b=1JSgx6rbPUk1f6T5p0SlpuIemVihks/skIW5Y9BiO/nbjqxAINydPH27nTKYvnbrbQ wiXOwRKXqYH4PgeduNZaarmqtWj8dGqiwp08aQ+/Q090tmo6IdPn5atoav1fmqtI3BPu YtSTb09mp/KNS1QcRIvXnfr7B7feVpslX/nHKmv1qg6+pAZXmtXvsHmx4zdmM26fkKYm 15tpaKxSbikMjPi4+tp/NadH5RMPXGUFhwlgPimaJ4FZgqas8V+g0xVYKpdDZFNPf42n yM8OHvJfzus/bBnsAxWpPnW0mbUC8asoQsf1YELNvhuJXDVwPQGLAHDIPReYCJtpCpHJ Kbkw== MIME-Version: 1.0 X-Received: by 10.112.155.202 with SMTP id vy10mr251754lbb.51.1367355938669; Tue, 30 Apr 2013 14:05:38 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.201.133 with HTTP; Tue, 30 Apr 2013 14:05:38 -0700 (PDT) In-Reply-To: <51803144.5040206@KingsMountain.com> References: <51803144.5040206@KingsMountain.com> Date: Tue, 30 Apr 2013 17:05:38 -0400 X-Google-Sender-Auth: H5H3Afz0HDpe0ZDz4Z5qXUO7MEw Message-ID: From: Adam Langley To: "=JeffH" Content-Type: text/plain; charset=UTF-8 Cc: IETF TLS WG Subject: Re: [TLS] whither draft-agl-tls-nextprotoneg? EncryptedExtensions? (was: Update on Origin-Bound Certificates: Now called "Channel ID") X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 21:08:14 -0000 On Tue, Apr 30, 2013 at 5:01 PM, =JeffH wrote: > After perusing both draft-agl-tls-nextprotoneg and > draft-balfanz-tls-channelid, > I tend to agree with PaulH that EncryptedExtensions ought to be a > stand-alone spec that is referenced by TLS extension specs as needed. I think the feeling at Orlando was that people didn't want to do EncryptedExtensions. Rather they wanted something more general. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From Jeff.Hodges@KingsMountain.com Tue Apr 30 14:29:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3F21F9AF1 for ; Tue, 30 Apr 2013 14:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.646 X-Spam-Level: X-Spam-Status: No, score=-101.646 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UerLdtTzxFHj for ; Tue, 30 Apr 2013 14:29:40 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 2318E21F9AD3 for ; Tue, 30 Apr 2013 14:29:21 -0700 (PDT) Received: (qmail 30425 invoked by uid 0); 30 Apr 2013 21:28:12 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy13.unifiedlayer.com with SMTP; 30 Apr 2013 21:28:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=RDpQFY9JLJgMkgt0CCfhPkEZ6F9uVBX4nDQfzOnUgVo=; b=GVCFWFxydixxpmN3amIhDAD6UsblnEichfmdqdbKGj9aUeGqx9tkae//mBLMcsIJvoT4rgMAKv2H15ZEvxqzijlrfKz590z11XTNK3u44Y70SEO2qo7KalwB7qTBILxQ; Received: from [216.113.168.128] (port=45560 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXI5r-0007jL-US; Tue, 30 Apr 2013 15:28:11 -0600 Message-ID: <5180376E.5010501@KingsMountain.com> Date: Tue, 30 Apr 2013 14:28:14 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF TLS WG Subject: Re: [TLS] whither draft-agl-tls-nextprotoneg? EncryptedExtensions? (was: Update on Origin-Bound Certificates: Now called "Channel ID") X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 21:29:45 -0000 AGL replied.. > On Tue, Apr 30, 2013 at 5:01 PM, =JeffH wrote: >> After perusing both draft-agl-tls-nextprotoneg and >> draft-balfanz-tls-channelid, >> I tend to agree with PaulH that EncryptedExtensions ought to be a >> stand-alone spec that is referenced by TLS extension specs as needed. > > I think the feeling at Orlando was that people didn't want to do > EncryptedExtensions. Rather they wanted something more general. hm, i had the impression during that discussion that the overall concern was with having (specifically) next-proto-negotiation in the clear, rather than objections to EncryptedExtensions per se. =JeffH From Jeff.Hodges@KingsMountain.com Tue Apr 30 17:11:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FB921F8605 for ; Tue, 30 Apr 2013 17:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.646 X-Spam-Level: X-Spam-Status: No, score=-101.646 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRVq5-IQ0Y7M for ; Tue, 30 Apr 2013 17:11:41 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 962CD21F85F4 for ; Tue, 30 Apr 2013 17:11:41 -0700 (PDT) Received: (qmail 28386 invoked by uid 0); 1 May 2013 00:11:19 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 1 May 2013 00:11:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+0ZBT7YEs+yiSF7lCzJJFfveRkO2l8lPxzqU+GG4hkY=; b=A1q0K56nzcF+p1rsKdAl7dG+WvNgj/CY++rdE0rwIN2/6IywpAkc9wSgxCdkA2hxOIvmUeQ2A2W9P0k0DCxnAoyw6reIIkZaALsN6hY658ey8050+m8D/92itIuBrzew; Received: from [216.113.168.128] (port=53630 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXKdj-0000P7-3g; Tue, 30 Apr 2013 18:11:19 -0600 Message-ID: <51805DA9.8000606@KingsMountain.com> Date: Tue, 30 Apr 2013 17:11:21 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF TLS WG Subject: [TLS] comments on draft-balfanz-tls-channelid X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 00:11:47 -0000 [ for best results use a fixed-pitch font ] Here's some comments on draft-balfanz-tls-channelid, I hope they're helpful. =JeffH ------ High-level comments: 1. EncryptedExtensions modification to the TLS handshake ought to be split out into a separate spec. 2. What are the ramifications if the TLS WG does not adopt an EncryptedExtensions mechanism? I.e., what are the downsides to the "channel id" being publicly exposed, i.e., the security ones as well as the privacy implications? 3. In my view, this spec defines how a TLS client generates and subsequently wields a unique client identifier/key with a particular TLS server over multiple TLS connections (in parallel and serially). Thus it is more about creating a "security association" between the client and server (eg, see definitions for the latter, as well as "channel", in RFC4949). Thus I would not use the term "channel" for this mechanism. Also, TLS unto itself is creating a cryptographic channel between client and server and thus using the channel term for this mech seems ripe for confusion. This comment implies some re-writing of the introduction (I've made some modest suggestions below). Perhaps "TLS Security Association ID" (TLS-SAIDs) ? 4. The lifecycle for the unique client identifier (aka "channel id") ought to be more fully discussed/specified in main portion of the spec. Presently it's sprinkled in the introduction and the privacy considerations. 5. There would seem to be considerations for applications in terms of reliance on the persistence of a given "channel id" and provisions for the "channel id" changing or disappearing, e.g. if an app leverages "channel id" to bind long-lived app-layer objects (eg cookies) to the TLS client, and these implications/issues should be discussed. 6. This mechanism should be compared/contrasted with TLS Channel Binding RFC5929. They don't appear to be mutually exclusive on first thought. What are the semantics if they are both employed by an application? For what might one employ one or the other or both concurrently? 7. This is a "trust on first use (TOFU)" mechanism. This should be mentioned/discussed explicitly. Detailed comments/questions: > Network Working Group D. Balfanz > Internet-Draft R. Hamilton > Expires: May 12, 2013 Google Inc > November 8, 2012 > > > Transport Layer Security (TLS) Channel IDs > draft-balfanz-tls-channelid-00 > > Abstract > > This document describes a Transport Layer Security (TLS) extension > for identifying client machines at the TLS layer without using bearer > tokens. > snip > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Why not client certificates . . . . . . . . . . . . . . . . . 4 > 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 > 4. Channel ID Extension . . . . . . . . . . . . . . . . . . . . . 6 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 > 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 > snip > > 1. Introduction > > Many applications on the Internet use _bearer tokens_ to authenticate > clients to servers. The most prominent example is the HTTP-based > World Wide Web, which overwhelmingly uses HTTP cookies to > authenticate client requests. Other examples include OpenID or SAML > assertions, and OAuth tokens. All these have in common that the > _bearer_ of the HTTP cookie or authentication token is granted access > to a protected resource, regardless of the channel over which the > token is presented, or who presented it. > > As a result, an adversary that manages to steal a bearer token from a > client can impersonate that client to services that require the > token. > > This document describes a light-weight mechanism for establishing a > _cryptographic channel_ between client and server. ^^^^^^^ ^ security association , denoted by an ECC public key. > A server can ^ For example, > choose to bind authentication tokens to this channel, thus rendering ^^^^^^^ association > the theft of authentication tokens fruitless - tokens must be sent > over the channel to which they are bound (i.e., by the client to > which they were issued) or else they will be ignored. suggest.. ..tokens bound to the security association will be ignored by the if they are not sent by the legitimate client. > > This document does not prescribe _how_ authentication tokens are > bound to the underlying channel. Rather, it prescribes how a client > can establish a long-lived channel with a server. ^^^^^^^ security association > Such a channel ^^^^^^^^^ an association > persists across HTTP requests, TLS connections, and even multiple TLS > sessions, as long as the same client communicates with the same > server. > > The basic idea is that the client proves, during the TLS handshake, > possession of a private key. The corresponding public key becomes > the "Channel ID" that identifies this TLS connection. Clients should > re-use the same private/public key pair across subsequent TLS > connections to the same server, thus creating TLS connections that > share the same Channel ID. > > Using private/public key pairs to define a channel (as opposed to, > say, an HTTP session cookie) has several advantages: One, the > credential establishing the channel (the private key) is never sent > from client to server, thus removing it from the reach of > eavesdroppers in the network. Two, clients can choose to implement > cryptographic operations in a secure hardware module, which further > removes the private key from the reach of eavesdroppers residing on > the client itself. > snip > > 2. Why not client certificates > > TLS already supports a means of identifying clients without using > bearer tokens: client certificates. However, a number of problems > with using client certificates motivated the development of an > alternative. > > Most importantly, it's not acceptable for a client identifier to be what are the threats if a long-term, asymmetric-key-based client identifier is sent in the clear during TLS handshake? Is it mostly a privacy concern? Or is it because of anticipated use cases of binding app-layer info to the TLS layer? > transmitted in the clear and client certificates in TLS are sent > unencrypted. Although we could also define a change to the TLS state > machine to move the client certificates under encryption, such > changes eliminate most of the benefits of reusing something that's > already defined. > > TLS client certificates are also defined to be part of the session > state. This turns session resumption secrets into equivalent barer ^^^^^ bearer > tokens; completely defeating our objectives. I'm curious here... RFC5246 Appendix F.1.4. indicates.. When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC keys are secure, the connection should be secure and effectively independent from previous connections. ..so I'm not sure how "session resumption secrets" are "equivalent bearer tokens" ? > > Client-certificates typically identify a user, while we seek to > identify machines. Since they are not, conceptually, mutually > exclusive and as only a single client certificate can be provided in > TLS, we don't want to consume that single slot and eliminate the > possibility of also using existing client certificates. > > Client certificates are implemented in TLS as X.509 certificates and > we don't wish to require servers to parse arbitrary ASN.1. ASN.1 is > a complex encoding that has been the source of several security > vulnerabilities in the past and typical TLS servers can currently > avoid doing ASN.1 parsing. > > X.509 certificates always include a signature, which would be a self- > signature in this case. Calculating and transmitting the self- > signature is a waste of computation and network traffic in our use. > Although we could define a null signature algorithm with an empty > signature, such deviations from X.509 eliminate many of the benefits > of reusing something that is already implemented. > > Finally, client certificates trigger significant server-side > processing by default and often need to be stored in their entirety > for the duration of the connection. Since this design is intended to > be widely used, it allows servers to retain only a cryptographic hash > of the client's public key after the handshake completes. > snip > > 4. Channel ID Extension > > A new extension type ("channel_id(TBD)") is defined and MAY be > included by the client in its "ClientHello" message. If, and only > if, the server sees this extension in the "ClientHello", it MAY > choose to echo the extension in its "ServerHello". In both cases, > the "extension_data" field MUST be empty. > > enum { > channel_id(TBD), (65535) > } ExtensionType; > > A new handshake message type ("encrypted_extensions(TBD)") is > defined. If the server included a "channel_id" extension in its > "ServerHello" message, the client MUST verify that the selected > cipher suite is sufficiently strong. If the cipher suite provides < > 80-bits of security, the client MUST abort the handshake with a fatal > "illegal_parameter" alert. Otherwise, the client MUST send an > "EncryptedExtensions" message after its "ChangeCipherSpec" and before > its "Finished" message. > > enum { > encrypted_extensions(TBD), (65535) > } HandshakeType; > > Therefore a full handshake with "EncryptedExtensions" has the > following flow (contrast with section 7.3 of RFC 5246 [RFC5246]): > > Client Server > > ClientHello (ChannelID extension) --------> > ServerHello > (ChannelID extension) > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > EncryptedExtensions > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > An abbreviated handshake with "EncryptedExtensions" has the following > > > > Balfanz & Hamilton Expires May 12, 2013 [Page 6] > > Internet-Draft TLS Channel ID November 2012 > > > flow: > > Client Server > > ClientHello (ChannelID extension) --------> > ServerHello > (ChannelID extension) > [ChangeCipherSpec] > <-------- Finished > [ChangeCipherSpec] > EncryptedExtensions > Finished --------> > Application Data <-------> Application Data > > The "EncryptedExtensions" message contains a series of "Extension" > structures (see section 7.4.1.4 of RFC 5246 [RFC5246] the below should be separate section... > If the server included a "channel_id" extension in its "ServerHello" > message, the client MUST include an "Extension" with "extension_type" suggest.. ..the client MUST include, within the EncryptedExtensions message, an "Extension" with "extension_type"... > equal to "channel_id(TBD)". The "extension_data" of which has the > following format: > > struct { > opaque x[32]; > opaque y[32]; > opaque r[32]; > opaque s[32]; > } ChannelIDExtension; > > The contents of each of "x", "y", "r" and "s" is a 32-byte, big- > endian number. The "x" and "y" fields contain the affine coordinates > of a P-256 [DSS] curve point. you mean that the "x" and "y" fields (of the ChannelIDExtension struct) contain the affine coordinates of a P-256 [DSS] curve point comprising an ECC public key "Q" ? [ where Q = dG, d = ECC private key, G is the curve base point, and other elliptic curve "domain parameters" are as given in [DSS] for curve P-256, and the key pair is generated according to appendix B.4 in [DSS] aka FIPS-186-3 ? ] So Q = (x,y) is the "channel id" per se ? It should be made explicit. What's the lifecycle management of this identifier (ie "Q")? Is the TLS server (or the server-side app running on top of it) to remember this identifier? Is it to be mapped to other client-side identifying information eg IP address, user data (eg account name), etc ? Even though this I-D is just specifying the identifier and proof-of-possession mechanism (aka "holder of key"), some modest discussion of example use cases (beyond the mention of binding to "authentication tokens" that appears in the Introduction) would be helpful. Presumably the TLS client stores this identifier keyed by TLS server domain name and re-uses it in future TLS connections to that server (the "storage model" needs to be discussed/specified)? When might a TLS client change an established identifier? (Some mention of these lifecycle items is given in the PrivCons section below) Is it to be remembered on first use? Is it to be updated in the server-side store upon it changing? What are this identifier's overall semantics? > The "r" and "s" fields contain an > ECDSA [DSS] signature by the corresponding private key of "TLS > Channel ID signature\x00" suggest.. The "r" and "s" fields contain an ECDSA [DSS] signature by the corresponding private key over this US-ASCII string (not including quotes, and where "\x00" represents an octet containing all zero bits): "TLS Channel ID signature\x00" ..although we should probably use ABNF (or the RFC5246 notation) to define this string and its concatenation with the handshake message hashes. > followed by the handshake hash(es) prior to > the "EncryptedExtensions" message. hashes of both the client-sent and server-sent handshake messages, as seen by the client? > > Unlike many other TLS extensions, this extension does not establish > properties of the session, only of the connection. When session > resumption or session tickets [RFC5077] are used, the previous > contents of this extension are irrelevant and only the values in the > new handshake messages are considered. but presumably the same (long-lived?) TLS client identifier Q = (x,y) used and only (r,s) are different ? Or are new values for all of {x,y,r,s} calculated? [ "no" is implied by the Introduction and Priv. Cons. ] > 5. Security Considerations > > There are four classes of attackers against which we consider our > security guarantees: passive network attackers, active network > attackers, active network attackers with misissued certificates and > attackers in possession of the legitimate server's private key. > > First, we wish to guarantee that we don't disclose the Channel ID to > passive or active network attackers. why? simply for privacy reasons? Or is the main concern that the "channel id" will be used by app layers, eg in HTTP cookies, in order to bind objects to a particular TLS client-server pair, and thus the "channel id" should be protected as a secret? If the "channel id" is simply included in cookies, and those cookies are leaked in the clear (which is not uncommon for a variety of reasons), then the "channel id" will potentially be divulged in any case. Since the channel id is a public key, the server could include some nonce, encrypted by the channel id key, in messages to the client, the client could decrypt it, then encrypt the nonce with its private key, and include that on messages back to the server, which the server could decrypt with the client's public key and verify. doing something like that could help keep the channel id itself out of these messages and their potentially leaky components (such as cookies) if servers who rely upon the Channel ID always do so with a corresponding proof-of-possession of the private key on the part of the TLS client (and they perform the requisite checks), then what are the security (as opposed to privacy) issues if the Channel ID is observable by others? I suppose it depends on the app-layer use cases employing the "channel id". > We do this by sending a > constant-length Channel ID under encryption. However, since the > Channel ID may be transmitted before the server's Finished message is > received, it's possible that the server isn't in possession of the > certificate that it presented. do you mean in possession of the corresponding private key (to the cert it presented) ? > In this situation, an active attacker > could cause a Channel ID to be transmitted under a random key in a > cipher suite of their choosing. Therefore we limit the permissible > cipher suites to those where decrypting the message is infeasible. these TLS cipher suites should be explicitly listed. > > Even with this limit, an active attacker can cause the Channel ID to > be transmitted in a non-forward-secure manner. Subsequent disclosure > of the server's private key would allow previously recorded Channel ^ legitimate > IDs to be decrypted. > > Second, we wish to guarantee that none of the first three attackers > can terminate/hijack a TLS connection and impersonate a Channel ID > from that connection when connecting to the legitimate server. We > assume that TLS provides sufficient security to prevent a connection > from being hijacked once established by these attackers. did you mean to say.. We assume that TLS provides sufficient security to prevent these attackers from being able to hijack the TLS connection. ..? > An active > attacker with a misissued certificate can successfully terminate the > TLS connection and decrypt the Channel ID. need a definition and perhaps reference for "mis-issued" cert. > However, as the signature > covers the handshake hashes, and therefore the server's certificate, > it wouldn't be accepted by the true server. this essentially means that a attacker server with a mis-issued certificate cannot act as a real-time TLS proxy between the TLS client and legit server, yes? But otherwise such an attacker could potentially mount an impersonation of the legitimate server, yes? > > Against an attacker with the legitimate server's private key we can > provide the second guarantee only if the legitimate server uses a > forward-secret cipher suite, otherwise the attacker can hijack the > connection. here "connection" means the long-lived "security association" between TLS client and legit server, yes? the known forward-secret TLS cipher suites should perhaps be listed in an appendix. > snip > > 6. Privacy Considerations > > The TLS layer does its part in protecting user privacy by > transmitting the Channel ID public key under encryption. Higher > levels of the stack must ensure that the same Channel ID is not used > with different servers in such a way as to provide a linkable > identifier. For example, a user-agent must use different Channel IDs > for communicating with different servers. There's ostensibly privacy implications worth mentioning in that each distinct TLS client stack one wields with a particular TLS server will generate a distinct "channel id" (TLS-SAID), even if they are "behind" one IP address from the server's perspective. > User-agents must also > ensure that Channel ID state can be reset by the user in the same way > as other identifiers, i.e. cookies. Yes, because otherwise this becomes a "super cookie" mech. This implies dependent app-layers will need to be able to handle dynamically changing "channel id" (TLS-SAID)s. > > However, there are some security concerns that could result in the > disclosure of a client's Channel ID to a network attacker. This is > covered in the Security Considerations section. > snip > > 7. IANA Considerations > > This document requires IANA to update its registry of TLS extensions > to assign an entry referred to here as "channel_id". > > This document also requires IANA to update its registry of TLS > handshake types to assign an entry referred to here as > "encrypted_extensions". > snip > > 8. References > > 8.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.2", RFC 5246, August 2008. > > [DSS] National Institute of Standards and Technology, "FIPS > 186-3: Digital Signature Standard". ^ Issued June, 2009 > > 8.2. Informative References > > [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, > "Transport Layer Security (TLS) Session Resumption without > Server-Side State", RFC 5077, January 2008. > > --- end