From n.mavrogiannopoulos@gmail.com Thu Dec 1 00:18:15 2011 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 61CC81F0C5C for ; Thu, 1 Dec 2011 00:18:15 -0800 (PST) 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 c3vWCo9RuS7E for ; Thu, 1 Dec 2011 00:18:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A07351F0C63 for ; Thu, 1 Dec 2011 00:18:14 -0800 (PST) Received: by eabm6 with SMTP id m6so2054442eab.31 for ; Thu, 01 Dec 2011 00:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=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=fQQyiTs/OjXvb/zUEX5Ul9XmXDSxry01sXxPmQBzlaI=; b=i66zrVo7pkr00ZWOxte2BuOTelDxCIil5KvA7zPvFpw5hBriOC6KDjfn1ExC9/y0id DwpFwLCn8TlMAbIH7VQoaLVTxrR2gje18X0rCcUKHpVaVGyIziWIz0xTFJ8PTCr0ezr7 GnYwJQ7QwbBHheRkM7QVxgdBZoDbdbMn8B1Nw= Received: by 10.213.32.3 with SMTP id a3mr368037ebd.1.1322727493780; Thu, 01 Dec 2011 00:18:13 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id 8sm15028653eei.8.2011.12.01.00.18.12 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 00:18:13 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4ED738DB.6090102@gnutls.org> Date: Thu, 01 Dec 2011 09:20:43 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: tls@ietf.org References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 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, 01 Dec 2011 08:18:15 -0000 On 11/30/2011 10:43 PM, Joe Salowey wrote: > The chairs would like to confirm the consensus of the TLS working group to adopt draft-wouters-tls-oob-pubkey-02 as a working group item. There was strong interest in this document at previous IETF meetings and the controversial options dealing with only providing public key hashes have been removed. Please respond to the following questions by December 14, 2011: > - Do you object to taking this draft on as working group item? (Please state the reason for you objection) no. > - Would you contribute time to review and provide text for the document when needed? yes. regards, Nikos From n.mavrogiannopoulos@gmail.com Thu Dec 1 00:29:50 2011 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 3604521F8B1F for ; Thu, 1 Dec 2011 00:29:50 -0800 (PST) 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 Hp+TzlChIcXb for ; Thu, 1 Dec 2011 00:29:49 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2607321F8B13 for ; Thu, 1 Dec 2011 00:29:48 -0800 (PST) Received: by eear51 with SMTP id r51so1139233eea.31 for ; Thu, 01 Dec 2011 00:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=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=yP5LEd+/vWekvOY2ykJiebfCaxwI7gQ01xwAcAE+bUY=; b=xjuKRAj3EZvMCExatRxdmGRQceitziu1MEoHLVuuF35jg5BOeyyM1SVbBuZlVTN+/q gHwE7FUIAD/9XAqljhxXu4s1skdYLBSAaySdFo0xp/rT14J8NqVt/uS0WarhQKgq/x3G oO06KOhn/mCqSrNz/ZNBTTChPA7XsIa4787Ok= Received: by 10.180.108.47 with SMTP id hh15mr4239509wib.14.1322728186690; Thu, 01 Dec 2011 00:29:46 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id ep13sm5144733wbb.8.2011.12.01.00.29.45 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 00:29:45 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4ED73B90.80908@gnutls.org> Date: Thu, 01 Dec 2011 09:32:16 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: tls@ietf.org References: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and 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: Thu, 01 Dec 2011 08:29:50 -0000 On 11/30/2011 10:34 PM, Joe Salowey wrote: > The chairs would like to see if there is consensus in the TLS working group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc as working group items. These drafts define AES-CCM cipher suites for TLS. The Zigbee smart energy group has interest in these drafts. These drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which is a super set of AES-CCM. The authors are requesting standards track for these ciphers. Please note that there is an IPR declaration listed for draft-mcgrew-tls-aes-ccm-ecc available here: https://datatracker.ietf.org/ipr/1443/. This declaration has been updated from previous declarations. Please respond to the following by December 14, 2011 : > - Do you object to taking these drafts on as working group items? (Please state the reason for you objection) No. > - Would you contribute time to review and provide text for the documents when needed? No. > - Do you object to standards track status for these documents?(Please state the reason for you objection) I object unless a clarification is given to the question below. Given that these documents define optional ciphersuites for a small target, what is the difference of having an informational or standards track status? regards, Nikos From dharkins@lounge.org Thu Dec 1 12:02:20 2011 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 1F7DC11E80EF for ; Thu, 1 Dec 2011 12:02:20 -0800 (PST) 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 T44PfqqGW4dz for ; Thu, 1 Dec 2011 12:02:19 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7E11E8147 for ; Thu, 1 Dec 2011 12:01:27 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EDCAC20054; Thu, 1 Dec 2011 12:01:26 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 1 Dec 2011 12:01:27 -0800 (PST) Message-ID: <418f9612c158e2e611ca393bc07a4d41.squirrel@www.trepanning.net> In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> References: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> Date: Thu, 1 Dec 2011 12:01:27 -0800 (PST) From: "Dan Harkins" To: "Joe Salowey" 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] consensus on adopting draft-mcgrew-tls-aes-ccm and 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: Thu, 01 Dec 2011 20:02:20 -0000 On Wed, November 30, 2011 1:34 pm, Joe Salowey wrote: > The chairs would like to see if there is consensus in the TLS working > group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc > as working group items. These drafts define AES-CCM cipher suites for > TLS. The Zigbee smart energy group has interest in these drafts. These > drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which is a > super set of AES-CCM. The authors are requesting standards track for > these ciphers. Please note that there is an IPR declaration listed for > draft-mcgrew-tls-aes-ccm-ecc available here: > https://datatracker.ietf.org/ipr/1443/. This declaration has been updated > from previous declarations. Please respond to the following by December > 14, 2011 : > > - Do you object to taking these drafts on as working group items? (Please > state the reason for you objection) No. > - Would you contribute time to review and provide text for the documents > when needed? Yes. > - Do you object to standards track status for these documents?(Please > state the reason for you objection) I have a mild objection. There is no point in doing CCM. GCM is faster, if you're gonna implement an AEAD scheme implement GCM. If you really want a 2-pass AEAD scheme you can use RFC 5297 and you get misuse-resistance for free (basically the security of the mode does not collapse if you reuse a nonce/counter). The only group I know pushing CCM is actually pushing CCM* and, as you note, this isn't CCM*. Dan. From d.sturek@att.net Thu Dec 1 12:20:56 2011 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 88C441F0C54 for ; Thu, 1 Dec 2011 12:20:56 -0800 (PST) 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 IVBRWIiMLnRW for ; Thu, 1 Dec 2011 12:20:55 -0800 (PST) Received: from nm26-vm0.access.bullet.mail.mud.yahoo.com (nm26-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.225]) by ietfa.amsl.com (Postfix) with SMTP id 9893C1F0C48 for ; Thu, 1 Dec 2011 12:20:55 -0800 (PST) Received: from [66.94.237.200] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Dec 2011 20:20:51 -0000 Received: from [98.139.221.51] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Dec 2011 20:20:51 -0000 Received: from [127.0.0.1] by smtp104.sbc.mail.bf1.yahoo.com with NNFMP; 01 Dec 2011 20:20:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1322770850; bh=xGcDDXOAUI3+qVgEyFgcqGsZkGPP1wxuvmYFSqMjpqU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=K5+vDgvvHGcw64zRwNH7g4Fk1QOGNk7EunGC+67m8JVoLIh51UqxEstRT8sUMlFCw5rKXSLZhF3ahXQ5WlLbX3cCFN/uY+3AP9FVy3ORlUwvv6hLzxj2KGvLQOkVAkQOsDwlhHP4B4kGJ1ZAhZZDur517/aBowUfACEyGl8NS1g= X-Yahoo-Newman-Id: 892355.79670.bm@smtp104.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PX4qcbIVM1ldU.yTWsi8DkC5O54MNkvW1pTtAou9YbExuGQ oLNp.YRDUROBrAExULW15hx3RQP8i5lCFIajcikdn4K9wpNG30oeHZka3ki8 wrEEV.tIn6.0OR5SBAqacqBQecLq0svBBA7XX2lU1fp3lo.JOMiTqvVlbTml vJ7aaBcgip1cb9AESaIeY3kdKYTT7Swyork5M4XVzdVe01SIR7PQQa5HA.bb wgGL_pmB_odnKqCczT9elXeuHZFMRa1.Q8L4njtfa4GpP3hRuNIcLUH0VXfq iedo.A5uuwRTlEpF99IugElAMBni3zqZOeV8H0ToM7wsZsAIkf1Eu56cAcO2 wm1euQiKpgkySJfSGBMB._41yN1yeKNEBdjlc48cdmxTIRnP7uZobAC5YqG7 CPx4wo4BPNvEwrr.AynTKedAIjDND2Phj8LPyF8d5Xpz9dHAyMqDGA7iwbw- - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.121] (d.sturek@174.78.56.227 with login) by smtp104.sbc.mail.bf1.yahoo.com with SMTP; 01 Dec 2011 12:20:50 -0800 PST User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Thu, 01 Dec 2011 12:20:38 -0800 From: Don Sturek To: Dan Harkins , Joe Salowey Message-ID: Thread-Topic: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc In-Reply-To: <418f9612c158e2e611ca393bc07a4d41.squirrel@www.trepanning.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and 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: Thu, 01 Dec 2011 20:20:58 -0000 Hi Dan, While ZigBee does specify AES-CCM* in their *commercial* specification, I would say the general problem is that IEEE 802.15.4 (which ZigBee uses) specifies AES-CCM and nearly all silicon vendors have that (not CCM*) available. If we could somehow get those implementations to switch to GCM, I don't think we would be asking for adoption of AES-CCM. That said, for the IEEE 802.15.4 devices already manufactured and in those in the field, either we try to align the use of TLS with what is available hardware wise or else bypass the AES-CCM engine in those parts and implement GCM in software..... Don On 12/1/11 12:01 PM, "Dan Harkins" wrote: > >On Wed, November 30, 2011 1:34 pm, Joe Salowey wrote: >> The chairs would like to see if there is consensus in the TLS working >> group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc >> as working group items. These drafts define AES-CCM cipher suites for >> TLS. The Zigbee smart energy group has interest in these drafts. >>These >> drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which is >>a >> super set of AES-CCM. The authors are requesting standards track for >> these ciphers. Please note that there is an IPR declaration listed for >> draft-mcgrew-tls-aes-ccm-ecc available here: >> https://datatracker.ietf.org/ipr/1443/. This declaration has been >>updated >> from previous declarations. Please respond to the following by >>December >> 14, 2011 : >> >> - Do you object to taking these drafts on as working group items? >>(Please >> state the reason for you objection) > > No. > >> - Would you contribute time to review and provide text for the documents >> when needed? > > Yes. > >> - Do you object to standards track status for these documents?(Please >> state the reason for you objection) > > I have a mild objection. There is no point in doing CCM. GCM is faster, >if you're gonna implement an AEAD scheme implement GCM. If you really want >a 2-pass AEAD scheme you can use RFC 5297 and you get misuse-resistance >for free (basically the security of the mode does not collapse if you >reuse a nonce/counter). The only group I know pushing CCM is actually >pushing CCM* and, as you note, this isn't CCM*. > > Dan. > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From rstruik.ext@gmail.com Thu Dec 1 12:59:06 2011 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 307CD11E80A3 for ; Thu, 1 Dec 2011 12:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 Cf17K5r9yFa6 for ; Thu, 1 Dec 2011 12:59:05 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D346511E809D for ; Thu, 1 Dec 2011 12:59:04 -0800 (PST) Received: by lahj13 with SMTP id j13so1094322lah.31 for ; Thu, 01 Dec 2011 12:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=r2wADR2qr84OxGZCcsHtxDqnB9hgufiqeYVDn77xfDc=; b=uyMiwbfXGyJZXwl6eT9YY/SmOcFvA/tn/Xy7uNwR2CF+LjFAEQCTsJLHIjkgF76qUt Q1PsS8oAYx/bihMk4jO3lR8syETs3w29qTJXqTIIchqfAVxvB6cGUgsI5q/igGPHBr5p 501KYvZKsB2YNo4PHuSE8bMonQuqj5XdhkqLw= Received: by 10.152.105.211 with SMTP id go19mr5919692lab.31.1322773143821; Thu, 01 Dec 2011 12:59:03 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id ne3sm6246140lab.7.2011.12.01.12.58.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 12:59:02 -0800 (PST) Message-ID: <4ED7EA82.2080407@gmail.com> Date: Thu, 01 Dec 2011 15:58:42 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and 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: Thu, 01 Dec 2011 20:59:06 -0000 Dear colleagues: Just a short note (I will have to review the cross-referenced four or so RFCs later): 1) to my knowledge, for relatively short frames (a few times the size of the underlying block cipher), the GCM mode of operation is *not* "significantly faster" than the CCM mode of operation. 2) 802.15.4-2011 (or 802.15.4-2006 for that matter) does use the CCM* mode of operation, where the nonce format is incompatible with that specified in the RFC 5116 or the mcgrew-tls-aes-ccm draft. Given #2 above, it seems that reference to 802.15.4's use of CCM is somewhat inopportune. Moreover, from Don Sturek's note below, it seems that the Joe Salovey's note that "Zigbee smart energy group has interest in these drafts" should be taken with some grain of salt (lukewarm interest at most, so it seems [if one really wished to have had another cipher (on technical grounds???), then one missed a window of opportunity 802.15.4 TG4i issued very recently and 802.15.4 TGe just went to RevCom]). On a more detailed technical note, a) how does one assure that nonces used by different entities never clash if they use a shared key for securing network traffic? (a scenario prevalent in lots of ZigBee, RoLL, etc. scenarios). b) I am curious as to whether the design in mcgrew-tls-aes-ccm allows for reuse of keying material accross layers, so as to economize on key storage and key management overhead? (given that devices should be assumed to have intra-device open trust domain, this seems feasible. I am concerned the current draft may kill off this prospect). Based on the above, I am somewhat critical as to why this should be pushed, certainly as a standard-track document. Most of these arguments I have made before, but did not see addressed. I will provide more technical feedback later on, but prior to the suggested December 15th deadline. Best regards, Rene On 01/12/2011 3:20 PM, Don Sturek wrote: > Hi Dan, > > While ZigBee does specify AES-CCM* in their *commercial* specification, I > would say the general problem is that IEEE 802.15.4 (which ZigBee uses) > specifies AES-CCM and nearly all silicon vendors have that (not CCM*) > available. If we could somehow get those implementations to switch to > GCM, I don't think we would be asking for adoption of AES-CCM. That said, > for the IEEE 802.15.4 devices already manufactured and in those in the > field, either we try to align the use of TLS with what is available > hardware wise or else bypass the AES-CCM engine in those parts and > implement GCM in software..... > > Don > > > > > On 12/1/11 12:01 PM, "Dan Harkins" wrote: > >> On Wed, November 30, 2011 1:34 pm, Joe Salowey wrote: >>> The chairs would like to see if there is consensus in the TLS working >>> group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc >>> as working group items. These drafts define AES-CCM cipher suites for >>> TLS. The Zigbee smart energy group has interest in these drafts. >>> These >>> drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which is >>> a >>> super set of AES-CCM. The authors are requesting standards track for >>> these ciphers. Please note that there is an IPR declaration listed for >>> draft-mcgrew-tls-aes-ccm-ecc available here: >>> https://datatracker.ietf.org/ipr/1443/. This declaration has been >>> updated >>> from previous declarations. Please respond to the following by >>> December >>> 14, 2011 : >>> >>> - Do you object to taking these drafts on as working group items? >>> (Please >>> state the reason for you objection) >> No. >> >>> - Would you contribute time to review and provide text for the documents >>> when needed? >> Yes. >> >>> - Do you object to standards track status for these documents?(Please >>> state the reason for you objection) >> I have a mild objection. There is no point in doing CCM. GCM is faster, >> if you're gonna implement an AEAD scheme implement GCM. If you really want >> a 2-pass AEAD scheme you can use RFC 5297 and you get misuse-resistance >> for free (basically the security of the mode does not collapse if you >> reuse a nonce/counter). The only group I know pushing CCM is actually >> pushing CCM* and, as you note, this isn't CCM*. >> >> Dan. >> >> >> _______________________________________________ >> 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 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From i.grok@comcast.net Thu Dec 1 20:05:44 2011 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 7136A1F0C4D for ; Thu, 1 Dec 2011 20:05:44 -0800 (PST) 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 1HewPNZ1SMvP for ; Thu, 1 Dec 2011 20:05:44 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by ietfa.amsl.com (Postfix) with ESMTP id 04B501F0C3B for ; Thu, 1 Dec 2011 20:05:43 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 43Rm1i0021ZMdJ4A245dGe; Fri, 02 Dec 2011 04:05:37 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id 43w01i00R00PQ6U8c3w1xL; Fri, 02 Dec 2011 03:56:02 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id pB245fha016831 for ; Thu, 1 Dec 2011 23:05:41 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id pB245f1T016830 for tls@ietf.org; Thu, 1 Dec 2011 23:05:41 -0500 Date: Thu, 1 Dec 2011 23:05:41 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20111202040540.GA16740@odin.ulthar.us> Mail-Followup-To: tls@ietf.org References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 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, 02 Dec 2011 04:05:44 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 01:43:48PM -0800, Joe Salowey wrote: > The chairs would like to confirm the consensus of the TLS working > group to adopt draft-wouters-tls-oob-pubkey-02 as a working group > item. There was strong interest in this document at previous IETF > meetings and the controversial options dealing with only providing > public key hashes have been removed. Please respond to the following > questions by December 14, 2011: > - Do you object to taking this draft on as working group item? (Please > state the reason for you objection) no objection > - Would you contribute time to review and provide text for the > document when needed? yes --=20 Scott Schmit --+HP7ph2BbKc20aGI Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjAyMDQwNTQwWjAjBgkqhkiG9w0BCQQxFgQUIuJ60D2n REk/0B+qifLJscI3tFEweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAIgXVE2xf t6c8CDKJ4G7LRFzU4c+BRZDvN8ehvhPj463reVJFrdA8t9dXgvdKaN8RgjEL23q7DdnAduHR cZOZH+s1SKOxMlFXREoIjCaJhJuRodvR6JzKK0tTzRWLdPorvmyXZN3QYfHIB7RMnK0BM2xM b5QYkdw/EOzPn/itAiyShi2/xr6hHFPB4Tm2cGQiPqCO8pYEy3pb24aAINHYveNFuXdtj+OK A/RWpUiIID2D+j7nlSsXUesxaH8xznJ93bvXF3oV1J0Zy728q8WwfZByZp2rBbs2a7M/fYap +O/hjUrbsijFK/jaHyNDNWdUrNN6ROLQKbxx4j86wLNJpg== --+HP7ph2BbKc20aGI-- From mbadra@gmail.com Fri Dec 2 04:09:49 2011 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 57C6321F9928 for ; Fri, 2 Dec 2011 04:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 2liFNV-2+cSf for ; Fri, 2 Dec 2011 04:09:48 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8330721F9924 for ; Fri, 2 Dec 2011 04:09:48 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2521857vbb.31 for ; Fri, 02 Dec 2011 04:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c+TbY7x2nlSlAeWnaiu4veAg7Zm24McpsXfNLoH/cwI=; b=iuQ/WLkYga7jAuEQZg71dr155dT0HvFHn0w1J++u8w0GtPxRPa5ebcEmb5fVgOU3S2 zcCn0n45s3Q1962wbsA4HIBZoIb9mhlbC5pV4tzfE+VTOowLDguxP1K66/epIsm+Wzzt tB4LnobZBEvikQXCgVSz8PwxjlZX8X0U8md+4= MIME-Version: 1.0 Received: by 10.52.177.34 with SMTP id cn2mr9458849vdc.34.1322827784722; Fri, 02 Dec 2011 04:09:44 -0800 (PST) Received: by 10.220.191.13 with HTTP; Fri, 2 Dec 2011 04:09:44 -0800 (PST) In-Reply-To: <201111302341.pAUNfJDa008028@fs4113.wdf.sap.corp> References: <201111302341.pAUNfJDa008028@fs4113.wdf.sap.corp> Date: Fri, 2 Dec 2011 13:09:44 +0100 Message-ID: From: Mohamad Badra To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf3071cc903518d804b31ad881 Cc: tls@ietf.org Subject: Re: [TLS] TLS identity protection using Signaling Cipher Suite Value 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, 02 Dec 2011 12:09:49 -0000 --20cf3071cc903518d804b31ad881 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 30, 2011 at 12:41 AM, Martin Rex wrote: > Badra wrote: > > > > Martin Rex wrote: > > > > > > As I previously mentioned, the only reliable protection during the > > > handshake would be an indication from the server that is authenticated > > > by the server credential an can *not* be stripped from the handshake. > > > Basically, it would need to be hardwired into the server's credential, > > > like an additional certificate extension or a new EKU OID. > > > > As you previously mentioned too, hardwiring an new optional TLS protocol > > feature into a TLS server certificate, resulting in potentially hard to > > diagnose handshake failures. > > This "hard to diagnose handshake failures" refers only to client > implementations that would check for this server certificate attribute > and not sensible report to the user why the client implementation > aborted the handshake. "old" clients who do not check the feature > would not abort. Typical user reaction "but it works with Browser X!". > > > > > If the client doesn't receive such a message from the server, it must > > stop the TLS handshake > > Of course, you could implement it as a client-side credential attribute > which says "never send in the clear", instead of negotiating the protocol > feature with the server. That is not so much different from the server > conveying the info through a certificate attribute, just that it is > entirely up to the client whether an when it is being "enforced", > and the server has no say in that. If the user tries to use such a > feature before the server has even implemented it, the user will > face a failure (and switch it off). Who is going to reenable it > when the server adds the feature, then? If the server could steer > this with a certificate attribute, this would provide a certain > level of synchronization and negotiation whether the feature is > available and can (or should) be used. > Shall be the server's indication authenticated? (i.e. the client's indication is not authenticated) Best regards Badra --20cf3071cc903518d804b31ad881 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at= 12:41 AM, Martin Rex <mrex@sap.com> wrote:
Badra wrote:
>
> Martin Rex <mrex@sap.com> wr= ote:
> >
> > As I previously mentioned, the only reliable protection during th= e
> > handshake would be an indication from the server that is authenti= cated
> > by the server credential an can *not* be stripped from the handsh= ake.
> > Basically, it would need to be hardwired into the server's cr= edential,
> > like an additional certificate extension or a new EKU OID.
>
> As you previously mentioned too, hardwiring an new optional TLS protoc= ol
> feature into a TLS server certificate, resulting in potentially hard t= o
> diagnose handshake failures.

This "hard to diagnose handshake failures" refers only to c= lient
implementations that would check for this server certificate attribute
and not sensible report to the user why the client implementation
aborted the handshake. =A0"old" clients who do not check the feat= ure
would not abort. =A0Typical user reaction "but it works with Browser X= !".

>
> If the client doesn't receive such a message from the server, it m= ust
> stop the TLS handshake

Of course, you could implement it as a client-side credential attribu= te
which says "never send in the clear", instead of negotiating the = protocol
feature with the server. =A0That is not so much different from the server conveying the info through a certificate attribute, just that it is
entirely up to the client whether an when it is being "enforced",=
and the server has no say in that. =A0If the user tries to use such a
feature before the server has even implemented it, the user will
face a failure (and switch it off). =A0Who is going to reenable it
when the server adds the feature, then? =A0If the server could steer
this with a certificate attribute, this would provide a certain
level of synchronization and negotiation whether the feature is
available and can (or should) be used.

=
Shall be the server's indication authenticated? (i.e. th= e client's indication is not authenticated)

Best regards
Badra
--20cf3071cc903518d804b31ad881-- From internet-drafts@ietf.org Fri Dec 2 11:48:56 2011 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 82FED11E80F5; Fri, 2 Dec 2011 11:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 dKzVTP0MygVS; Fri, 2 Dec 2011 11:48:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2257721F8B29; Fri, 2 Dec 2011 11:48:56 -0800 (PST) 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: 3.64 Message-ID: <20111202194856.10751.81163.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2011 11:48:56 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-dtls-heartbeat-04.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: Fri, 02 Dec 2011 19:48:56 -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 Grou= p of the IETF. Title : Transport Layer Security (TLS) and Datagram Transport La= yer Security (DTLS) Heartbeat Extension Author(s) : Robin Seggelmann Michael Tuexen Michael Williams Filename : draft-ietf-tls-dtls-heartbeat-04.txt Pages : 9 Date : 2011-12-02 This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path maximum transmission unit (PMTU) discovery for DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-04.txt From jsalowey@cisco.com Sun Dec 4 22:13:37 2011 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 BAA9321F8508 for ; Sun, 4 Dec 2011 22:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 JfN1HCrgqjss for ; Sun, 4 Dec 2011 22:13:37 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEF421F8491 for ; Sun, 4 Dec 2011 22:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=660; q=dns/txt; s=iport; t=1323065617; x=1324275217; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=qJE9fqJEIv9IQtyY2JnQnXcOXLjw23JSpTovGtF0Wn0=; b=ca8zKKwv7JDzrkLXweSxpug2XqsDPMVKkbpDWPRbagdPb36DF5X7hBPq tWTl8Z9CxVRz0/CMAKrNJ8w3IzfP8pzdfbLEYuFOcpO4uv4QHs6w3xy5p mnvRqWA/Pi0dksEUYLI+islzyeDeIuE1IscT/Dm7vDKxEy/AlS2fHtz2q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEANRf3E6rRDoG/2dsb2JhbABEqjiBBYILASeCGRmHbZVngSYBnWWIDIIyYwSILYwvhUeMcg X-IronPort-AV: E=Sophos;i="4.71,297,1320624000"; d="scan'208";a="17720801" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 05 Dec 2011 06:13:36 +0000 Received: from [10.33.251.93] ([10.33.251.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB56Da1I011537 for ; Mon, 5 Dec 2011 06:13:36 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Dec 2011 22:13:47 -0800 Message-Id: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review 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, 05 Dec 2011 06:13:37 -0000 Some changes were made to the document as part of IESG review. The = revised document and diffs can be found here: http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-04.txt http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-dtls-heartbeat-04 One of the requested changes was to randomize to the data in the = heartbeat message to attempt to head of any issues occurring from weak = or flawed ciphers. Since the change was relatively simple, the = document was modified even though modern ciphers should not have a = problem. Flaws may be discovered in one of the many cipher suites in = the future. =20 Cheers, Joe= From n.mavrogiannopoulos@gmail.com Mon Dec 5 01:37:29 2011 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 CEAD821F8AE1 for ; Mon, 5 Dec 2011 01:37:28 -0800 (PST) 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 DfdwVuF9GPv9 for ; Mon, 5 Dec 2011 01:37:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DABA21F8AF4 for ; Mon, 5 Dec 2011 01:37:27 -0800 (PST) Received: by faas1 with SMTP id s1so404847faa.31 for ; Mon, 05 Dec 2011 01:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L1JpkbkZ4vMhDApt8yOdXs9yodfkB5TNbEQdhSxPuLo=; b=ZI2bPOSddCB2tVIfPcLQkgexi8kzg4KoKTZD6Top2W9eL5afaH56y+EctvADbDM3RK AZXF5pHO7FucEyknDx6A52eBJFpfjplyYd1lG173AvulPling4JyyIFk0aUhJlUQx6j4 o1gmH6WNK2Sz3pKKhtSMiJSiZbovKyNYZFSXY= MIME-Version: 1.0 Received: by 10.180.74.211 with SMTP id w19mr1510940wiv.7.1323077847068; Mon, 05 Dec 2011 01:37:27 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.4.72 with HTTP; Mon, 5 Dec 2011 01:37:26 -0800 (PST) In-Reply-To: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> References: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> Date: Mon, 5 Dec 2011 10:37:26 +0100 X-Google-Sender-Auth: K_hOP6BeetOmgRB5fhqLHfJgJpU Message-ID: From: Nikos Mavrogiannopoulos To: Joe Salowey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review 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, 05 Dec 2011 09:37:29 -0000 On Mon, Dec 5, 2011 at 7:13 AM, Joe Salowey wrote: > Some changes were made to the document as part of IESG review. =C2=A0The = revised document and diffs can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-04.txt > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-dtls-heartbeat-04 > One of the requested changes was to randomize to the data in the heartbea= t message to attempt to head of any issues occurring from weak or flawed ci= phers. =C2=A0 Since the change was relatively simple, the document was modi= fied even though modern ciphers should not have a problem. =C2=A0Flaws may = be discovered in one of the many cipher suites in the future. Are there any papers or cipher documentation discussing how using randomized data in a packet would solve possible future cipher flaws? regards, Nikos From dharkins@lounge.org Mon Dec 5 09:04:25 2011 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 1222021F8C53 for ; Mon, 5 Dec 2011 09:04:25 -0800 (PST) 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 9qGkgEXVDp3M for ; Mon, 5 Dec 2011 09:04:24 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 648E421F8C0D for ; Mon, 5 Dec 2011 09:04:24 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 02EA5A88810C; Mon, 5 Dec 2011 09:04:24 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 5 Dec 2011 09:04:24 -0800 (PST) Message-ID: In-Reply-To: References: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> Date: Mon, 5 Dec 2011 09:04:24 -0800 (PST) From: "Dan Harkins" To: "Nikos Mavrogiannopoulos" 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] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review 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, 05 Dec 2011 17:04:25 -0000 On Mon, December 5, 2011 1:37 am, Nikos Mavrogiannopoulos wrote: > On Mon, Dec 5, 2011 at 7:13 AM, Joe Salowey wrote: >> Some changes were made to the document as part of IESG review.  The >> revised document and diffs can be found here: >> http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-04.txt >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-heartbeat-04 >> One of the requested changes was to randomize to the data in the >> heartbeat message to attempt to head of any issues occurring from weak >> or flawed ciphers.   Since the change was relatively simple, the >> document was modified even though modern ciphers should not have a >> problem.  Flaws may be discovered in one of the many cipher suites in >> the future. > > Are there any papers or cipher documentation discussing how using > randomized data in a packet would solve possible future cipher flaws? Check out "Deterministic Authenticated Encryption"* by Rogaway and Shrimpton. It defines a cipher mode for key-wrapping but the proof of security (appendix C) is based on the notion of randomized data in the packet-- i.e. that part of the data (the key) being wrapped is random. They also treat this new cipher mode as a general IV-based authenticated encryption scheme that has the property of misuse-resistance (section 7). regards, Dan. * http://www.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf From iesg-secretary@ietf.org Tue Dec 6 08:01:25 2011 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 7191D21F8BDB; Tue, 6 Dec 2011 08:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 joRHGOvUKO3L; Tue, 6 Dec 2011 08:01:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECAC21F8BE4; Tue, 6 Dec 2011 08:01:24 -0800 (PST) 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: 3.64 Message-ID: <20111206160124.9637.21667.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2011 08:01:24 -0800 Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension' to Proposed Standard (draft-ietf-tls-dtls-heartbeat-04.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, 06 Dec 2011 16:01:25 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension' (draft-ietf-tls-dtls-heartbeat-04.txt) as a 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-dtls-heartbeat/ Technical Summary The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path maximum transmission unit (PMTU) discovery for DTLS. Working Group Summary The is broad working group support for this document. Document Quality The document has been reviewed by the transport area directorate and feedback from that review was incorporated into the document. Several implementations are planned to enhance the support for DTLS to protect management and other UDP protocols. Personnel Joe Salowey (jsalowey@cisco.com) is the document shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. From n.mavrogiannopoulos@gmail.com Tue Dec 6 08:17:08 2011 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 381E021F8BF3 for ; Tue, 6 Dec 2011 08:17:08 -0800 (PST) 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 QRoZ1KkI4nX8 for ; Tue, 6 Dec 2011 08:17:07 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80EC621F8BF0 for ; Tue, 6 Dec 2011 08:17:07 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so5189819wgb.13 for ; Tue, 06 Dec 2011 08:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nQGRQKPv4F6tPvDu+d5/Qeu4UHX7k6og9nJnhwaa2ao=; b=Lvxg7iKqLYL78Qrw0laFTfcjU8CiXYZOkvVpOvtTdhaJcD0OcPrZ0x4J8oB9Q3zOkI xoZSg6drVNIF5ZZuviUEkwB86AY9zeCpS2lDIUz+uYitG/BSsGlVSEKvTO1mGCwagloq 7GFq17uJ3yhJ0M61FKhWxrCmsDTCW8WYngBM8= MIME-Version: 1.0 Received: by 10.227.204.208 with SMTP id fn16mr2345409wbb.6.1323188226740; Tue, 06 Dec 2011 08:17:06 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.4.72 with HTTP; Tue, 6 Dec 2011 08:17:06 -0800 (PST) In-Reply-To: References: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> Date: Tue, 6 Dec 2011 17:17:06 +0100 X-Google-Sender-Auth: sAHidVsJ258ezrZ7lJcRs2J3L7c Message-ID: From: Nikos Mavrogiannopoulos To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review 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, 06 Dec 2011 16:17:08 -0000 On Mon, Dec 5, 2011 at 6:04 PM, Dan Harkins wrote: >>> One of the requested changes was to randomize to the data in the >>> heartbeat message to attempt to head of any issues occurring from weak >>> or flawed ciphers. =C2=A0 Since the change was relatively simple, the >>> document was modified even though modern ciphers should not have a >>> problem. =C2=A0Flaws may be discovered in one of the many cipher suites= in >>> the future. >> Are there any papers or cipher documentation discussing how using >> randomized data in a packet would solve possible future cipher flaws? > =C2=A0Check out "Deterministic Authenticated Encryption"* by Rogaway and > Shrimpton. It defines a cipher mode for key-wrapping but the proof of > security (appendix C) is based on the notion of randomized data in the > packet-- i.e. that part of the data (the key) being wrapped is random. Indeed, but this is not a generic encryption mode like CBC or CTR. It is specifically designed to encrypt random keys, and thus depends on its randomness. Typical encryption modes are specifically designed to prevent someone distinguishing a given plaintext encryption from a random one. Now, if one would like to use a subliminal channel in TLS, the heartbeat extension now provides an unbounded channel. regards, Nikos From marsh@extendedsubset.com Tue Dec 6 08:56:54 2011 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 16A9721F8BFE for ; Tue, 6 Dec 2011 08:56:54 -0800 (PST) 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 4otR2IspYuT8 for ; Tue, 6 Dec 2011 08:56:53 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C421F8BF6 for ; Tue, 6 Dec 2011 08:56:53 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RXyK4-000M9u-R6 for tls@ietf.org; Tue, 06 Dec 2011 16:56:52 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8617363C3 for ; Tue, 6 Dec 2011 16:56:51 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18o5eExGweV6pV/exRkqlXsoy5tfecZYJ4= Message-ID: <4EDE4953.6040709@extendedsubset.com> Date: Tue, 06 Dec 2011 10:56:51 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] DTLS implementation attack? 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, 06 Dec 2011 16:56:54 -0000 Anyone have more info on this? Even just a CVE or 'fixed in' version would be helpful. http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a > Plaintext-Recovery Attacks Against Datagram TLS > > Kenneth Paterson and Nadhem Alfardan We describe an efficient and > full plaintext recovery attack against the OpenSSL implementation of > DTLS, and an efficient, partial plaintext recovery attack against the > GnuTLS implementation of DTLS. We discuss the reasons why these > implementations are insecure, drawing lessons for secure protocol > design and implementation in general. Thanks, - Marsh From n.mavrogiannopoulos@gmail.com Tue Dec 6 09:19:43 2011 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 6C42F21F8BBF for ; Tue, 6 Dec 2011 09:19:43 -0800 (PST) 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 3u1t8iOJj-Us for ; Tue, 6 Dec 2011 09:19:42 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7CF721F8BBA for ; Tue, 6 Dec 2011 09:19:41 -0800 (PST) Received: by bkbzs8 with SMTP id zs8so5177bkb.31 for ; Tue, 06 Dec 2011 09:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=A20Byh/Or9VXBUtu4DuJRiv2fZPAf5kOqI/qBAFxW8I=; b=C415j9YUjKX8Wx6qBxjdh+f0yyKHygdaaQbV/pFrykzoQNeQvjk/S5ygd3hh2t0O5x rdZEP5kbqfc2hXuCkxYF0TvzSI/2rqnG+oiOLCyw/wkCsaVoZL83rKJ4LTqjuXOCXCba +nXqg5jmJQhJ/laaUEeCGKIKC0zoZAr25TWxE= MIME-Version: 1.0 Received: by 10.180.74.211 with SMTP id w19mr8249141wiv.7.1323191979741; Tue, 06 Dec 2011 09:19:39 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.4.72 with HTTP; Tue, 6 Dec 2011 09:19:39 -0800 (PST) In-Reply-To: <4EDE4953.6040709@extendedsubset.com> References: <4EDE4953.6040709@extendedsubset.com> Date: Tue, 6 Dec 2011 18:19:39 +0100 X-Google-Sender-Auth: Xedo3L8-xU4bzcrtbENHNp2B-8w Message-ID: From: Nikos Mavrogiannopoulos To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS implementation attack? 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, 06 Dec 2011 17:19:43 -0000 On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray wrote: > Anyone have more info on this? > Even just a CVE or 'fixed in' version would be helpful. > http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a >> Plaintext-Recovery Attacks Against Datagram TLS Concerning gnutls the 3.0.8 release reduces the timing information revealed to an adversary to counter this attack. However, I'm still in contact with the authors for more information on the issue. regards, Nikos From mrex@sap.com Tue Dec 6 09:33:14 2011 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 DFD6721F8BC5 for ; Tue, 6 Dec 2011 09:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.133, 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 rI+kYtdn98sU for ; Tue, 6 Dec 2011 09:33:14 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F053E21F8BDB for ; Tue, 6 Dec 2011 09:33:13 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pB6HX02F012121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 18:33:00 +0100 (MET) From: Martin Rex Message-Id: <201112061732.pB6HWxJ3003658@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 6 Dec 2011 18:32:59 +0100 (MET) In-Reply-To: from "Nikos Mavrogiannopoulos" at Dec 6, 11 06:19:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DTLS implementation attack? 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, 06 Dec 2011 17:33:15 -0000 Nikos Mavrogiannopoulos wrote: > > On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray wrote: > > > Anyone have more info on this? > > Even just a CVE or 'fixed in' version would be helpful. > > http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a > >> Plaintext-Recovery Attacks Against Datagram TLS > > Concerning gnutls the 3.0.8 release reduces the timing information > revealed to an adversary to counter this attack. However, I'm still in > contact with the authors for more information on the issue. By following the "SHOULD silently discard" recommendation in DTLS http://tools.ietf.org/html/rfc4347#page-9 In general, DTLS implementations SHOULD silently discard data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate bad_record_mac alert with level fatal and terminate its connection state. in combination with a CBC-block cipher with explicit initial IV, you might be creating a decryption oracle, vaguely similar to the design defect in XML encryption with block ciphers in CBC-mode (XML encryption has an explicit IV, but no MAC at all -- which is suicidal in online scenarios, such as WS-Security). -Martin From ekr@rtfm.com Tue Dec 6 09:39:23 2011 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 2B51821F8AD2 for ; Tue, 6 Dec 2011 09:39:23 -0800 (PST) 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 SA4LimaFmzCd for ; Tue, 6 Dec 2011 09:39:22 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 100F521F8A67 for ; Tue, 6 Dec 2011 09:39:21 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2812814vbb.31 for ; Tue, 06 Dec 2011 09:39:21 -0800 (PST) Received: by 10.52.72.227 with SMTP id g3mr8630810vdv.10.1323193161488; Tue, 06 Dec 2011 09:39:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.186.70 with HTTP; Tue, 6 Dec 2011 09:38:39 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201112061732.pB6HWxJ3003658@fs4113.wdf.sap.corp> References: <201112061732.pB6HWxJ3003658@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 6 Dec 2011 09:38:39 -0800 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] DTLS implementation attack? 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, 06 Dec 2011 17:39:23 -0000 On Tue, Dec 6, 2011 at 9:32 AM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: >> >> On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray wro= te: >> >> > Anyone have more info on this? >> > Even just a CVE or 'fixed in' version would be helpful. >> > http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a >> >> Plaintext-Recovery Attacks Against Datagram TLS >> >> Concerning gnutls the 3.0.8 release reduces the timing information >> revealed to an adversary to counter this attack. However, I'm still in >> contact with the authors for more information on the issue. > > By following the "SHOULD silently discard" recommendation in DTLS > =A0http://tools.ietf.org/html/rfc4347#page-9 > > =A0 In general, DTLS implementations SHOULD silently discard data with > =A0 bad MACs. =A0If a DTLS implementation chooses to generate an alert wh= en > =A0 it receives a message with an invalid MAC, it MUST generate > =A0 bad_record_mac alert with level fatal and terminate its connection > =A0 state. > > in combination with a CBC-block cipher with explicit initial IV, > you might be creating a decryption oracle, vaguely similar to the > design defect in XML encryption with block ciphers in CBC-mode > (XML encryption has an explicit IV, but no MAC at all -- which > is suicidal in online scenarios, such as WS-Security). I'm not following why silent discard would create a problem. Can you explai= n the threat you are concerned about? -Ekr From dharkins@lounge.org Tue Dec 6 10:11:02 2011 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 6016921F8C0C for ; Tue, 6 Dec 2011 10:11:02 -0800 (PST) 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 vMqpesjOEWHn for ; Tue, 6 Dec 2011 10:10:52 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8A50621F8BFE for ; Tue, 6 Dec 2011 10:10:52 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2818C20054; Tue, 6 Dec 2011 10:10:36 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 6 Dec 2011 10:10:36 -0800 (PST) Message-ID: <299bdcba9ed4bc96b1f87ee7bd40c753.squirrel@www.trepanning.net> In-Reply-To: References: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> Date: Tue, 6 Dec 2011 10:10:36 -0800 (PST) From: "Dan Harkins" To: "Nikos Mavrogiannopoulos" 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] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review 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, 06 Dec 2011 18:11:02 -0000 On Tue, December 6, 2011 8:17 am, Nikos Mavrogiannopoulos wrote: > On Mon, Dec 5, 2011 at 6:04 PM, Dan Harkins wrote: > >>>> One of the requested changes was to randomize to the data in the >>>> heartbeat message to attempt to head of any issues occurring from weak >>>> or flawed ciphers.   Since the change was relatively simple, the >>>> document was modified even though modern ciphers should not have a >>>> problem.  Flaws may be discovered in one of the many cipher suites in >>>> the future. >>> Are there any papers or cipher documentation discussing how using >>> randomized data in a packet would solve possible future cipher flaws? >>  Check out "Deterministic Authenticated Encryption"* by Rogaway and >> Shrimpton. It defines a cipher mode for key-wrapping but the proof of >> security (appendix C) is based on the notion of randomized data in the >> packet-- i.e. that part of the data (the key) being wrapped is random. > > Indeed, but this is not a generic encryption mode like CBC or CTR. It > is specifically designed to encrypt random keys, and thus depends on > its randomness. Typical encryption modes are specifically designed to > prevent someone distinguishing a given plaintext encryption from a > random one. Actually it is a generic encryption mode. It's a generic AEAD scheme (like GCM or CCM) and has code-points allocated by IANA for AEAD algorithms defined by RFC 5116: http://www.iana.org/assignments/aead-parameters/aead-parameters.xml Unlike other AEAD schemes this one has the benefit of misuse-resistance (see section 7). It is also provably-secure key-wrapping scheme, as you note. I mention this because it formally addresses the issue of randomness in the packet and its effect on the security of the cipher mode which is what I thought you were asking about. It's a generic AEAD mode...it's a key-wrapping scheme... for a crypto protocol developer, it's the new SHIMMER! http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/ > Now, if one would like to use a subliminal channel in TLS, the > heartbeat extension now provides an unbounded channel. Well that's a whole different issue.... Dan. From mrex@sap.com Tue Dec 6 10:28:18 2011 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 36A1E21F8433 for ; Tue, 6 Dec 2011 10:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.122 X-Spam-Level: X-Spam-Status: No, score=-10.122 tagged_above=-999 required=5 tests=[AWL=0.127, 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 AdRet7ybKeFl for ; Tue, 6 Dec 2011 10:28:17 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2816721F8448 for ; Tue, 6 Dec 2011 10:28:16 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB6IRqIL016303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 19:27:52 +0100 (MET) From: Martin Rex Message-Id: <201112061827.pB6IRpLW006958@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 6 Dec 2011 19:27:51 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Dec 6, 11 09:38:39 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DTLS implementation attack? 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, 06 Dec 2011 18:28:18 -0000 Eric Rescorla wrote: > > On Tue, Dec 6, 2011 at 9:32 AM, Martin Rex wrote: > > Nikos Mavrogiannopoulos wrote: > >> > >> On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray wrote: > >> > >> > Anyone have more info on this? > >> > Even just a CVE or 'fixed in' version would be helpful. > >> > http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a > >> >> Plaintext-Recovery Attacks Against Datagram TLS > >> > >> Concerning gnutls the 3.0.8 release reduces the timing information > >> revealed to an adversary to counter this attack. However, I'm still in > >> contact with the authors for more information on the issue. > > > > By following the "SHOULD silently discard" recommendation in DTLS > >  http://tools.ietf.org/html/rfc4347#page-9 > > > >   In general, DTLS implementations SHOULD silently discard data with > >   bad MACs.  If a DTLS implementation chooses to generate an alert when > >   it receives a message with an invalid MAC, it MUST generate > >   bad_record_mac alert with level fatal and terminate its connection > >   state. > > > > in combination with a CBC-block cipher with explicit initial IV, > > you might be creating a decryption oracle, vaguely similar to the > > design defect in XML encryption with block ciphers in CBC-mode > > (XML encryption has an explicit IV, but no MAC at all -- which > > is suicidal in online scenarios, such as WS-Security). > > I'm not following why silent discard would create a problem. Can you explain > the threat you are concerned about? Nikos mentioned "timing information revealed to an adversary". Plaintext guessing attacks for block ciphers in CBC-mode exploit timing differences for padding errors and MAC-errors (a variation of Vaudenay). I know very little about DTLS. Quickly glancing over the spec. The last paragraph of this http://tools.ietf.org/html/rfc4347#section-4.1.2.5 "MUST discard" sounds even more dangerous. How about replaying in a 1:1 interleave crafted records trying to determine timing differences and the client's Finished message, so that the latter will cause the server to resend the server finished message -- which may enable the attacker to measure differences in processing the crafted record. -Martin From robert.cragie@gridmerge.com Tue Dec 6 10:29:37 2011 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 78C7D21F8C0E for ; Tue, 6 Dec 2011 10:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 dcx-VwWAguR9 for ; Tue, 6 Dec 2011 10:29:36 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C321F8801 for ; Tue, 6 Dec 2011 10:29:36 -0800 (PST) Received: from client-86-27-10-250.glfd.adsl.virginmedia.com ([86.27.10.250] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1RXzlm-0000zr-L6; Tue, 06 Dec 2011 18:29:35 +0000 Message-ID: <4EDE5F1E.2030605@gridmerge.com> Date: Tue, 06 Dec 2011 18:29:50 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Rene Struik , tls@ietf.org References: <4ED7EA82.2080407@gmail.com> In-Reply-To: <4ED7EA82.2080407@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030100030506080007060107" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and 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: Tue, 06 Dec 2011 18:29:37 -0000 This is a cryptographically signed message in MIME format. --------------ms030100030506080007060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rene, Comments inline, bracketed by Robert On 01/12/2011 8:58 PM, Rene Struik wrote: > Dear colleagues: > > Just a short note (I will have to review the cross-referenced four or s= o > RFCs later): > > 1) to my knowledge, for relatively short frames (a few times the size o= f > the underlying block cipher), > the GCM mode of operation is *not* "significantly faster" than the CCM > mode of operation. > > 2) 802.15.4-2011 (or 802.15.4-2006 for that matter) does use the CCM* > mode of operation, where > the nonce format is incompatible with that specified in the RFC 5116 or= > the mcgrew-tls-aes-ccm draft. > > Given #2 above, it seems that reference to 802.15.4's use of CCM is > somewhat inopportune. Not necessarily - it depends on the implementation of AES-CCM or=20 AES-CCM*. > Moreover, from > Don Sturek's note below, it seems that the Joe Salovey's note that > "Zigbee smart energy group has > interest in these drafts" should be taken with some grain of salt > (lukewarm interest at most, so it seems [if one > really wished to have had another cipher (on technical grounds???), the= n > one missed a window of opportunity > 802.15.4 TG4i issued very recently and 802.15.4 TGe just went to RevCom= ]). I am not sure what your point is. The fact is we are using these=20 drafts in efficient ZigBee IP implementations based on current=20 technology. > > On a more detailed technical note, > > a) how does one assure that nonces used by different entities never > clash if they use a > shared key for securing network traffic? (a scenario prevalent in lots > of ZigBee, RoLL, etc. scenarios). I would say this is somewhat out of scope for a TLS specification=20 but the situation exists for GCM as well and is covered in RFC 5116 for=20 both GCM and CCM > > b) I am curious as to whether the design in mcgrew-tls-aes-ccm allows > for reuse of keying material accross > layers, so as to economize on key storage and key management overhead? > (given that devices should be > assumed to have intra-device open trust domain, this seems feasible. I > am concerned the current draft may > kill off this prospect). I think the question is more whether it would preclude it and the=20 answer is IMHO no. > > Based on the above, I am somewhat critical as to why this should be > pushed, certainly as a standard-track > document. The aim was to align with the two GCM documents, i.e. align=20 draft-mcgrew-tls-aes-ccm with RFC 5288 (standards track) and=20 draft-mcgrew-tls-aes-ccm-ecc with RFC 5289 (informational). This seems=20 reasonable as they are equivalent > > Most of these arguments I have made before, but did not see addressed. > > I will provide more technical feedback later on, but prior to the > suggested December 15th deadline. > > Best regards, Rene > > On 01/12/2011 3:20 PM, Don Sturek wrote: >> Hi Dan, >> >> While ZigBee does specify AES-CCM* in their *commercial* specification= , I >> would say the general problem is that IEEE 802.15.4 (which ZigBee uses= ) >> specifies AES-CCM and nearly all silicon vendors have that (not CCM*) >> available. If we could somehow get those implementations to switch to= >> GCM, I don't think we would be asking for adoption of AES-CCM. That s= aid, >> for the IEEE 802.15.4 devices already manufactured and in those in the= >> field, either we try to align the use of TLS with what is available >> hardware wise or else bypass the AES-CCM engine in those parts and >> implement GCM in software..... >> >> Don >> >> >> >> >> On 12/1/11 12:01 PM, "Dan Harkins" wrote: >> >>> On Wed, November 30, 2011 1:34 pm, Joe Salowey wrote: >>>> The chairs would like to see if there is consensus in the TLS workin= g >>>> group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm= -ecc >>>> as working group items. These drafts define AES-CCM cipher suites f= or >>>> TLS. The Zigbee smart energy group has interest in these drafts. >>>> These >>>> drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which= is >>>> a >>>> super set of AES-CCM. The authors are requesting standards track fo= r >>>> these ciphers. Please note that there is an IPR declaration listed = for >>>> draft-mcgrew-tls-aes-ccm-ecc available here: >>>> https://datatracker.ietf.org/ipr/1443/. This declaration has been >>>> updated >>>> from previous declarations. Please respond to the following by >>>> December >>>> 14, 2011 : >>>> >>>> - Do you object to taking these drafts on as working group items? >>>> (Please >>>> state the reason for you objection) >>> No. >>> >>>> - Would you contribute time to review and provide text for the docum= ents >>>> when needed? >>> Yes. >>> >>>> - Do you object to standards track status for these documents?(Pleas= e >>>> state the reason for you objection) >>> I have a mild objection. There is no point in doing CCM. GCM is fas= ter, >>> if you're gonna implement an AEAD scheme implement GCM. If you really= want >>> a 2-pass AEAD scheme you can use RFC 5297 and you get misuse-resistan= ce >>> for free (basically the security of the mode does not collapse if you= >>> reuse a nonce/counter). The only group I know pushing CCM is actually= >>> pushing CCM* and, as you note, this isn't CCM*. >>> >>> Dan. >>> >>> >>> _______________________________________________ >>> 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 > --------------ms030100030506080007060107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIwNjE4Mjk1MFowIwYJKoZI hvcNAQkEMRYEFP0aFUTsDMxH/VqBeY9WMVaNJp1QMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQCesg6xHbTUjdpWUvXXh9FF E7cwL8XUjCxMKbb4Xs4e3nodinMp+Jo79hCC/P1FJqKHXpLOdaqGg4h7zKhGN3XQLTSsB8lh Vcv2vmFVDyzDF4luge5aPYH8vTFYPRyK4Qu65dk8/+sx+2Xsm0u9OnbuPZ3N49XZR04VbuEl ODcMCNHyRuZlEEa4UxYAdSesDS3Jtrh1wo2pDwqWzWNs2ZozQpAcusHJwVHelWek0UeOC5W+ a6DMwftcz1lAgMkjzFEHrJRTltY0ds/7dHnNQMm5lpuVzbpLq6Iiyh3uKjyzkMpHPxpVEREv vrmFhF5G00RLfWezKfayzospIQSenruVAAAAAAAA --------------ms030100030506080007060107-- From ekr@rtfm.com Tue Dec 6 10:52:35 2011 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 7637421F8BDB for ; Tue, 6 Dec 2011 10:52:35 -0800 (PST) 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 PlqO-M8V9hXM for ; Tue, 6 Dec 2011 10:52:34 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 990A021F8BBA for ; Tue, 6 Dec 2011 10:52:34 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2904558vbb.31 for ; Tue, 06 Dec 2011 10:52:34 -0800 (PST) Received: by 10.52.92.70 with SMTP id ck6mr8711077vdb.61.1323197554106; Tue, 06 Dec 2011 10:52:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.186.70 with HTTP; Tue, 6 Dec 2011 10:51:53 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201112061827.pB6IRpLW006958@fs4113.wdf.sap.corp> References: <201112061827.pB6IRpLW006958@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 6 Dec 2011 10:51:53 -0800 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] DTLS implementation attack? 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, 06 Dec 2011 18:52:35 -0000 On Tue, Dec 6, 2011 at 10:27 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Tue, Dec 6, 2011 at 9:32 AM, Martin Rex wrote: >> > Nikos Mavrogiannopoulos wrote: >> >> >> >> On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray = wrote: >> >> >> >> > Anyone have more info on this? >> >> > Even just a CVE or 'fixed in' version would be helpful. >> >> > http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a >> >> >> Plaintext-Recovery Attacks Against Datagram TLS >> >> >> >> Concerning gnutls the 3.0.8 release reduces the timing information >> >> revealed to an adversary to counter this attack. However, I'm still i= n >> >> contact with the authors for more information on the issue. >> > >> > By following the "SHOULD silently discard" recommendation in DTLS >> > =A0http://tools.ietf.org/html/rfc4347#page-9 >> > >> > =A0 In general, DTLS implementations SHOULD silently discard data with >> > =A0 bad MACs. =A0If a DTLS implementation chooses to generate an alert= when >> > =A0 it receives a message with an invalid MAC, it MUST generate >> > =A0 bad_record_mac alert with level fatal and terminate its connection >> > =A0 state. >> > >> > in combination with a CBC-block cipher with explicit initial IV, >> > you might be creating a decryption oracle, vaguely similar to the >> > design defect in XML encryption with block ciphers in CBC-mode >> > (XML encryption has an explicit IV, but no MAC at all -- which >> > is suicidal in online scenarios, such as WS-Security). >> >> I'm not following why silent discard would create a problem. Can you exp= lain >> the threat you are concerned about? > > Nikos mentioned "timing information revealed to an adversary". > > Plaintext guessing attacks for block ciphers in CBC-mode exploit > timing differences for padding errors and MAC-errors (a variation > of Vaudenay). > > I know very little about DTLS. =A0Quickly glancing over the spec. > The last paragraph of this > =A0 http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > "MUST discard" sounds even more dangerous. > > How about replaying in a 1:1 interleave crafted records > trying to determine timing differences and the client's Finished > message, so that the latter will cause the server to resend the > server finished message -- which may enable the attacker to measure > differences in processing the crafted record. I'm still not sure I understand the threat model you have in mind here. These attacks rely on the attacker using the peer as an oracle to learn something he doesn't otherwise know. In the case of the Vaudenay attacks, assuming I remember correctly, it's whether a block is correctly CBC padded versus whether it's incorrectly CBC padded (and hence will produce an invalid MAC). So, what's important here is to treat CBC padding errors the same way you treat MAC errors. As far as I know, treating MAC errors differently from valid packets doesn't leak useful information, since tampering with anything in the TLS packet should produce an invalid MAC, a fact the attacker is presumably aware of. -Ekr From n.mavrogiannopoulos@gmail.com Wed Dec 7 01:43:45 2011 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 DC59321F85A4 for ; Wed, 7 Dec 2011 01:43:45 -0800 (PST) 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 5fbd1VPQv272 for ; Wed, 7 Dec 2011 01:43:45 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E80D821F8531 for ; Wed, 7 Dec 2011 01:43:44 -0800 (PST) Received: by eekd4 with SMTP id d4so288685eek.31 for ; Wed, 07 Dec 2011 01:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=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=iUWoz7mOUBxVHX72pFVsW2q7HXCk4rgcPwdMKcgDnKA=; b=RtC20jBnPcpQUuTm/h49kl0fnjE9pvJZ1k69NeSuiC1dqdWdeVVzg/Q8hVsR/NyDSI 7V0rH5bs3/NKAIofDfiE7WES1Lh0VPR/WS8z7vfBSshnCm2vmwwxVcmtPNFqtaXwFMoZ d2RCXkPJmQldrA1J7kCV9QD54r8a+x6uT4J28= Received: by 10.14.2.25 with SMTP id 25mr3495551eee.32.1323251022102; Wed, 07 Dec 2011 01:43:42 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id 49sm3809523eec.1.2011.12.07.01.43.41 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 01:43:41 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4EDF35E7.2060107@gnutls.org> Date: Wed, 07 Dec 2011 10:46:15 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: mrex@sap.com References: <201112061732.pB6HWxJ3003658@fs4113.wdf.sap.corp> In-Reply-To: <201112061732.pB6HWxJ3003658@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] DTLS implementation attack? 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, 07 Dec 2011 09:43:46 -0000 On 12/06/2011 06:32 PM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: >> >> On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray >> wrote: >> >>> Anyone have more info on this? Even just a CVE or 'fixed in' >>> version would be helpful. >>> http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a >>>> Plaintext-Recovery Attacks Against Datagram TLS >> >> Concerning gnutls the 3.0.8 release reduces the timing information >> revealed to an adversary to counter this attack. However, I'm still >> in contact with the authors for more information on the issue. > > By following the "SHOULD silently discard" recommendation in DTLS > http://tools.ietf.org/html/rfc4347#page-9 in combination with a > CBC-block cipher with explicit initial IV, you might be creating a > decryption oracle, The attack on the paper was trying to detect the difference in processing time of a message with an invalid pad and a message with an invalid mac in CBC ciphers. For that they transferred a series of packets followed by a heartbeat message[0], and then checked the time it took for the heartbeat reply to arrive. I don't want to copy their claims before it is published but they don't mention that silently discarding messages is an issue, they rather say that developers relied on that to make non constant time processing. [0]. In gnutls that doesn't have the heartbeat extension they used a custom technique of similar nature. regards, Nikos From mrex@sap.com Fri Dec 9 22:36:38 2011 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 4DB2F21F8AB9 for ; Fri, 9 Dec 2011 22:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.181, 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 Uxz1voLxOn4P for ; Fri, 9 Dec 2011 22:36:37 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1677121F89BA for ; Fri, 9 Dec 2011 22:36:36 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBA6aTGV002577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 10 Dec 2011 07:36:34 +0100 (MET) From: Martin Rex Message-Id: <201112100636.pBA6aSIr021536@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Sat, 10 Dec 2011 07:36:28 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: [TLS] popularity of truncated MAC TLS extension 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: Sat, 10 Dec 2011 06:36:38 -0000 Which implementations support the truncated MAC extension from rfc6066 (first published as rfc3546)? I was forwarded the following URL: http://www.rhul.ac.uk/aboutus/newsandevents/news/newsarticles/cryptographersbelievesizedoesmattertostaysafeonline.aspx about the paper "Tag Size Does Matter: Attacks and Proofs for the TLS Record Protocol" Kenneth G. Paterson, Thomas Ristenpart, and Thomas Shrimpton I don't know whether it is due my lack of sleep, but I found the paper slightly difficult to read. I don't currently feel like I have to be afraid of anything. -Martin From pgut001@login01.cs.auckland.ac.nz Fri Dec 9 23:18:15 2011 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 2C97621F85BB for ; Fri, 9 Dec 2011 23:18:15 -0800 (PST) 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 njWAmEYHPJFw for ; Fri, 9 Dec 2011 23:18:13 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCD21F8446 for ; Fri, 9 Dec 2011 23:18:11 -0800 (PST) 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=1323501493; x=1355037493; h=from:to:subject:cc:in-reply-to:message-id:date; bh=vm8R5CEzlvNX7QtRKExRODax6hwvPF0KxLqXG5VRSQg=; b=K6s1HnIOkKKRiwiTP1iVbJswluBhiElzGzsnXTrUAkMV8u+gKQAQMBXn M5veBmgn5PCfQF8n0ZcR7H+z5UMjYuou0YG2ABJl+GX5CqDKJH/aRyEnK gkUnbyMxIzbmKiIdll0Cf6cTx3L2j1PTyHAAwV6eAjUxjN6Qle+Un4tLy U=; X-IronPort-AV: E=Sophos;i="4.71,331,1320577200"; d="scan'208";a="94012077" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Dec 2011 20:18:04 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RZHC7-0006BG-LL; Sat, 10 Dec 2011 20:18:03 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201112100636.pBA6aSIr021536@fs4113.wdf.sap.corp> Message-Id: Date: Sat, 10 Dec 2011 20:18:03 +1300 Cc: tls@ietf.org Subject: Re: [TLS] popularity of truncated MAC TLS extension 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, 10 Dec 2011 07:18:15 -0000 Martin Rex writes: >Which implementations support the truncated MAC extension from rfc6066 (first >published as rfc3546)? According to the TLS comparison table set up about a year ago, none of them do. (This would make it one of the few successful cases of the cordon sanitaire applied to crypto protocols). Peter. From shinsh93@gmail.com Sat Dec 10 00:39:32 2011 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 6553E21F8B0E for ; Sat, 10 Dec 2011 00:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 OvbUolwGSMk8 for ; Sat, 10 Dec 2011 00:39:31 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8FD21F8AF8 for ; Sat, 10 Dec 2011 00:39:30 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so5573578wgb.13 for ; Sat, 10 Dec 2011 00:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kYYXYrrwVezhRm38/zFlGdIGyo2NnMhcHJauOudz5ro=; b=vxgDZnd/YGlvtIThphB6i7JZizFOtrAtpyWh9O0Lfo3Jov2CL3JMKmUsNTsw++IvXK iyYq62TPlVA2+8piqIRzTL3cFGIIZnbeI6vfz8Ajfv0g6wQH+MTNY9kYK779agjPrOKw yyrRhGvHY00C36jR8wDEswnABztqx3F0Hlh+c= MIME-Version: 1.0 Received: by 10.216.229.75 with SMTP id g53mr675534weq.31.1323506365729; Sat, 10 Dec 2011 00:39:25 -0800 (PST) Sender: shinsh93@gmail.com Received: by 10.216.68.17 with HTTP; Sat, 10 Dec 2011 00:39:25 -0800 (PST) In-Reply-To: <4ECACDA3.4000003@gmail.com> References: <4ECACDA3.4000003@gmail.com> Date: Sat, 10 Dec 2011 17:39:25 +0900 X-Google-Sender-Auth: BYeGGMoAdoojEuQw0xLtvXlehmg Message-ID: From: SeongHan Shin To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016364d1b8bc98b5c04b3b8d66c Cc: Kazukuni Kobara Subject: Re: [TLS] about the PWD Proposal 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, 10 Dec 2011 08:39:32 -0000 --0016364d1b8bc98b5c04b3b8d66c Content-Type: text/plain; charset=ISO-8859-1 Dear TLS WG members, You can see I-D of "augmented" PAKE protocol below. https://datatracker.ietf.org/doc/draft-shin-augmented-pake/ In Section 2, several advantages and security features can be found. Best regards, Shin On Tue, Nov 22, 2011 at 7:16 AM, Yaron Sheffer wrote: > In a somewhat related protocol (IKEv2 with PACE for authentication), we > added an appendix on password salting: http://tools.ietf.org/html/** > draft-kuegler-ipsecme-pace-**ikev2-08#appendix-B. > The setting there is a little different from tls-pwd, because IKE is > normally symmetric (peer to peer vs. client to server). But some of our > analysis does apply. In particular, dynamically replacing the short > credentials by a long shared secret ( http://tools.ietf.org/html/** > draft-kuegler-ipsecme-pace-**ikev2-08#appendix-B.3) > would mitigate much of the risk. > > Thanks, > Yaron > > ----- > Hi, > I am interested in the PWD proposal at the meeting, and run through it( > http://tools.ietf.org/html/**draft-harkins-tls-pwd-01#**section-3.4), > > > and have the following concerns: > > 1. In the document, it says both Client and Server should be able to > compute PE, which is derived from username, password, salt,etc. > That means Client or the user should also remember the salt value, in > that case, salt is meaningless and can be replaced by a longer password. > This is quite different from the widely known usage of salt, e.g. in > UNIX operating system, salt is not required to remember by the user, but by > server to fetch locally by reference to the username. > And as far as I know, I am sure the authors also know that, other > password based key exchanges protocols don't involve salt, but store a hash > value of password among other things locally. > > I realize that this is very different from the usage in UNIX operating >> systems, but it is necessary, as the UNIX (or other) operating system >> running the web server has to store the password. Storing the password in >> the clear on as an unsalted hash is worse than storing a salted hash (or >> "base" in the draft's terminology), so that is what the TLS server does. >> The use of base instead of password is not to protect the password during >> handshake, but to protect it during storage on the server. >> >> Having said that, I think it is now very practical to take a list of the >> 100,000 most popular passwords on the web, a database of 10,000 salted >> hashes (the file described in section 3.4), and find all the matches. >> That's 1,000,000,000 operations, which would take 15 minutes on a MacBook >> Air (1.4 GHz). I think the days of saying that a database of salted hashes >> makes theft of the password file irrelevant should be over. Yes, I know >> that with unsalted hash it would be practical to test the 100,000,000 most >> popular passwords. >> >> session cookies somehow (e.g., via the BEAST attack): but if you don't >> have my OBCs' private keys then you can't actually make use of my >> cookies. >> >> With OBC cookie theft is not enough. With OBC the attacker must get >> at the private keys for the OBCs. >> >> Also, with OBC you get closer to true logout: destroy ("forget") your >> OBC private keys and your sessions are as good as dead. Moreover, the >> user-agent, not the server, is in control of maximum session lifetime, >> since there's no point in the server setting cookies that will outlive >> the OBCs. >> I we can find no other use case, we might want to rename it to "Origin >> Bound Cookie". >> >> But that would require some interesting interaction between layers. >> >> Are all cookies received while using OBC considered (by the client!) >> bound to the OBC? If not, the client might use an old cookie after a logout >> event, leading to the server falsely detecting an attempt to forge a >> cookie. Maybe we need a new keyword on the cookie header. >> >> Where is the "logout" button? If it's part of the website (in the >> "canvas") how does the HTML/HTTP tell the browser to log out? Probably best >> to have it in the Chrome for sites where OBC are supported. >> > > > ______________________________**_________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/**listinfo/tls > -- ------------------------------------------------------------------ SeongHan Shin Research Center for Information Security (RCIS), National Institute of Advanced Industrial Science and Technology (AIST), Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan Tel : +81-29-861-2670/5284 Fax : +81-29-861-5285 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ --0016364d1b8bc98b5c04b3b8d66c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear TLS WG members,
=A0
You can see I-D of "augmented" PAKE protocol below.
In Section 2, several advantages and security features can be found.
=A0
Best regards,
Shin
=A0
=A0
On Tue, Nov 22, 2011 at 7:16 AM, Yaron Sheffer <= span dir=3D"ltr"><yaronf.ietf@g= mail.com> wrote:
In a somewhat related protocol (IKEv2= with PACE for authentication), we added an appendix on password salting: <= a href=3D"http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#ap= pendix-B" target=3D"_blank">http://tools.ietf.org/html/draft-kuegler= -ipsecme-pace-ikev2-08#appendix-B. The setting there is a little= different from tls-pwd, because IKE is normally symmetric (peer to peer vs= . client to server). But some of our analysis does apply. In particular, dy= namically replacing the short credentials by a long shared secret ( http://tools.ietf.org/html/draft-kuegler-ips= ecme-pace-ikev2-08#appendix-B.3) would mitigate much of the risk= .

Thanks,
=A0 =A0Yaron

-----
=A0Hi,
=A0I am interested in= the PWD proposal at the meeting, and run through it(htt= p://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4<= /a>),=20

=A0and have the following concerns:

1. In the = document, it =A0says both Client and Server should be able to compute PE, w= hich is derived from username, password, salt,etc.
=A0 That means Client= or the user should also remember the salt value, in that case, salt is mea= ningless and can be replaced by a longer password.
=A0 This is quite different from the widely known usage of salt, e.g. in UN= IX operating system, salt is not required to remember by the user, but by s= erver to fetch locally by reference to the username.
=A0And as far as I = know, I am sure the authors also know that, other password based key exchan= ges protocols don't involve salt, but store a hash value of password am= ong other things locally.

I realize that this is very different from the usage in U= NIX operating systems, but it is necessary, as the UNIX (or other) operatin= g system running the web server has to store the password. Storing the pass= word in the clear on as an unsalted hash is worse than storing a salted has= h (or "base" in the draft's terminology), so that is what the= TLS server does. The use of base instead of password is not to protect the= password during handshake, but to protect it during storage on the server.=

Having said that, I think it is now very practical to take a list of th= e 100,000 most popular passwords on the web, a database of 10,000 salted ha= shes (the file described in section 3.4), and find all the matches. That= 9;s 1,000,000,000 operations, which would take 15 minutes on a MacBook Air = (1.4 GHz). I think the days of saying that a database of salted hashes make= s theft of the password file irrelevant should be over. Yes, I know that wi= th unsalted hash it would be practical to test the 100,000,000 most popular= passwords.

session cookies somehow (e.g., via the BEAST attack): but if you = don't
have my OBCs' private keys then you can't actually mak= e use of my
cookies.

With OBC cookie theft is not enough. =A0With= OBC the attacker must get
at the private keys for the OBCs.

Also, with OBC you get closer to t= rue logout: destroy ("forget") your
OBC private keys and your = sessions are as good as dead. =A0Moreover, the
user-agent, not the serve= r, is in control of maximum session lifetime,
since there's no point in the server setting cookies that will outlive<= br>the OBCs.
I we can find no other use case, we might want to rename it= to "Origin Bound Cookie".

But that would require some int= eresting interaction between layers.

Are all cookies received while using OBC considered (by the client!) bo= und to the OBC? If not, the client might use an old cookie after a logout e= vent, leading to the server falsely detecting an attempt to forge a cookie.= Maybe we need a new keyword on the cookie header.

Where is the "logout" button? =A0If it's part of the webs= ite (in the "canvas") how does the HTML/HTTP tell the browser to = log out? Probably best to have it in the Chrome for sites where OBC are sup= ported.


__________________________________________= _____
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--

-------------------------------------= -----------------------------
SeongHan Shin
Research Center for Infor= mation Security (RCIS),
National Institute of Advanced Industrial Science and Technology (AIST),Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : += 81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seongha= n.shin@aist.go.jp
------------------------------------------------------------------
--0016364d1b8bc98b5c04b3b8d66c-- From demoss.matt@gmail.com Mon Dec 12 10:52:52 2011 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 7F8C421F8783 for ; Mon, 12 Dec 2011 10:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 MkiYosn+wlOt for ; Mon, 12 Dec 2011 10:52:51 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1D3621F8A6C for ; Mon, 12 Dec 2011 10:52:44 -0800 (PST) Received: by eaad1 with SMTP id d1so1624817eaa.31 for ; Mon, 12 Dec 2011 10:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hKOfGFyfJPzFgBvVzWcIZEFqyu3wg6zcn7Kp5sJDfHA=; b=wzMF5f+/lZsDhoAsSL8zRMGH5oCxXFR8dGYb8hh10IupLUmxqP/SzFiG3pqbDQhLbE mmFQ92L5m9wez8B8eusWWmyOFT+Xsaug5k1/yN5kfYSaLFuHoROIm8B+FC3ZM/sHlDc6 L+SqsiPkmWGH4Z4OnwDLOsV3qmFcw+jBMNkRI= MIME-Version: 1.0 Received: by 10.216.46.148 with SMTP id r20mr2438517web.114.1323715963451; Mon, 12 Dec 2011 10:52:43 -0800 (PST) Received: by 10.223.88.134 with HTTP; Mon, 12 Dec 2011 10:52:43 -0800 (PST) In-Reply-To: <4ECACDA3.4000003@gmail.com> References: <4ECACDA3.4000003@gmail.com> Date: Mon, 12 Dec 2011 13:52:43 -0500 Message-ID: From: Matt DeMoss To: Yaron Sheffer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] about the PWD Proposal 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, 12 Dec 2011 18:52:52 -0000 Does it make sense to suggest that the server could store long term only a salt and the result of PBKDF2? I believe that could be done without altering the proposal, but would be too much work for the server. If the protocol was altered, client and server could negotiate the number of iterations and the work of performing PBKDF2 could be moved to the client. Wifi-Protected Access includes a "pass-phrase=96to=96PSK mapping" using PBKDF2, but possibly with different goals. On Mon, Nov 21, 2011 at 5:16 PM, Yaron Sheffer wrot= e: > In a somewhat related protocol (IKEv2 with PACE for authentication), we > added an appendix on password salting: > http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B= . > The setting there is a little different from tls-pwd, because IKE is > normally symmetric (peer to peer vs. client to server). But some of our > analysis does apply. In particular, dynamically replacing the short > credentials by a long shared secret ( > http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B= .3) > would mitigate much of the risk. > > Thanks, > =A0 =A0Yaron > > ----- > =A0Hi, > =A0I am interested in the PWD proposal at the meeting, and run through > it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), > > =A0and have the following concerns: > > 1. In the document, it =A0says both Client and Server should be able to > compute PE, which is derived from username, password, salt,etc. > =A0 That means Client or the user should also remember the salt value, in= that > case, salt is meaningless and can be replaced by a longer password. > =A0 This is quite different from the widely known usage of salt, e.g. in = UNIX > operating system, salt is not required to remember by the user, but by > server to fetch locally by reference to the username. > =A0And as far as I know, I am sure the authors also know that, other pass= word > based key exchanges protocols don't involve salt, but store a hash value = of > password among other things locally. > >> I realize that this is very different from the usage in UNIX operating >> systems, but it is necessary, as the UNIX (or other) operating system >> running the web server has to store the password. Storing the password i= n >> the clear on as an unsalted hash is worse than storing a salted hash (or >> "base" in the draft's terminology), so that is what the TLS server does.= The >> use of base instead of password is not to protect the password during >> handshake, but to protect it during storage on the server. >> >> Having said that, I think it is now very practical to take a list of the >> 100,000 most popular passwords on the web, a database of 10,000 salted >> hashes (the file described in section 3.4), and find all the matches. Th= at's >> 1,000,000,000 operations, which would take 15 minutes on a MacBook Air (= 1.4 >> GHz). I think the days of saying that a database of salted hashes makes >> theft of the password file irrelevant should be over. Yes, I know that w= ith >> unsalted hash it would be practical to test the 100,000,000 most popular >> passwords. >> >> session cookies somehow (e.g., via the BEAST attack): but if you don't >> have my OBCs' private keys then you can't actually make use of my >> cookies. >> >> With OBC cookie theft is not enough. =A0With OBC the attacker must get >> at the private keys for the OBCs. >> >> Also, with OBC you get closer to true logout: destroy ("forget") your >> OBC private keys and your sessions are as good as dead. =A0Moreover, the >> user-agent, not the server, is in control of maximum session lifetime, >> since there's no point in the server setting cookies that will outlive >> the OBCs. >> I we can find no other use case, we might want to rename it to "Origin >> Bound Cookie". >> >> But that would require some interesting interaction between layers. >> >> Are all cookies received while using OBC considered (by the client!) bou= nd >> to the OBC? If not, the client might use an old cookie after a logout ev= ent, >> leading to the server falsely detecting an attempt to forge a cookie. Ma= ybe >> we need a new keyword on the cookie header. >> >> Where is the "logout" button? =A0If it's part of the website (in the >> "canvas") how does the HTML/HTTP tell the browser to log out? Probably b= est >> to have it in the Chrome for sites where OBC are supported. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From dharkins@lounge.org Mon Dec 12 12:52:58 2011 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 1E77421F87D6 for ; Mon, 12 Dec 2011 12:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, 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 QEj5DkSit3s3 for ; Mon, 12 Dec 2011 12:52:57 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F0E5321F861E for ; Mon, 12 Dec 2011 12:52:56 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7F0101022404A; Mon, 12 Dec 2011 12:52:55 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Dec 2011 12:52:55 -0800 (PST) Message-ID: <5af4a304c9258f2478144c4aaa54a4da.squirrel@www.trepanning.net> In-Reply-To: References: <4ECACDA3.4000003@gmail.com> Date: Mon, 12 Dec 2011 12:52:55 -0800 (PST) From: "Dan Harkins" To: "Matt DeMoss" 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: Yaron Sheffer , tls@ietf.org Subject: Re: [TLS] about the PWD Proposal 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, 12 Dec 2011 20:52:58 -0000 This thread seems to be diverging a bit. Can we return to the technique used in (version 01 of) the PWD proposal? Is that adequate? IKE has a completely different usage model where, as Yaron mentions, both sides need access to the password. TLS has stricter role assignment. Wifi-Protected Access is insecure since it's not based on a zero knowledge proof. Its use of PBKDF2 is just supposed to slow down an offline dictionary attack. Below it's noted that if one has access to database of 10,000 salted passwords and a dictionary of 100,000 of the most popular passwords (assume that quite a few of them will be in the 10,000) that it's possible to do a dictionary attack quite easily. Adding PBKDF2 would slow that down but not much: http://www.theregister.co.uk/2011/01/11/amazon_cloud_wifi_cracking/ It's futile to throw more iterations at this problem. The solution is using a protocol based on a zero knowledge proof-- like the protocol in question-- an get away from broken things like Wifi-Protected Access, or any of the TLS-PSK ciphersuites, using passwords. If an adversary gets access to a database of passwords then the contents of that database should be assumed to be compromised even if they're salted and even if they've been PBKDF2'd with 10,000 iterations. Dan. On Mon, December 12, 2011 10:52 am, Matt DeMoss wrote: > Does it make sense to suggest that the server could store long term > only a salt and the result of PBKDF2? > > I believe that could be done without altering the proposal, but would > be too much work for the server. If the protocol was altered, client > and server could negotiate the number of iterations and the work of > performing PBKDF2 could be moved to the client. > > Wifi-Protected Access includes a "pass-phrase–to–PSK mapping" using > PBKDF2, but possibly with different goals. > > On Mon, Nov 21, 2011 at 5:16 PM, Yaron Sheffer > wrote: >> In a somewhat related protocol (IKEv2 with PACE for authentication), we >> added an appendix on password salting: >> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B. >> The setting there is a little different from tls-pwd, because IKE is >> normally symmetric (peer to peer vs. client to server). But some of our >> analysis does apply. In particular, dynamically replacing the short >> credentials by a long shared secret ( >> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B.3) >> would mitigate much of the risk. >> >> Thanks, >>    Yaron >> >> ----- >>  Hi, >>  I am interested in the PWD proposal at the meeting, and run through >> it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), >> >>  and have the following concerns: >> >> 1. In the document, it  says both Client and Server should be able to >> compute PE, which is derived from username, password, salt,etc. >>   That means Client or the user should also remember the salt value, in >> that >> case, salt is meaningless and can be replaced by a longer password. >>   This is quite different from the widely known usage of salt, e.g. in >> UNIX >> operating system, salt is not required to remember by the user, but by >> server to fetch locally by reference to the username. >>  And as far as I know, I am sure the authors also know that, other >> password >> based key exchanges protocols don't involve salt, but store a hash value >> of >> password among other things locally. >> >>> I realize that this is very different from the usage in UNIX operating >>> systems, but it is necessary, as the UNIX (or other) operating system >>> running the web server has to store the password. Storing the password >>> in >>> the clear on as an unsalted hash is worse than storing a salted hash >>> (or >>> "base" in the draft's terminology), so that is what the TLS server >>> does. The >>> use of base instead of password is not to protect the password during >>> handshake, but to protect it during storage on the server. >>> >>> Having said that, I think it is now very practical to take a list of >>> the >>> 100,000 most popular passwords on the web, a database of 10,000 salted >>> hashes (the file described in section 3.4), and find all the matches. >>> That's >>> 1,000,000,000 operations, which would take 15 minutes on a MacBook Air >>> (1.4 >>> GHz). I think the days of saying that a database of salted hashes makes >>> theft of the password file irrelevant should be over. Yes, I know that >>> with >>> unsalted hash it would be practical to test the 100,000,000 most >>> popular >>> passwords. >>> >>> session cookies somehow (e.g., via the BEAST attack): but if you don't >>> have my OBCs' private keys then you can't actually make use of my >>> cookies. >>> >>> With OBC cookie theft is not enough.  With OBC the attacker must get >>> at the private keys for the OBCs. >>> >>> Also, with OBC you get closer to true logout: destroy ("forget") your >>> OBC private keys and your sessions are as good as dead.  Moreover, the >>> user-agent, not the server, is in control of maximum session lifetime, >>> since there's no point in the server setting cookies that will outlive >>> the OBCs. >>> I we can find no other use case, we might want to rename it to "Origin >>> Bound Cookie". >>> >>> But that would require some interesting interaction between layers. >>> >>> Are all cookies received while using OBC considered (by the client!) >>> bound >>> to the OBC? If not, the client might use an old cookie after a logout >>> event, >>> leading to the server falsely detecting an attempt to forge a cookie. >>> Maybe >>> we need a new keyword on the cookie header. >>> >>> Where is the "logout" button?  If it's part of the website (in the >>> "canvas") how does the HTML/HTTP tell the browser to log out? Probably >>> best >>> to have it in the Chrome for sites where OBC are supported. >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nico@cryptonector.com Mon Dec 12 13:04:46 2011 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 F0D9921F867F for ; Mon, 12 Dec 2011 13:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ydWIP2Yq62jc for ; Mon, 12 Dec 2011 13:04:46 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3867F21F8678 for ; Mon, 12 Dec 2011 13:04:46 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 07342318074 for ; Mon, 12 Dec 2011 13:04:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=MeYAz0cTJWOEHYU1eGiMxMsJhQKGWYAMCydhh08ETTBo fVVOZR2eUZmHpI1Pgv2zZP065Rz8tPKCLwNo01tyI84qgpHs2iFwiRdMxqKReA2a 0bak9gtzIusVZELnGwfutzvm36mgWvPEpk3P2wWRf4UD+qhlfg+FQl76zlV/GPc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wmsx7C79EsRgzQyhLDMUysQjpq8=; b=E01aduK0D4m w6V4Xe51FohCLpa09DarC327HM9npyD74cum4kh5ibFB0sqKIJfd2IzUO9aG+PwV gdnIjHha0nR5Al/5oDgoqHXNoGEY5X9Adq+XYSFbZtAWNDnlQMgWNuQxsMd89lIj 8V/lt15n+i423dMN7K9a4IpBpmT7SbIU= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id E0F87318072 for ; Mon, 12 Dec 2011 13:04:44 -0800 (PST) Received: by dajz8 with SMTP id z8so7240846daj.31 for ; Mon, 12 Dec 2011 13:04:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.209.71 with SMTP id mk7mr38283724pbc.9.1323723884498; Mon, 12 Dec 2011 13:04:44 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 12 Dec 2011 13:04:44 -0800 (PST) In-Reply-To: <5af4a304c9258f2478144c4aaa54a4da.squirrel@www.trepanning.net> References: <4ECACDA3.4000003@gmail.com> <5af4a304c9258f2478144c4aaa54a4da.squirrel@www.trepanning.net> Date: Mon, 12 Dec 2011 15:04:44 -0600 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Yaron Sheffer , tls@ietf.org Subject: Re: [TLS] about the PWD Proposal 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, 12 Dec 2011 21:04:47 -0000 On Mon, Dec 12, 2011 at 2:52 PM, Dan Harkins wrote: > =C2=A0It's futile to throw more iterations at this problem. The solution = is > using a protocol based on a zero knowledge proof-- like the protocol in > question-- an get away from broken things like Wifi-Protected Access, > or any of the TLS-PSK ciphersuites, using passwords. If an adversary gets > access to a database of passwords then the contents of that database > should be assumed to be compromised even if they're salted and even if > they've been PBKDF2'd with 10,000 iterations. PBKDF and salting buys the compromised service and its users time to change all their passwords. I think this is critical from an operations point of view. Nico -- From mrex@sap.com Mon Dec 12 18:01:49 2011 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 3F2B41F0C47 for ; Mon, 12 Dec 2011 18:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.075 X-Spam-Level: X-Spam-Status: No, score=-10.075 tagged_above=-999 required=5 tests=[AWL=0.174, 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 v5LN+DuocNRn for ; Mon, 12 Dec 2011 18:01:48 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 247371F0C35 for ; Mon, 12 Dec 2011 18:01:47 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBD21iLF017863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Dec 2011 03:01:45 +0100 (MET) From: Martin Rex Message-Id: <201112130201.pBD21inR017744@fs4113.wdf.sap.corp> To: dharkins@lounge.org (Dan Harkins) Date: Tue, 13 Dec 2011 03:01:44 +0100 (MET) In-Reply-To: <5af4a304c9258f2478144c4aaa54a4da.squirrel@www.trepanning.net> from "Dan Harkins" at Dec 12, 11 12:52:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: yaronf.ietf@gmail.com, tls@ietf.org Subject: [TLS] OT: WPA2-PSK vs. TLS-PSK (was about the PWD Proposal) 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, 13 Dec 2011 02:01:49 -0000 Off-topic: Dan Harkins wrote: > > Below it's noted that if one has access to database of 10,000 salted > passwords and a dictionary of 100,000 of the most popular passwords > (assume that quite a few of them will be in the 10,000) that it's > possible to do a dictionary attack quite easily. Adding PBKDF2 would > slow that down but not much: > > http://www.theregister.co.uk/2011/01/11/amazon_cloud_wifi_cracking/ > > It's futile to throw more iterations at this problem. The solution is > using a protocol based on a zero knowledge proof-- like the protocol in > question-- an get away from broken things like Wifi-Protected Access, > or any of the TLS-PSK ciphersuites, using passwords. If an adversary gets > access to a database of passwords then the contents of that database > should be assumed to be compromised even if they're salted and even if > they've been PBKDF2'd with 10,000 iterations. WPA2-PSK is quite different from TLS-PSK in that one should *NOT* use a memorizable password for WPA2-PSK, but instead a very long and garbled one that is saved and automatically used. If you're using WPA2-PSK with an short or memorizable passwort, then you're not using the technology in the fashion that it is intended to be used. What WPA2-PSK does not provide (and where it differs from WPA2-Enterprise) is confidentiality from other rightful WPA2-PSK clients. AFAIK, only for WPA2-Enterprise every communication link will use a seperate set of keys, while WPA2-PSK clients will all use the same keys (and therefore can watch each others traffic). -Martin From dharkins@lounge.org Mon Dec 12 18:46:17 2011 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 22E9921F8783 for ; Mon, 12 Dec 2011 18:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 tDtShT0SNAN6 for ; Mon, 12 Dec 2011 18:46:16 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6080721F8753 for ; Mon, 12 Dec 2011 18:46:16 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E740DA88810C; Mon, 12 Dec 2011 18:46:14 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Dec 2011 18:46:15 -0800 (PST) Message-ID: <33d911044702574740e3bc9d63cc8e0a.squirrel@www.trepanning.net> In-Reply-To: <201112130201.pBD21inR017744@fs4113.wdf.sap.corp> References: <201112130201.pBD21inR017744@fs4113.wdf.sap.corp> Date: Mon, 12 Dec 2011 18:46:15 -0800 (PST) From: "Dan Harkins" To: mrex@sap.com 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: yaronf.ietf@gmail.com, tls@ietf.org Subject: Re: [TLS] OT: WPA2-PSK vs. TLS-PSK (was about the PWD Proposal) 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, 13 Dec 2011 02:46:17 -0000 On Mon, December 12, 2011 6:01 pm, Martin Rex wrote: > Off-topic: Indeed! :-) > Dan Harkins wrote: >> >> Below it's noted that if one has access to database of 10,000 salted >> passwords and a dictionary of 100,000 of the most popular passwords >> (assume that quite a few of them will be in the 10,000) that it's >> possible to do a dictionary attack quite easily. Adding PBKDF2 would >> slow that down but not much: >> >> http://www.theregister.co.uk/2011/01/11/amazon_cloud_wifi_cracking/ >> >> It's futile to throw more iterations at this problem. The solution is >> using a protocol based on a zero knowledge proof-- like the protocol in >> question-- an get away from broken things like Wifi-Protected Access, >> or any of the TLS-PSK ciphersuites, using passwords. If an adversary >> gets >> access to a database of passwords then the contents of that database >> should be assumed to be compromised even if they're salted and even if >> they've been PBKDF2'd with 10,000 iterations. > > WPA2-PSK is quite different from TLS-PSK in that one should *NOT* > use a memorizable password for WPA2-PSK, but instead a very long and > garbled one that is saved and automatically used. Actually the spec (-2007 version) provides for "an alternative manner of setting the PSK [which] uses the password-to-key algorithm defined [by PBKDF2]". It expressly says how to use a password. There isn't any normative language around it's use-- like "should not"-- but it does, informally, give a use case which is: "PSK-based authentication, typically managed by the pass-phrase hash method as described in [PBKDF2]." > If you're using WPA2-PSK with an short or memorizable passwort, > then you're not using the technology in the fashion that it is > intended to be used. Yes, you should not use a memorizable password but given the fact that your average human's ability to enter a large pseudo-random character string repeatedly (or have multiple average humans enter it once) in an error-free fashion is quite low that is exactly how it is used. > What WPA2-PSK does not provide (and where it differs from WPA2-Enterprise) > is confidentiality from other rightful WPA2-PSK clients. AFAIK, only > for WPA2-Enterprise every communication link will use a seperate > set of keys, while WPA2-PSK clients will all use the same keys > (and therefore can watch each others traffic). There is nothing in the protocol that prevents a single and unique PSK being assigned to a MAC address, it's just that that's not really how it's used. Again, that's because it's easier to just have a single PSK for everyone and make that PSK be easy to enter. Protocols that lose security when deployed in the easiest and most straightforward manner (i.e. the way everyone's gonna deploy it!) are extremely fragile. To tie it all back to what this thread used to be, when one uses a password with a protocol based on a zero knowledge proof there's a certain amount of robustness and misuse resistance. You should not share a password but if you do it will not give an adversary an advantage in determining the password because it still takes 1 active attack to some other protocol participant to check each candidate password in the dictionary-- do 50 attacks against a single device or 1 attack against 50 devices, it's no different. (By the way, the upcoming -2012 version of the 802.11 standard will have a secure replacement for WPA2-PSK that is based on a zero knowledge proof...coming soon to an 802.11 implementation near you!) regards, Dan. From dbrown@certicom.com Tue Dec 13 09:32:46 2011 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 E5B3321F8A57 for ; Tue, 13 Dec 2011 09:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, 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 t7XlJP3ipK7c for ; Tue, 13 Dec 2011 09:32:42 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9C87D21F891D for ; Tue, 13 Dec 2011 09:32:42 -0800 (PST) X-AuditID: 0a41282f-b7f4f6d000000b99-91-4ee78c39a4b0 Received: from XHT102CNC.rim.net (xht102cnc.rim.net [10.65.12.215]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 74.BB.02969.93C87EE4; Tue, 13 Dec 2011 17:32:41 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT102CNC.rim.net ([fe80::24bd:c715:2b6b:8f7d%11]) with mapi; Tue, 13 Dec 2011 12:32:41 -0500 From: Dan Brown To: 'Dan Harkins' Date: Tue, 13 Dec 2011 12:32:40 -0500 Thread-Topic: [TLS] about the PWD Proposal Thread-Index: Acym97Tapt4kwVyfR2+mDshktXw0lgSxM69g Message-ID: References: <1f90702381c4b1eb233430e28fb8fb47.squirrel@www.trepanning.net> In-Reply-To: <1f90702381c4b1eb233430e28fb8fb47.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXC5chzXdey57mfQf9OdYul/76wWHw638Xo wOSxZMlPJo9nu1+yBDBFNTDaJObl5ZcklqQqpKQWJ9sq+aSmJ+YoBBRlliUmVyq4ZBYn5yRm 5qYWKSlkptgqmSgpFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/ XQsLU0tdQyU7XSSQ8I87o+mzUMFHtYovm+YzNzA+kuti5OCQEDCRWHzRpouRE8gUk7hwbz1b FyMXh5BAL5PErz/vmSGcxYwSpx/uYQGpYhNQlbh/9BwzSLOIgLrElu+xIGFmAUWJ95fmgZWw AJVc+/YFzBYW0JQ4++chmC0ioCXx6dghZgjbSGLH9MeMIDavgIfEzPkfoBZPZpRY/e4LG0iC U8Bb4v6Nz+wgNiPQdd9PrWGCWCYucevJfCaIqwUkluw5zwxhi0q8fPyPFaJeVOJO+3pGiHo9 iRtTp7BB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYhTMzSg2MDNIzkvW K8rM1ctLLdnECE4SGvo7GPv2ah1iFOBgVOLhPVD33E+INbGsuDL3EKMEB7OSCO+XWqAQb0pi ZVVqUX58UWlOavEhRgtg0E1kluJOzgcmsLySeGMDAxSOkjivpvo9PyGBdGA6yk5NLUgtgmll 4uCUamDc8eYAk8fKi+f3/fh4o27+HaW+N2I3GDeGrbGLuxF/RKb63cVje8SlvHVqVA47P3r9 yXjtv3hhx6zc/zx3zk2VvqW3pfqizrOrXD4nwr9sUHnds95y7toFoafiLng7R3L9SvGp6/Ff c+ePb8cMLU6p+B/f+vNFrrcyOyS++m108MGmCNfC5E9mSizFGYmGWsxFxYkALF7m5SsDAAA= Cc: "tls@ietf.org" Subject: Re: [TLS] about the PWD Proposal 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, 13 Dec 2011 17:32:47 -0000 Hi Dan, 1) Various password-based key agreement schemes are specified in IEEE 1363.2= . I would encourage TLS, and IETF more generally, to use one of these, sinc= e they have already undergone standardization, and therefore some scrutiny.= Some even have published security proofs. IEEE 1363.2 includes a discussi= on of asymmetric and symmetric cases (client-server v. peer-peer.) 2) As you noted, your scheme is like SPEKE, but adds a mask, and seems to re= quire sending of an extra scalar, which may be a slight disadvantage. What= is the advantage of the masking, when compared to SPEKE? Best regards, Daniel Brown Research In Motion Limited > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Dan > Harkins > Sent: Saturday, November 19, 2011 3:13 PM > To: zhou.sujing@zte.com.cn > Cc: tls@ietf.org > Subject: Re: [TLS] about the PWD Proposal > > > Hello, > > On Fri, November 18, 2011 12:59 am, zhou.sujing@zte.com.cn wrote: > > Hi, > > I am interested in the PWD proposal at the meeting, and run through > > it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), > > and have the following concerns: > > Thank you for your interest. > > > 1. In the document, it says both Client and Server should be able to > > compute PE, which is derived from username, password, salt,etc. > > That means Client or the user should also remember the salt value, in > > that case, salt is meaningless and can be replaced by a longer password. > > This is quite different from the widely known usage of salt, e.g. in > > UNIX operating system, salt is not required to remember by the user, but > > by server to fetch locally by reference to the username. > > And as far as I know, I am sure the authors also know that, other > > password based key exchanges protocols don't involve salt, but store a > > hash value of password among other things locally. > > As Yoav mentioned, the salt is used to protect against server > compromise. If the salt is chosen randomly by the server (as it should > be) then an adversary who obtains possession of the database of salted > passwords is required to effectively do an off-line dictionary attack > against each entry in the database to recover passwords. > > The salt is not stored by the client, it is communicated to the client > in the ServerKeyExchange. All the client needs to do is remember the > password. > > > 2. From the figure in the PPT shown at the meeting, I cann't see why the > > protocol should use both "private" and "mask" values, in my opinion, onl= y > > "mask " value shall be OK. > > private value is redundent, and not helpful in security improvement. > > because the current derived shared key is PE^{private_a*private_b} > > according to this document=A3=AC and > > after removing private value, it will be PE^{mask_a*mask_b} > > and private, mask value are both generated locally and not transporte= d > > on the wire, so it does not make much difference except making it more > > complex. > > The private value is used in the final exponentiation (or, equivalently, > point multiplication) to derive the pre-master secret. Each private > value is sent to the peer masked by modulo addition (which means that a > passive attacker cannot guess the private since there are q different > pairs of numbers that sum to any given number less than q and a > probability of 1/q is effectively the same as guessing a DH exponential > which we all assume is too hard). The mask is removed through modular > multiplication (or equivalently, point addition) in a manner that prevents > the disclosure of the private value. > > Private is definitely not redundant! > > > 3. Now I only talk about the security of the simplified version (as in > > above point 2) > > after simplification the protocol is easier to analysize, it is just > > like an ordinary DH exchange except that the base group generator is PE > > instead of g. > > So the security is reduced to the PE, is it a good group generator > > which has large order? if not then it is insecure. > > Unfortunatly the authors failed to analysize this crucial point. > > An ordinary DH with PE as the generator is the SPEKE exchange. This > is decidedly NOT an ordinary DH with PE as the generator. As mentioned > above, both mask and private are crucial and such a "masked" exchange is > not ordinary, PE as the generator notwithstanding. > > Please look at the exchange again in more detail. > > > Thank you for your patience! > > Thank you, again, for your interest! Perhaps you can implement it. :-) > > regards, > > Dan. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From dharkins@lounge.org Tue Dec 13 21:36:41 2011 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 0178511E80B6 for ; Tue, 13 Dec 2011 21:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, 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 N-XjI8Zf1-CI for ; Tue, 13 Dec 2011 21:36:40 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E5BE411E808C for ; Tue, 13 Dec 2011 21:36:39 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 490501022404A; Tue, 13 Dec 2011 21:36:39 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 13 Dec 2011 21:36:39 -0800 (PST) Message-ID: <388c6680e6dc343cc6056fdd94d11493.squirrel@www.trepanning.net> In-Reply-To: References: <1f90702381c4b1eb233430e28fb8fb47.squirrel@www.trepanning.net> Date: Tue, 13 Dec 2011 21:36:39 -0800 (PST) From: "Dan Harkins" To: "Dan Brown" 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] about the PWD Proposal 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, 14 Dec 2011 05:36:41 -0000 Hi Dan, There is no technical advantage to the key exchange in the PWD proposal when compared to SPEKE. regards, Dan. On Tue, December 13, 2011 9:32 am, Dan Brown wrote: > Hi Dan, > > 1) Various password-based key agreement schemes are specified in IEEE > 1363.2. I would encourage TLS, and IETF more generally, to use one of > these, since they have already undergone standardization, and therefore > some scrutiny. Some even have published security proofs. IEEE 1363.2 > includes a discussion of asymmetric and symmetric cases (client-server v. > peer-peer.) > > 2) As you noted, your scheme is like SPEKE, but adds a mask, and seems to > require sending of an extra scalar, which may be a slight disadvantage. > What is the advantage of the masking, when compared to SPEKE? > > Best regards, > > Daniel Brown > Research In Motion Limited > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Dan >> Harkins >> Sent: Saturday, November 19, 2011 3:13 PM >> To: zhou.sujing@zte.com.cn >> Cc: tls@ietf.org >> Subject: Re: [TLS] about the PWD Proposal >> >> >> Hello, >> >> On Fri, November 18, 2011 12:59 am, zhou.sujing@zte.com.cn wrote: >> > Hi, >> > I am interested in the PWD proposal at the meeting, and run through >> > it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), >> > and have the following concerns: >> >> Thank you for your interest. >> >> > 1. In the document, it says both Client and Server should be able to >> > compute PE, which is derived from username, password, salt,etc. >> > That means Client or the user should also remember the salt value, >> in >> > that case, salt is meaningless and can be replaced by a longer >> password. >> > This is quite different from the widely known usage of salt, e.g. >> in >> > UNIX operating system, salt is not required to remember by the user, >> but >> > by server to fetch locally by reference to the username. >> > And as far as I know, I am sure the authors also know that, other >> > password based key exchanges protocols don't involve salt, but store a >> > hash value of password among other things locally. >> >> As Yoav mentioned, the salt is used to protect against server >> compromise. If the salt is chosen randomly by the server (as it should >> be) then an adversary who obtains possession of the database of salted >> passwords is required to effectively do an off-line dictionary attack >> against each entry in the database to recover passwords. >> >> The salt is not stored by the client, it is communicated to the client >> in the ServerKeyExchange. All the client needs to do is remember the >> password. >> >> > 2. From the figure in the PPT shown at the meeting, I cann't see why >> the >> > protocol should use both "private" and "mask" values, in my opinion, >> only >> > "mask " value shall be OK. >> > private value is redundent, and not helpful in security >> improvement. >> > because the current derived shared key is PE^{private_a*private_b} >> > according to this document£¬ and >> > after removing private value, it will be PE^{mask_a*mask_b} >> > and private, mask value are both generated locally and not >> transported >> > on the wire, so it does not make much difference except making it more >> > complex. >> >> The private value is used in the final exponentiation (or, >> equivalently, >> point multiplication) to derive the pre-master secret. Each private >> value is sent to the peer masked by modulo addition (which means that a >> passive attacker cannot guess the private since there are q different >> pairs of numbers that sum to any given number less than q and a >> probability of 1/q is effectively the same as guessing a DH exponential >> which we all assume is too hard). The mask is removed through modular >> multiplication (or equivalently, point addition) in a manner that >> prevents >> the disclosure of the private value. >> >> Private is definitely not redundant! >> >> > 3. Now I only talk about the security of the simplified version (as in >> > above point 2) >> > after simplification the protocol is easier to analysize, it is >> just >> > like an ordinary DH exchange except that the base group generator is >> PE >> > instead of g. >> > So the security is reduced to the PE, is it a good group generator >> > which has large order? if not then it is insecure. >> > Unfortunatly the authors failed to analysize this crucial point. >> >> An ordinary DH with PE as the generator is the SPEKE exchange. This >> is decidedly NOT an ordinary DH with PE as the generator. As mentioned >> above, both mask and private are crucial and such a "masked" exchange is >> not ordinary, PE as the generator notwithstanding. >> >> Please look at the exchange again in more detail. >> >> > Thank you for your patience! >> >> Thank you, again, for your interest! Perhaps you can implement it. :-) >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > From zhou.sujing@zte.com.cn Tue Dec 13 21:56:50 2011 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 09B4711E8089 for ; Tue, 13 Dec 2011 21:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.31 X-Spam-Level: X-Spam-Status: No, score=-99.31 tagged_above=-999 required=5 tests=[AWL=2.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_UTF8=0.152, 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 zDbOAn2+58dg for ; Tue, 13 Dec 2011 21:56:49 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E32A321F85B1 for ; Tue, 13 Dec 2011 21:56:19 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Wed, 14 Dec 2011 13:39:44 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 43852.2347441809; Wed, 14 Dec 2011 13:56:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBE5u1UJ048179; Wed, 14 Dec 2011 13:56:02 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: "tls@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 14 Dec 2011 13:55:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-14 13:56:03, Serialize complete at 2011-12-14 13:56:03 Content-Type: multipart/alternative; boundary="=_alternative 002098AE48257966_=" X-MAIL: mse01.zte.com.cn pBE5u1UJ048179 Subject: [TLS] =?utf-8?b?6L2s5Y+ROiBSZTogICAgICDCtMOwwrjCtDogUmU6ICBPVDog?= =?utf-8?q?WPA2-PSK_vs=2E_TLS-PSK______=28was__about_the_PWD_Proposal=29?= 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, 14 Dec 2011 05:56:50 -0000 This is a multipart message in MIME format. --=_alternative 002098AE48257966_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCi0tLS0tIOi9rOWPkeS6uiDlkajoi4/pnZkwMDEz MjgzMS91c2VyL3p0ZV9sdGQg5pe26Ze0IDIwMTEtMTItMTQgMTM6NTUgLS0tLS0NCg0K5ZGo6IuP 6Z2ZMDAxMzI4MzEvdXNlci96dGVfbHRkDQoyMDExLTEyLTE0IDEzOjUzDQoNCuaUtuS7tuS6ug0K IkRhbiBIYXJraW5zIiA8ZGhhcmtpbnNAbG91bmdlLm9yZz4NCuaKhOmAgQ0KDQrkuLvpopgNCuet lOWkjTogUmU6ICAgICAgwrTDsMK4wrQ6IFJlOiBbVExTXSBPVDogV1BBMi1QU0sgdnMuIFRMUy1Q U0sgICAgICAod2FzICBhYm91dCANCnRoZSBQV0QgUHJvcG9zYWwpDQoNCg0KDQoNCg0KUmVnYXJk c35+fg0KDQotU3VqaW5nIFpob3UNCg0KIkRhbiBIYXJraW5zIiA8ZGhhcmtpbnNAbG91bmdlLm9y Zz4g5YaZ5LqOIDIwMTEtMTItMTQgMTM6NDI6MTk6DQoNCj4gDQo+ICAgSGVsbG8sDQo+IA0KPiBP biBUdWUsIERlY2VtYmVyIDEzLCAyMDExIDU6MjggcG0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24g d3JvdGU6DQo+ID4gUmVnYXJkc35+fg0KPiA+DQo+ID4gLVN1amluZyBaaG91DQo+ID4NCj4gPiB0 bHMtYm91bmNlc0BpZXRmLm9yZyDDkMK0w5PDmiAyMDExLTEyLTEzIDEwOjQ2OjE1Og0KPiA+DQo+ ID4+DQo+ID4+IE9uIE1vbiwgRGVjZW1iZXIgMTIsIDIwMTEgNjowMSBwbSwgTWFydGluIFJleCB3 cm90ZToNCj4gPj4gPiBPZmYtdG9waWM6DQo+ID4+DQo+ID4+ICAgSW5kZWVkISA6LSkNCj4gPj4N Cj4gPj4gPiBEYW4gSGFya2lucyB3cm90ZToNCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gICBQcm90 b2NvbHMgdGhhdCBsb3NlIHNlY3VyaXR5IHdoZW4gZGVwbG95ZWQgaW4gdGhlIGVhc2llc3QgYW5k IG1vc3QNCj4gPj4gc3RyYWlnaHRmb3J3YXJkIG1hbm5lciAoaS5lLiB0aGUgd2F5IGV2ZXJ5b25l J3MgZ29ubmEgZGVwbG95IGl0ISkgYXJlDQo+ID4+IGV4dHJlbWVseSBmcmFnaWxlLiBUbyB0aWUg aXQgYWxsIGJhY2sgdG8gd2hhdCB0aGlzIHRocmVhZCB1c2VkIHRvIGJlLA0KPiA+PiB3aGVuIG9u ZSB1c2VzIGEgcGFzc3dvcmQgd2l0aCBhIHByb3RvY29sIGJhc2VkIG9uIGEgemVybyBrbm93bGVk Z2UNCj4gPj4gcHJvb2YNCj4gPj4gdGhlcmUncyBhIGNlcnRhaW4gYW1vdW50IG9mIHJvYnVzdG5l c3MgYW5kIG1pc3VzZSByZXNpc3RhbmNlLiBZb3UNCj4gPj4gc2hvdWxkDQo+ID4+IG5vdCBzaGFy ZSBhIHBhc3N3b3JkIGJ1dCBpZiB5b3UgZG8gaXQgd2lsbCBub3QgZ2l2ZSBhbiBhZHZlcnNhcnkg YW4NCj4gPj4gYWR2YW50YWdlIGluIGRldGVybWluaW5nIHRoZSBwYXNzd29yZCBiZWNhdXNlIGl0 IHN0aWxsIHRha2VzIDEgYWN0aXZlDQo+ID4+IGF0dGFjayB0byBzb21lIG90aGVyIHByb3RvY29s IHBhcnRpY2lwYW50IHRvIGNoZWNrIGVhY2ggY2FuZGlkYXRlDQo+ID4+IHBhc3N3b3JkIGluIHRo ZSBkaWN0aW9uYXJ5LS0gZG8gNTAgYXR0YWNrcyBhZ2FpbnN0IGEgc2luZ2xlIGRldmljZSBvcg0K PiA+PiAxIGF0dGFjayBhZ2FpbnN0IDUwIGRldmljZXMsIGl0J3Mgbm8gZGlmZmVyZW50Lg0KPiA+ DQo+ID4gSXMgdGhlIFBXRCBwcm90b2NvbCBpbiBkaXNjdXNzaW9uIGEgb25lIGJhc2VkIG9uIHpl cm8ga25vd2xlZGdlIHByb29mPw0KPiA+IEkgZG91YnQgaXQuIFNlcnZlciBrbm93cyB0aGUgc2Fs dGVkIHB3ZCBhdCBsZWFzdCwgYWJzb2x1dGx5IG5vdCB6ZXJvDQo+ID4ga25vd2xlZGdlLg0KPiAN Cj4gICBBIHplcm8ga25vd2xlZGdlIHByb29mIGRvZXMgbm90IG1lYW4gdGhhdCBib3RoIHNpZGVz IGtub3cgbm90aGluZywNCj4gaXQgbWVhbnMgdGhhdCBhIHByb29mIG9mIGtub3dsZWRnZSBvZiBh IHNlY3JldCBpcyBwcm92aWRlZCB3aXRob3V0DQo+IGV4cG9zaW5nIGFueXRoaW5nIGFib3V0IHRo ZSBzZWNyZXQgKG9yIHNvbWUgZGVyaXZhdGl2ZSBvZiB0aGUgc2VjcmV0KS4NCj4gVGhlIG9ubHkg dGhpbmcgYW4gYWR2ZXJzYXJ5IGNhbiBsZWFybiBpcyB3aGV0aGVyIGEgc2luZ2xlIGd1ZXNzIG9m IHRoZQ0KPiBwYXNzd29yZCBpcyBjb3JyZWN0IGFuZCBpdCB0YWtlcyBhbiBhY3RpdmUgYXR0YWNr IHRvIGxlYXJuIHRoYXQuDQoNCnByb29mIG9mIGtub3dsZWRnZSBzaG91bGQgYmUgZGlmZiB3aXRo IHplcm8ta25vd2xlZGdlLCBpZiB0aGUgcHJvdG9jb2wgDQp1bmRlciBkaXNjdXNzaW9uIA0KaXMg YSByZWFsIHplcm8ta25vd2xlZGdlIG9yIGEgcHJvb2Ygb2Yga25vd2xlZGdlLCBhIHByb29mIHNo b3VsZCBiZSBnaXZlbiANCnNob3dpbmcgdGhhdA0KYXR0YWNrZXIncyB2aWV3IGNhbm5vdCBiZSB1 bm5lZ2xpZ2libGUgZGlzdGluZ3Vpc2hhYmxlIGZyb20gcmFuZG9tIGNvbnRleHQgDQppbiB0aGUg Y2FzZSBvZiB6ZXJvIGtub3dsZWRnZQ0KLCBvciB0aGUga25vd2xlZGdlIGNhbiBiZSBleHRyYWN0 ZWQgaW4gdGhlIGNhc2Ugb2YgcHJvb2Ygb2Yga25vd2xlZGdlLg0KDQpBcyBmYXIgYXMgSSBrbm93 IHRoZSBtb3N0IGVmZmllbnQgUG9LIGlzIGJhc2VkIG9uIFNjaG5vcnIncyBzY2hlbWUsIHdoaWxl IA0Kbm8gUHdkIGJhc2VkIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMNCmNhbiBiZSBjYWxsZWQgYSBa SyBwcm90b2NvbCBvciBhIFBvS+OAgg0KDQoNCj4gDQo+ID4gYW5kIGRpY3Rpb25hcnkgYXR0YWNr IGlzIG5vdCBuZWVkZWQsIHNpbmNlIHdoYXQgaXMgcmVhbHkgbmVlZGVkIHRvDQo+ID4gYXV0aGVu dGljYXRlIHRoZSBjbGllbnQNCj4gPiBpcyB0aGUgY2FsY3VsYXRlZCBQRSAoc2FsdGVkIHB3ZCku DQo+ID4NCj4gPiAgTWF5YmUgSSBtaXNzZWQgc29tZXRoaW5nLCBJZiBJIGFtIHdyb25nIHBsZWFz ZSBwb2ludCBvdXQuICBUaGFua3MhDQo+IA0KPiAgIFdlbGwgb2YgY291cnNlIGlmIGFuIGFkdmVy c2FyeSBrbm93cyB0aGUgY2FsY3VsYXRlZCBQRSBpdCBjYW4NCj4gZG8gYWxsIHNvcnRzIG9mIHRo aW5ncy4gSG93IGRvZXMgdGhlIGFkdmVyc2FyeSBsZWFybiB0aGUgY2FsY3VsYXRlZA0KPiBQRSB0 aG91Z2g/IFRoZSBwcm90b2NvbCBpcyByZXNpc3RhbnQgdG8gYW55IGF0dGFjayB0aGUgYWR2ZXJz YXJ5IGNhbg0KPiBsYXVuY2ggYWdhaW5zdCBpdC4gSWYgdGhlIHNlcnZlcidzIGRhdGFiYXNlIG9m IHBhc3N3b3JkcyAoc2FsdGVkIG9yIG5vdCkNCj4gaXMgY29tcHJvbWlzZWQgdGhlbiBhbGwgYmV0 cyBhcmUgb2ZmIGJ1dCB0aGF0J3Mgbm90IGFuIGF0dGFjayBhZ2FpbnN0DQo+IHRoZSBwcm90b2Nv bC4NCg0KU28gLCBpdCBpcyBubyBwb2ludCBjb25zaWRlcmluZyBvZiBzYWx0IHNob3VsZCBiZSB0 YWtlbiBoZXJlLg0KDQo+IA0KPiAgIHJlZ2FyZHMsDQo+IA0KPiAgIERhbi4NCj4gDQo+IA0KPiAN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 002098AE48257966_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODAgZmFj ZT0ic2Fucy1zZXJpZiI+LS0tLS0g6L2s5Y+R5Lq6IOWRqOiLj+mdmTAwMTMyODMxL3VzZXIvenRl X2x0ZA0K5pe26Ze0IDIwMTEtMTItMTQgMTM6NTUgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+5ZGo6IuP6Z2ZMDAxMzI4MzEvdXNlci96dGVfbHRkPC9iPjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTEyLTE0IDEzOjUz PC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O0RhbiBIYXJraW5zJnF1b3Q7ICZsdDtkaGFya2luc0Bsb3VuZ2Uub3JnJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+5oqE6YCBPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPuetlOWkjTogUmU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7wrTDsMK4wrQ6DQpSZTogW1RMU10g T1Q6IFdQQTItUFNLIHZzLiBUTFMtUFNLICZuYnNwOyAmbmJzcDsgJm5ic3A7KHdhcyAmbmJzcDth Ym91dA0KdGhlIFBXRCBQcm9wb3NhbCk8L2ZvbnQ+PGEgaHJlZj1Ob3RlczovLy80ODI1NzhGQzAw MTFDNDA0L0NEMkYzMjVEODYwQzc0RDE0ODI1NkM1MjAwNDQ3NUY3LzBBQUUxNzVEQUNCNjI2QzI0 ODI1Nzk2NjAwMUY1OTIwPumTvuaOpTwvYT48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1amlu ZyBaaG91PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7RGFuIEhhcmtp bnMmcXVvdDsgJmx0O2RoYXJraW5zQGxvdW5nZS5vcmcmZ3Q7DQrlhpnkuo4gMjAxMS0xMi0xNCAx Mzo0MjoxOTo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7IEhlbGxvLDxicj4NCiZn dDsgPGJyPg0KJmd0OyBPbiBUdWUsIERlY2VtYmVyIDEzLCAyMDExIDU6MjggcG0sIHpob3Uuc3Vq aW5nQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHN+fn48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgLVN1amluZyBaaG91PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IHRscy1ib3VuY2VzQGlldGYub3JnIMOQwrTDk8OaIDIwMTEtMTItMTMgMTA6NDY6MTU6 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT24g TW9uLCBEZWNlbWJlciAxMiwgMjAxMSA2OjAxIHBtLCBNYXJ0aW4gUmV4IHdyb3RlOjxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyBPZmYtdG9waWM6PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgJm5ic3A7IEluZGVlZCEgOi0pPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgJmd0OyBEYW4gSGFya2lucyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7 IFByb3RvY29scyB0aGF0IGxvc2Ugc2VjdXJpdHkgd2hlbiBkZXBsb3llZCBpbiB0aGUNCmVhc2ll c3QgYW5kIG1vc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IHN0cmFpZ2h0Zm9yd2FyZCBtYW5uZXIgKGku ZS4gdGhlIHdheSBldmVyeW9uZSdzIGdvbm5hIGRlcGxveQ0KaXQhKSBhcmU8YnI+DQomZ3Q7ICZn dDsmZ3Q7IGV4dHJlbWVseSBmcmFnaWxlLiBUbyB0aWUgaXQgYWxsIGJhY2sgdG8gd2hhdCB0aGlz IHRocmVhZA0KdXNlZCB0byBiZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdoZW4gb25lIHVzZXMgYSBw YXNzd29yZCB3aXRoIGEgcHJvdG9jb2wgYmFzZWQgb24gYSB6ZXJvDQprbm93bGVkZ2U8YnI+DQom Z3Q7ICZndDsmZ3Q7IHByb29mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGVyZSdzIGEgY2VydGFpbiBh bW91bnQgb2Ygcm9idXN0bmVzcyBhbmQgbWlzdXNlIHJlc2lzdGFuY2UuDQpZb3U8YnI+DQomZ3Q7 ICZndDsmZ3Q7IHNob3VsZDxicj4NCiZndDsgJmd0OyZndDsgbm90IHNoYXJlIGEgcGFzc3dvcmQg YnV0IGlmIHlvdSBkbyBpdCB3aWxsIG5vdCBnaXZlIGFuIGFkdmVyc2FyeQ0KYW48YnI+DQomZ3Q7 ICZndDsmZ3Q7IGFkdmFudGFnZSBpbiBkZXRlcm1pbmluZyB0aGUgcGFzc3dvcmQgYmVjYXVzZSBp dCBzdGlsbCB0YWtlcw0KMSBhY3RpdmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGF0dGFjayB0byBzb21l IG90aGVyIHByb3RvY29sIHBhcnRpY2lwYW50IHRvIGNoZWNrIGVhY2ggY2FuZGlkYXRlPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBwYXNzd29yZCBpbiB0aGUgZGljdGlvbmFyeS0tIGRvIDUwIGF0dGFja3Mg YWdhaW5zdCBhIHNpbmdsZQ0KZGV2aWNlIG9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAxIGF0dGFjayBh Z2FpbnN0IDUwIGRldmljZXMsIGl0J3Mgbm8gZGlmZmVyZW50Ljxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBJcyB0aGUgUFdEIHByb3RvY29sIGluIGRpc2N1c3Npb24gYSBvbmUgYmFzZWQg b24gemVybyBrbm93bGVkZ2UNCnByb29mPzxicj4NCiZndDsgJmd0OyBJIGRvdWJ0IGl0LiBTZXJ2 ZXIga25vd3MgdGhlIHNhbHRlZCBwd2QgYXQgbGVhc3QsIGFic29sdXRseSBub3QNCnplcm88YnI+ DQomZ3Q7ICZndDsga25vd2xlZGdlLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgQSB6ZXJv IGtub3dsZWRnZSBwcm9vZiBkb2VzIG5vdCBtZWFuIHRoYXQgYm90aCBzaWRlcyBrbm93IG5vdGhp bmcsPGJyPg0KJmd0OyBpdCBtZWFucyB0aGF0IGEgcHJvb2Ygb2Yga25vd2xlZGdlIG9mIGEgc2Vj cmV0IGlzIHByb3ZpZGVkIHdpdGhvdXQ8YnI+DQomZ3Q7IGV4cG9zaW5nIGFueXRoaW5nIGFib3V0 IHRoZSBzZWNyZXQgKG9yIHNvbWUgZGVyaXZhdGl2ZSBvZiB0aGUgc2VjcmV0KS48YnI+DQomZ3Q7 IFRoZSBvbmx5IHRoaW5nIGFuIGFkdmVyc2FyeSBjYW4gbGVhcm4gaXMgd2hldGhlciBhIHNpbmds ZSBndWVzcyBvZg0KdGhlPGJyPg0KJmd0OyBwYXNzd29yZCBpcyBjb3JyZWN0IGFuZCBpdCB0YWtl cyBhbiBhY3RpdmUgYXR0YWNrIHRvIGxlYXJuIHRoYXQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5wcm9vZiBvZiBrbm93bGVkZ2Ugc2hvdWxkIGJlIGRpZmYgd2l0aCB6 ZXJvLWtub3dsZWRnZSwNCmlmIHRoZSBwcm90b2NvbCB1bmRlciBkaXNjdXNzaW9uIDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aXMgYSByZWFsIHplcm8ta25vd2xlZGdlIG9yIGEg cHJvb2Ygb2Yga25vd2xlZGdlLA0KYSBwcm9vZiBzaG91bGQgYmUgZ2l2ZW4gc2hvd2luZyB0aGF0 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5hdHRhY2tlcidzIHZpZXcgY2Fubm90 IGJlIHVubmVnbGlnaWJsZSBkaXN0aW5ndWlzaGFibGUNCmZyb20gcmFuZG9tIGNvbnRleHQgaW4g dGhlIGNhc2Ugb2YgemVybyBrbm93bGVkZ2U8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiwgb3IgdGhlIGtub3dsZWRnZSBjYW4gYmUgZXh0cmFjdGVkIGluIHRoZSBjYXNlIG9mDQpw cm9vZiBvZiBrbm93bGVkZ2UuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5BcyBmYXIgYXMgSSBrbm93IHRoZSBtb3N0IGVmZmllbnQgUG9LIGlzIGJhc2VkIG9uDQpTY2hu b3JyJ3Mgc2NoZW1lLCB3aGlsZSBubyBQd2QgYmFzZWQgYXV0aGVudGljYXRpb24gc2NoZW1lczwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Y2FuIGJlIGNhbGxlZCBhIFpLIHByb3Rv Y29sIG9yIGEgUG9L44CCPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBhbmQgZGljdGlvbmFyeSBhdHRhY2sgaXMgbm90IG5l ZWRlZCwgc2luY2Ugd2hhdCBpcyByZWFseSBuZWVkZWQNCnRvPGJyPg0KJmd0OyAmZ3Q7IGF1dGhl bnRpY2F0ZSB0aGUgY2xpZW50PGJyPg0KJmd0OyAmZ3Q7IGlzIHRoZSBjYWxjdWxhdGVkIFBFIChz YWx0ZWQgcHdkKS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7TWF5YmUgSSBt aXNzZWQgc29tZXRoaW5nLCBJZiBJIGFtIHdyb25nIHBsZWFzZSBwb2ludCBvdXQuDQombmJzcDtU aGFua3MhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyBXZWxsIG9mIGNvdXJzZSBpZiBhbiBh ZHZlcnNhcnkga25vd3MgdGhlIGNhbGN1bGF0ZWQgUEUgaXQgY2FuPGJyPg0KJmd0OyBkbyBhbGwg c29ydHMgb2YgdGhpbmdzLiBIb3cgZG9lcyB0aGUgYWR2ZXJzYXJ5IGxlYXJuIHRoZSBjYWxjdWxh dGVkPGJyPg0KJmd0OyBQRSB0aG91Z2g/IFRoZSBwcm90b2NvbCBpcyByZXNpc3RhbnQgdG8gYW55 IGF0dGFjayB0aGUgYWR2ZXJzYXJ5IGNhbjxicj4NCiZndDsgbGF1bmNoIGFnYWluc3QgaXQuIElm IHRoZSBzZXJ2ZXIncyBkYXRhYmFzZSBvZiBwYXNzd29yZHMgKHNhbHRlZCBvcg0Kbm90KTxicj4N CiZndDsgaXMgY29tcHJvbWlzZWQgdGhlbiBhbGwgYmV0cyBhcmUgb2ZmIGJ1dCB0aGF0J3Mgbm90 IGFuIGF0dGFjayBhZ2FpbnN0PGJyPg0KJmd0OyB0aGUgcHJvdG9jb2wuPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5TbyAsIGl0IGlzIG5vIHBvaW50IGNvbnNpZGVyaW5n IG9mIHNhbHQgc2hvdWxkIGJlDQp0YWtlbiBoZXJlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyByZWdhcmRzLDxicj4NCiZndDsg PGJyPg0KJmd0OyAmbmJzcDsgRGFuLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtT ZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRh aW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNw O3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlv bi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2Nv bmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2Fy ZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7 YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9z ZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7 YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2Fy ZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5i c3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFs Jm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJl Jm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVk Jm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNw O25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21l c3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3Ro aXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNw O2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1Nw YW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002098AE48257966_=-- From internet-drafts@ietf.org Wed Dec 14 07:59:06 2011 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 0E2B021F8B5D; Wed, 14 Dec 2011 07:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 61V2rZlFG8tJ; Wed, 14 Dec 2011 07:59:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD79921F8B53; Wed, 14 Dec 2011 07:59:05 -0800 (PST) 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: 3.64p1 Message-ID: <20111214155905.11035.63224.idtracker@ietfa.amsl.com> Date: Wed, 14 Dec 2011 07:59:05 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-10.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: Wed, 14 Dec 2011 15:59:06 -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 Grou= p of the IETF. Title : Transport Layer Security (TLS) Cached Information Extens= ion Author(s) : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-10.txt Pages : 14 Date : 2011-12-14 This document defines a Transport Layer Security (TLS) extension for cached information. This extension allows the TLS client to inform a server of cached information from previous TLS handshakes, allowing the server to omit sending cached static information to the client during the TLS handshake protocol exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-cached-info-10.txt From Hannes.Tschofenig@gmx.net Wed Dec 14 08:08:06 2011 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 C989A21F8BF0 for ; Wed, 14 Dec 2011 08:08:06 -0800 (PST) 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 1wxWky+MQyvv for ; Wed, 14 Dec 2011 08:08:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E268D21F8BEF for ; Wed, 14 Dec 2011 08:08:05 -0800 (PST) Received: (qmail 29073 invoked by uid 0); 14 Dec 2011 16:08:04 -0000 Received: from 84.35.81.2 by www031.gmx.net with HTTP; Wed, 14 Dec 2011 17:08:03 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Wed, 14 Dec 2011 17:08:03 +0100 From: "Hannes Tschofenig" Message-ID: <20111214160803.137810@gmx.net> MIME-Version: 1.0 To: tls@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+0vTlzXpm0eY3yv+voqRkObB1J4CoN12bx+oBdFh K/Guud6k7EyDxO4a4LdU+sQwT8TXErVgbd+A== Content-Transfer-Encoding: 8bit X-GMX-UID: tKyabrFUeSEqZZIAqXUh2Ql+IGRvb0D4 Subject: [TLS] draft-ietf-tls-cached-info-10.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: Wed, 14 Dec 2011 16:08:06 -0000 Hi all, Ekr suggested during the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of draft-wouters-tls-oob-pubkey-02. This week I had a chat with Joe about draft-ietf-tls-cached-info-10.txt. He added me as a co-author and encouraged me to interact with the group to move it forward. With version 10 I refreshed the document since it expired. I am planning to reach out to the smart objects folks to double-check whether it meets their requirements and to solicit reviews. In any case, please review the document and share your comments with us. Ciao Hannes From n.mavrogiannopoulos@gmail.com Wed Dec 14 08:35:59 2011 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 17FEA21F8C2B for ; Wed, 14 Dec 2011 08:35:59 -0800 (PST) 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 3bFMhDCFV+Fp for ; Wed, 14 Dec 2011 08:35:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5930021F8B6C for ; Wed, 14 Dec 2011 08:35:58 -0800 (PST) Received: by eeke49 with SMTP id e49so990945eek.31 for ; Wed, 14 Dec 2011 08:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=i5m9If8A94RcYM8olpSupW5NeEznTQPyoEe4pUdBuhI=; b=Kq7VdNJ37ZjWcOhL7T3m4YysMzbRYnR2r8V9R5EtgG4JNTzDWCxBvUfJt9C7gLDPmC mcURudjjuHF5zxoGKIyPSloQjO8aCIXNvHt+pu6pbLqXA9BySYoiNJyNkhKWBv0+49d1 B3KxuJPD7j/za9o4awr1Of2cxBU983aTky+yY= MIME-Version: 1.0 Received: by 10.180.14.69 with SMTP id n5mr6274810wic.13.1323880557481; Wed, 14 Dec 2011 08:35:57 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.81.65 with HTTP; Wed, 14 Dec 2011 08:35:57 -0800 (PST) In-Reply-To: <20111214160803.137810@gmx.net> References: <20111214160803.137810@gmx.net> Date: Wed, 14 Dec 2011 17:35:57 +0100 X-Google-Sender-Auth: bK3kjgPBr4WpOmjG6YPH72MLAcc Message-ID: From: Nikos Mavrogiannopoulos To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-10.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: Wed, 14 Dec 2011 16:35:59 -0000 On Wed, Dec 14, 2011 at 5:08 PM, Hannes Tschofenig wrote: > Hi all, > Ekr suggested during the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of draft-wouters-tls-oob-pubkey-02. [...] > In any case, please review the document and share your comments with us. Hello, Some comments. page 5: The hash algorithm used to calculate hash values SHALL be the hash algorithm that was used to generate the Finished message in the handshake exchange from which the hashed information was cached. Hash algorithm identifiers are defined in the RFC 5246 [RFC5246] HashAlgorithm registry. The finished message doesn't use a hash algorithm, but rather a PRF. That PRF is based on SHA1 in TLS 1.0 and SHA256 in TLS 1.2, but there is no guarantee that a PRF must be based on a hash. Why doesn't this extension negotiate the hash on the previous (non-cached) run? page 8: I cannot understand the meaning of 5 and 5.1. Does it mean that the certificate message sent is: struct { CachedObject ASN.1Cert<1..2^24-1>; } Certificate; If this is the meaning then "Substitution syntax is defined by expanding the syntax of the opaque ASN.1Cert structure" should be better phrased. I'd use "The certificate message is replaced by the CachedCertificate message defined as:" ... same applies in 5.2. page 3: "Significant benefits can be achieved in low bandwidth and high latency networks". Out of curiosity. Is TLS being used in any low-bandwidth channels, where this extension is needed? (latency low or high doesn't really matter since the round-trips are not affected by this extension) regards, Nikos From mrex@sap.com Thu Dec 15 11:15:01 2011 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 B80FF21F8549 for ; Thu, 15 Dec 2011 11:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 2JGF34UDlHYf for ; Thu, 15 Dec 2011 11:15:01 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0250021F8548 for ; Thu, 15 Dec 2011 11:15:00 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBFJEutR027509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Dec 2011 20:14:56 +0100 (MET) From: Martin Rex Message-Id: <201112151914.pBFJEtWC027666@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joe Salowey) Date: Thu, 15 Dec 2011 20:14:55 +0100 (MET) In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> from "Joe Salowey" at Nov 30, 11 01:34:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and 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, 15 Dec 2011 19:15:01 -0000 Joe Salowey wrote: > > The chairs would like to see if there is consensus in the TLS working > group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc > as working group items. > > Please respond to the following by December 14, 2011 : Sorry, I'm late. > > - Do you object to taking these drafts on as working group items? While I do not object, I do not see a need for these to become WG items. I believe they could remain individual submissions and still be discussed in the WG. But I want to leave any decisions to those who intend to contribute to that work. > > - Would you contribute time to review and provide text for the > documents when needed? Unlikely. > > - Do you object to standards track status for these documents? Yes, I do. I am not aware of a rationale why they *should* go on the standards track. We are not actually short of TLS ciphersuite proposals. Standards track should be reserved to documents that are considered generally useful and where it is intended to recommend implementing them and where the WG has the commitment to drive the document through the whole standardization process (i.e. beyond PS). With respect to the "2 maturity levels" discussion on the ietf mailing list, the reason why there are so many RFCs at proposed and only very few progressing further is a lack of both, commitment by the WG to work the document further and lack of general usefulness of a non-marginal part of those documents. -Martin From hannes.tschofenig@nsn.com Sun Dec 18 02:30:40 2011 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 C72A321F84C5 for ; Sun, 18 Dec 2011 02:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.648 X-Spam-Level: X-Spam-Status: No, score=-104.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 7bvzpMc9UDbJ for ; Sun, 18 Dec 2011 02:30:37 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2E42C21F84C1 for ; Sun, 18 Dec 2011 02:30:36 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBIAUWTw022082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Dec 2011 11:30:33 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBIAUSxK022940 for ; Sun, 18 Dec 2011 11:30:32 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 11:29:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBD6F.DEA7E737" Date: Sun, 18 Dec 2011 12:30:56 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38072@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [TLS] draft-ietf-tls-cached-info-10.txt Thread-Index: Acy9cCCb9bJDz3F4S7GA7Ct801NRZA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Dec 2011 10:29:06.0608 (UTC) FILETIME=[DEEE4B00:01CCBD6F] X-Mailman-Approved-At: Sun, 18 Dec 2011 03:57:21 -0800 Subject: Re: [TLS] draft-ietf-tls-cached-info-10.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: Sun, 18 Dec 2011 10:30:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBD6F.DEA7E737 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nikos,=20 thanks for your quick feedback.=20 Your remark regarding the hash algorithm is correct. There are a few other questions, namely a) Should there be more than one hash function be used? I would say that in general the opinion is "yes" because of the crypto-agility requirement.=20 b) When there is more than one algorithm what registry should be used? The registry for HashAlgorithm registry established with RFC 5246 is one possible option but clearly defined for a different purpose. When someone adds a new hash algorithm purely for usage with the TLS cached info extension then the question arises of how valuable this is for what it was initially created for by RFC 5246. I personally would just create a separate registry rather than overloading an existing one. c) Should there be a negotiation of hash algorithms, as you suggest, or rather a pure indication. I am OK with negotiation. d) What should be the hash algorithm that is mandatory-to-implement? I would not pick one. Your interpretation of the text in Section 5.1 is correct. There is definitely a chance to improve the text.=20 Regarding your question about the usage of TLS in communication environments with low bandwidth, and high loss rate. Yes, there are communities who run IP-based protocols, including DTLS/TLS on constrained devices, such as sensors. Have a look at this workshop report: http://tools.ietf.org/html/draft-iab-smart-object-workshop-06 =20 I would appreciate your feedback on the remaining questions concerning the hash algorithm topic. I will produce an updated version of the draft that clarifies the text in Section 5.1. Ciao Hannes On Wed, Dec 14, 2011 at 5:08 PM, Hannes Tschofenig wrote: > Hi all, > Ekr suggested during the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of draft-wouters-tls-oob-pubkey-02. [...] > In any case, please review the document and share your comments with us. Hello, Some comments. page 5: The hash algorithm used to calculate hash values SHALL be the hash algorithm that was used to generate the Finished message in the handshake exchange from which the hashed information was cached. Hash algorithm identifiers are defined in the RFC 5246 [RFC5246] HashAlgorithm registry. The finished message doesn't use a hash algorithm, but rather a PRF. That PRF is based on SHA1 in TLS 1.0 and SHA256 in TLS 1.2, but there is no guarantee that a PRF must be based on a hash. Why doesn't this extension negotiate the hash on the previous (non-cached) run? page 8: I cannot understand the meaning of 5 and 5.1. Does it mean that the certificate message sent is: struct { CachedObject ASN.1Cert<1..2^24-1>; } Certificate; If this is the meaning then "Substitution syntax is defined by expanding the syntax of the opaque ASN.1Cert structure" should be better phrased. I'd use "The certificate message is replaced by the CachedCertificate message defined as:" ... same applies in 5.2. page 3: "Significant benefits can be achieved in low bandwidth and high latency networks". Out of curiosity. Is TLS being used in any low-bandwidth channels, where this extension is needed? (latency low or high doesn't really matter since the round-trips are not affected by this extension) regards, Nikos ------_=_NextPart_001_01CCBD6F.DEA7E737 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [TLS] draft-ietf-tls-cached-info-10.txt

Hi Nikos, =

thanks for your quick = feedback.

Your remark regarding = the hash algorithm is correct. There are a few other questions, = namely

a)      Should there be more than one hash function be used? I would say = that in general the opinion is “yes” because of the crypto-agility requirement.

b)      When there is more = than one algorithm what registry should be used? The registry = for HashAlgorithm = registry established with RFC 5246 is one possible option but clearly defined = for a different purpose. When someone adds a new hash algorithm purely = for usage with the TLS cached info extension then the question arises of how valuable this = is for what it was initially created for by RFC 5246. I personally would just create = a separate registry rather than overloading an existing one.

c)      Should there be a negotiation of hash algorithms, as you suggest, or rather a pure = indication. I am OK with negotiation.

d)      What should be the = hash algorithm that is mandatory-to-implement? I would not pick one.

Your interpretation of the text in Section 5.1 is correct. There is definitely a = chance to improve the text.

Regarding your question about the usage of TLS in communication environments = with low bandwidth, and high loss rate. Yes, there are communities who run IP-based = protocols, including DTLS/TLS on constrained devices, such as sensors. Have = a look at this workshop report: = http://tools.ietf.org/html/draft-iab-smart-object-workshop-06=  

I = would appreciate your feedback on the remaining questions concerning the = hash algorithm topic. I will produce an updated version of the draft = that clarifies the text in Section 5.1.

Ciao
Hannes

On Wed, Dec 14, 2011 = at 5:08 PM, Hannes Tschofenig

<Hannes.Tschofenig at gmx.net> wrote:

> Hi all,

> Ekr suggested during the Taipei IETF TLS meeting to remove the = functionality of conveying a public key fingerprint from = draft-wouters-tls-oob-pubkey. I did that already during that meeting = with the submission of = draft-wouters-tls-oob-pubkey-02.

[...]

> In any case, please review the document and share your = comments with us.

Hello,

 Some comments.

page 5:

The hash algorithm used to calculate hash values SHALL be the = hash

   algorithm that was used to generate the Finished = message in the

   handshake exchange from which the hashed information = was cached.

   Hash algorithm identifiers are defined in the RFC 5246 = [RFC5246]

   HashAlgorithm registry.

The finished message doesn't use a hash algorithm, but rather a = PRF.

That PRF is based on SHA1 in TLS 1.0 and SHA256 in TLS 1.2, but = there

is = no guarantee that a PRF must be based on a hash. Why doesn't = this

extension negotiate the hash on the previous (non-cached) = run?

page 8:

 I cannot understand the meaning of 5 and 5.1. Does it mean = that the

certificate message sent is:

struct {

           &n= bsp;  CachedObject ASN.1Cert<1..2^24-1>;

} = Certificate;

If = this is the meaning then "Substitution syntax is defined = by

expanding the syntax of the opaque ASN.1Cert structure" should = be

better phrased. I'd use "The certificate message is replaced = by the

CachedCertificate message defined as:"

...

same applies in 5.2.

page 3:

   "Significant benefits can be achieved in low = bandwidth and high

   latency networks".

Out of curiosity. Is TLS being used in any low-bandwidth = channels,

where this extension is needed? (latency low or high doesn't = really

matter since the round-trips are not affected by this = extension)

regards,

Nikos

------_=_NextPart_001_01CCBD6F.DEA7E737-- From robert.cragie@gridmerge.com Mon Dec 19 11:56:55 2011 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 41A1421F847B for ; Mon, 19 Dec 2011 11:56:55 -0800 (PST) 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 sdWpEsvoStKi for ; Mon, 19 Dec 2011 11:56:54 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 67DC611E8080 for ; Mon, 19 Dec 2011 11:56:54 -0800 (PST) Received: from client-82-26-167-12.pete.adsl.virginmedia.com ([82.26.167.12] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1RcjKJ-0002ba-NR for tls@ietf.org; Mon, 19 Dec 2011 19:56:48 +0000 Message-ID: <4EEF9719.3050506@gridmerge.com> Date: Mon, 19 Dec 2011 19:57:13 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tls@ietf.org References: <201112151914.pBFJEtWC027666@fs4113.wdf.sap.corp> In-Reply-To: <201112151914.pBFJEtWC027666@fs4113.wdf.sap.corp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070707030406010403060206" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and 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: Mon, 19 Dec 2011 19:56:55 -0000 This is a cryptographically signed message in MIME format. --------------ms070707030406010403060206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 15/12/2011 7:14 PM, Martin Rex wrote: >> - Do you object to taking these drafts on as working group items? > While I do not object, I do not see a need for these to become WG items= =2E > I believe they could remain individual submissions and still be > discussed in the WG. But I want to leave any decisions to those who in= tend > to contribute to that work. We have been going around the houses on this somewhat. I have no=20 particular preference either but would like to take the quickest route=20 and was under the assumption this would be the quickest route. >> - Do you object to standards track status for these documents? > Yes, I do. > I am not aware of a rationale why they *should* go on the standards tra= ck. > We are not actually short of TLS ciphersuite proposals. > > Standards track should be reserved to documents that are considered > generally useful and where it is intended to recommend implementing > them and where the WG has the commitment to drive the document > through the whole standardization process (i.e. beyond PS). Code using these documents is currently being implemented in ZigBee IP=20 and SEP 2.0 platforms. So from that point of view they are unlikely to=20 remain esoteric. It is for the very reason you state that I would prefer = them to be standards track or at least reflect the status of RFC 5288=20 and RFC 5289 on which they are based. Robert --------------ms070707030406010403060206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIxOTE5NTcxM1owIwYJKoZI hvcNAQkEMRYEFCxzFhu7B10kCrqfx/6t2FTZu3EHMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQACgTwcwK7HVEnKWwe6lWNx ysr79iAoYT/97KPfCsRCiQlcbRay/2u0Hlx6oZBL8shTof+YrZP4qM0hjQi9gyJl/k3IvvDM H7xG0lHZAt0YbWxLJbH4o5m+pA7YpTGJGLjR5gd+wf9TdSaWUUo+lKgH3yDzy9f0CRsoYrvq dPun2pCi2vKNDhicXweufTlWLNXXExZhYqIZD3fzRGXueuMDAb6QsOGfjJ0T9AevuMvRo925 AcoWCXg0rDzW4dFAt9c5cIZjLJgiya7JBFbNb+z5XGSJOrbbkKyTujNGbDLiiNrCZ7ME9hP4 AxnyLI4BdTPrjEu4GP4nZWnRHY9awJnGAAAAAAAA --------------ms070707030406010403060206-- From fweimer@bfk.de Tue Dec 20 05:15:34 2011 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 3928921F8B0B for ; Tue, 20 Dec 2011 05:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 oybSbH9QyeqE for ; Tue, 20 Dec 2011 05:15:33 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFFA21F8880 for ; Tue, 20 Dec 2011 05:15:33 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RczXX-0008Ri-GR for tls@ietf.org; Tue, 20 Dec 2011 13:15:31 +0000 Received: by bfk.de with local id 1RczXX-0001WR-Dn for tls@ietf.org; Tue, 20 Dec 2011 13:15:31 +0000 From: Florian Weimer To: tls@ietf.org Date: Tue, 20 Dec 2011 13:15:31 +0000 Message-ID: <82ehvzidu4.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 13:15:34 -0000 TCP has the property that connection shutdowns can overtake application data if connections are used in full-duplex mode. Here's an example: X sends a fatal TLS alert to Y X shuts down the connection Y sends data to X X receives from Y, sends RST to signal data loss to Y Y receives RST At this point, when Y tries to send further data, it will receive EPIPE from the sockets API. When it tries to read data, it will receive ECONNRESET. According to the socket API sepcification, there is no way to access the initial TLS alert. Note that this behavior is not related to the SO_LINGER socket option. (I see this with an OpenJDK server and a GNUTLS client, when the server sends a certificate_unknown alert immediately after receiving the Certificate message. The client never receives it.) What is the best way to deal with this? I plan to avoid closing the connection immediately after sending the alert, essentially waiting for the client to close the connection. (There will be a short timeout, but denial-of-service issues have to be dealt with out-of-band anyway.) Are there any better options? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From marsh@extendedsubset.com Tue Dec 20 10:12:38 2011 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 C0F7721F85EF for ; Tue, 20 Dec 2011 10:12:38 -0800 (PST) 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 j5hjcOgY+4zg for ; Tue, 20 Dec 2011 10:12:38 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4473A21F85A7 for ; Tue, 20 Dec 2011 10:12:38 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Rd4B3-000INY-Qv; Tue, 20 Dec 2011 18:12:37 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D4DC76067; Tue, 20 Dec 2011 18:12:35 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19+BhcOsy0iIAzwodCDFC3h0e53P7jF34Y= Message-ID: <4EF0D014.1050907@extendedsubset.com> Date: Tue, 20 Dec 2011 12:12:36 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Florian Weimer References: <82ehvzidu4.fsf@mid.bfk.de> In-Reply-To: <82ehvzidu4.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 18:12:38 -0000 On 12/20/2011 07:15 AM, Florian Weimer wrote: > TCP has the property that connection shutdowns can overtake application > data if connections are used in full-duplex mode. > > Here's an example: > > X sends a fatal TLS alert to Y > X shuts down the connection > Y sends data to X > X receives from Y, sends RST to signal data loss to Y This would seem to be against the spirit of http://tools.ietf.org/html/rfc793 (section 3.5. Closing a Connection) which says "Users must keep reading connections they close for sending until the TCP says no more data." > Y receives RST > > At this point, when Y tries to send further data, it will receive EPIPE > from the sockets API. When it tries to read data, it will receive > ECONNRESET. According to the socket API sepcification, there is no way > to access the initial TLS alert. My interpretation is that RSTs are generally to be avoided by properly-coded applications and a fatal TLS alert should not prevent the graceful close of the TCP socket. I have heard of client apps that crash badly upon receiving an RST. (Alternatively this could be used to argue that they should be sent much more frequently, but that's another discussion :-) - Marsh From nico@cryptonector.com Tue Dec 20 10:22:10 2011 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 CD13D21F853E for ; Tue, 20 Dec 2011 10:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] 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 c2gViohwyE5k for ; Tue, 20 Dec 2011 10:22:09 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2289621F85AE for ; Tue, 20 Dec 2011 10:22:09 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id D092A26C073 for ; Tue, 20 Dec 2011 10:22:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=U8Mz75l4kFP39rkP2mR5ZdLh5N3TldPSNc/G/qwpmC8C d9NFvykNybh2icnvkw+S5K8otIdwnLO/dXFnYakeRe1yCBEEOxRHTDpZxbGZQYhc J0Nc8Eh62YpfOYsw+0tIrwDKQZHRxqlpTCvA6WdyVe/cqFlVcPSo9PRhu7IDjq4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=vocaG9Lb7E/nnghjU9c0pe2rWf4=; b=LQXPiERSSk8 P0vRD/mfLiEiB85P9OpDtv//oyaEEV+Vaog580XQu8CqR1jZWZkInjm+B7e5lpnY Du8SmH/QA2A4bGteEFxcPw99KxMH28G6ced7UXsaAGRk6gYcYal4vUdUpr7m6MBj BmQrICBToE3oCQ8FF5fcRNOunmk8oSWM= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id B6D2E26C06F for ; Tue, 20 Dec 2011 10:22:08 -0800 (PST) Received: by pbdd12 with SMTP id d12so5214975pbd.31 for ; Tue, 20 Dec 2011 10:22:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr4865806pbv.90.1324405328357; Tue, 20 Dec 2011 10:22:08 -0800 (PST) Received: by 10.68.32.227 with HTTP; Tue, 20 Dec 2011 10:22:08 -0800 (PST) In-Reply-To: <82ehvzidu4.fsf@mid.bfk.de> References: <82ehvzidu4.fsf@mid.bfk.de> Date: Tue, 20 Dec 2011 12:22:08 -0600 Message-ID: From: Nico Williams To: Florian Weimer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 18:22:11 -0000 On Tue, Dec 20, 2011 at 7:15 AM, Florian Weimer wrote: > What is the best way to deal with this? =C2=A0I plan to avoid closing the > connection immediately after sending the alert, essentially waiting for > the client to close the connection. =C2=A0(There will be a short timeout,= but > denial-of-service issues have to be dealt with out-of-band anyway.) Your approach seems to be a variable-sized queue with a minimum time on the queue for each socket on that queue. A variant on this: use a fixed-sized queue. Create a fixed-sized queue, shutdown() SHUT_RDWR (but don't close()) after sending the fatal alert, add the socket to the queue; if the queue is full take out the oldest socket and close() it. No need for a reaper thread: properly behaved clients will cause those sockets to close, leaving no state beyond a file descriptor around on the server side; bad clients will not be able to do anything more serious than a) consume a bound number of server-side resources, b) cause legitimate clients to get RST before being able to see fatal alerts. The right size for the queue will depend on the latency for sending, receiving and processing the fatal alert message relative to typical connection lifetime. But it will probably be easiest to size the shutdown socket queue as a fraction of the max open connections you can/want to handle. A fixed-sized queue seems to have better DoS protection: you know what is the max number of sockets in this state is that the attacker can force you to have, and you convert a resource consumption DoS into a case where bad clients can cause some legitimate clients will get an RST without first seeing a fatal alert. > Are there any better options? I think a fixed-sized queue w/o a reaper thread is likely easier to code and is simpler to analyze regarding DoS attacks than a variable size queue with a reaper thread and a "reasonable" timeout per-socket on that queue. Nico -- From SRS0=Qyu2=7A=acm.org=bmoeller@srs.kundenserver.de Tue Dec 20 10:32:10 2011 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 A33B121F84A2 for ; Tue, 20 Dec 2011 10:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.626 X-Spam-Level: X-Spam-Status: No, score=-101.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 HZw0mVDs1onX for ; Tue, 20 Dec 2011 10:32:10 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id CF74321F84B4 for ; Tue, 20 Dec 2011 10:32:09 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MPrBi-1RZCrv3iAE-0053DZ; Tue, 20 Dec 2011 19:32:06 +0100 Received: by qadz3 with SMTP id z3so4377945qad.10 for ; Tue, 20 Dec 2011 10:32:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.98.8 with SMTP id o8mr4268402qan.79.1324405924738; Tue, 20 Dec 2011 10:32:04 -0800 (PST) Received: by 10.224.19.196 with HTTP; Tue, 20 Dec 2011 10:32:04 -0800 (PST) In-Reply-To: <4EF0D014.1050907@extendedsubset.com> References: <82ehvzidu4.fsf@mid.bfk.de> <4EF0D014.1050907@extendedsubset.com> Date: Tue, 20 Dec 2011 19:32:04 +0100 Message-ID: From: Bodo Moeller To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d9a6aeb69c04b48a4898 X-Provags-ID: V02:K0:/M1vpbR871vVLM/jWWQuO1PTDPMFLdgYGtssxsTc2Ba jCA+lBqgVuh0ynG3K/QRhptU6X6xh9+rJWd5dYrVjt9c+A+4g4 lPqG1QFZR56f/eeqs7Kajr0RaTS9TZ6XEgtAx7CHVve1a5OkHE py4MYRk7Juk/To07I6OWYC5+Nqri0QeXZ+s1u0xJvt7OJ1r5YG usrrn0PqtonCf+5hUw8x2OPyr8Ud+W2/cPkowZGwUgmGSp3CaL HmtqM6RuG3zuelnFpYhNCreZ8aPNoW5asGliaFg0juCGSADLSo 92ECTv5+R29ZaAn0l9+ztplfZUPIxVNC8QjXXSbjkBA7goExf2 7VLTRYd5mW3hPOUu3xDyws83GfKXazDjI+gSRcEqsFMpJJoDzQ j/YE21zH6u5Y1RUYfAcU53EKexBr+PVeoMCatnVVde+0hRMWS9 uI7qN Subject: Re: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 18:32:39 -0000 --20cf3074d9a6aeb69c04b48a4898 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 20, 2011 at 7:12 PM, Marsh Ray wrote: > X shuts down the connection >> Y sends data to X >> X receives from Y, sends RST to signal data loss to Y >> > > This would seem to be against the spirit of > http://tools.ietf.org/html/rfc793 (section 3.5. Closing a Connection) > which says "Users must keep reading connections they close for sending > until the TCP says no more data." > Note that RFC 1122 section 4.2.2.13 specifies that A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. I'm guessing that on typical systems, this behavior for close() *does* depend on the SO_LINGER parameters, though. Bodo --20cf3074d9a6aeb69c04b48a4898 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2011 at 7:12 PM, Marsh Ray <marsh@extendedsubset.com> w= rote:
=A0
=A0 X shuts down the connection
=A0 Y sends data to X
=A0 X receives from Y, sends RST to signal data loss to Y
=
=A0
This would seem to be against the spirit of
http://tool= s.ietf.org/html/rfc793 (section 3.5. Closing a Connection) which says &= quot;Users must keep reading connections they close for sending until the T= CP says no more data."

Note that RFC 1122 section 4.2.2.13 specifies that
            A host MAY implement a "half-duplex" TCP close sequen=
ce, so
            that an application that has called CLOSE cannot continue to
            read data from the connection.  If such a host issues a
            CLOSE call while received data is still pending in TCP, or
            if new data is received after CLOSE is called, its TCP
            SHOULD send a RST to show that data was lost.

I'm guessing that on typi= cal systems, this behavior for close() *does* depend on the SO_LINGER param= eters, though.

Bodo

--20cf3074d9a6aeb69c04b48a4898-- From nico@cryptonector.com Tue Dec 20 10:41:09 2011 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 4F51F11E8083 for ; Tue, 20 Dec 2011 10:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 zv3YIJVqp6mt for ; Tue, 20 Dec 2011 10:41:08 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id D6D9811E807F for ; Tue, 20 Dec 2011 10:41:08 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 8E79F3B8072 for ; Tue, 20 Dec 2011 10:41:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=yfE4eHleyaBtFDZ2Q3SYg m+24HNDeOU7w3AQ2OFQuaquIKZMkemZ3fPRpl6T+i3U9eI1LdZ71lhc03BrymbvC KLQIOJsAKbNj1E2LesDqFO9tw/xhpLGmLsifD7uPCi7mjnB5f4iTbBOTn4GvaY6J M1cSIPF2vTps9WaLXGpxjA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FFkr9FfF1vecWI+msTAz T16797w=; b=M0kyldYjWPkjt5iUi3cbgGM2yuAZj+ecIGl11YcvvoCkvc61tvSB ED5agQdBSMPD/RmxhxMZTYuTe+50kFAGPlzYa6vgB25P+8MYU1aGi4+frPia41w/ 8OIH+nfOoVxvXRoZ01Tu0Zg8wJRiaOBk86i0CBEHhtQzEEQlDfb0nAs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 7E2033B806C for ; Tue, 20 Dec 2011 10:41:08 -0800 (PST) Received: by dajz8 with SMTP id z8so6347870daj.31 for ; Tue, 20 Dec 2011 10:41:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.191.34 with SMTP id gv2mr3617486pbc.101.1324406468179; Tue, 20 Dec 2011 10:41:08 -0800 (PST) Received: by 10.68.32.227 with HTTP; Tue, 20 Dec 2011 10:41:08 -0800 (PST) In-Reply-To: References: <82ehvzidu4.fsf@mid.bfk.de> <4EF0D014.1050907@extendedsubset.com> Date: Tue, 20 Dec 2011 12:41:08 -0600 Message-ID: From: Nico Williams To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 18:41:09 -0000 Ah, yes, just set SO_LINGER and a reasonable linger time (and have the socket in non-blocking mode, but that probably goes without saying). Nico -- From mrex@sap.com Tue Dec 20 13:25:48 2011 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 B03F421F8560 for ; Tue, 20 Dec 2011 13:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 0WvRj0m9qzUL for ; Tue, 20 Dec 2011 13:25:48 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3021F84BA for ; Tue, 20 Dec 2011 13:25:47 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBKLPhDH014764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 22:25:44 +0100 (MET) From: Martin Rex Message-Id: <201112202125.pBKLPh03000374@fs4113.wdf.sap.corp> To: fweimer@bfk.de (Florian Weimer) Date: Tue, 20 Dec 2011 22:25:43 +0100 (MET) In-Reply-To: <82ehvzidu4.fsf@mid.bfk.de> from "Florian Weimer" at Dec 20, 11 01:15:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 21:25:48 -0000 Florian Weimer wrote: > > TCP has the property that connection shutdowns can overtake application > data if connections are used in full-duplex mode. > > Here's an example: > > X sends a fatal TLS alert to Y > X shuts down the connection > Y sends data to X > X receives from Y, sends RST to signal data loss to Y > Y receives RST > > At this point, when Y tries to send further data, it will receive EPIPE > from the sockets API. When it tries to read data, it will receive > ECONNRESET. According to the socket API sepcification, there is no way > to access the initial TLS alert. Note that this behavior is not related > to the SO_LINGER socket option. Could you point me to the particular section of the socket API spec that defines such behaviour (for the TCP stack of Y) to be correct? The way that I read rfc1122 section 4.2.2.13, the TCP stack of Y is only allowed to kill data upon the Y app performing a close operation on the socket. If the app on Y does not call close when receiving the EPIPE from send(), then the data must IMHO remain readable, and the ECONNRESET will follow the TLS alert. -Martin From dharkins@lounge.org Tue Dec 20 13:38:10 2011 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 27AC31F0C35 for ; Tue, 20 Dec 2011 13:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 4e5+hY22pE32 for ; Tue, 20 Dec 2011 13:38:09 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 70E0721F8560 for ; Tue, 20 Dec 2011 13:38:09 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 431BE1022404A; Tue, 20 Dec 2011 13:38:09 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 20 Dec 2011 13:38:09 -0800 (PST) Message-ID: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> Date: Tue, 20 Dec 2011 13:38:09 -0800 (PST) From: "Dan Harkins" To: cfrg@irtf.org 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: [TLS] password-based key exchange 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, 20 Dec 2011 21:38:10 -0000 Hello, I proposed a new TLS ciphersuite using a zero knowledge proof at IETF 82 in Taipei. The draft is here: http://tools.ietf.org/html/draft-harkins-tls-pwd-01 At the TLS WG meeting I was requested to ask people on the CFRG list with expertise in this field to take a look at it. So here I am, asking. If someone has some spare cycles this holiday season, if you just gotta get away from the relatives, or you are just feeling in the giving mood, please take a look and comment. Any analysis on this would be greatly appreciated. (I tried to do a formal proof but I cannot, and that's what's prompting this). I can describe the key exchange broadly here. There are subtle differences in the draft-- like one side keeps a salted version of the password and communicates the salt during a HELLO message-- that don't affect the exchange. It is symmetric so I can describe it from one side's perspective. The side being described is "local" and the other side is "peer", it goes like this: Given: local ID, peer ID, password, an agreed-upon set of domain parameters defining a finite field group (it works will elliptic curve crypto too) and using two function: - E = HashToElement(d) which takes some data, d, and hashes into the finite field to return an element, E. - x = H(y) returns a random stream, x, given some input, y. The key exchange works like this: 1. PE = HashToElement(local_ID | peer_ID | password) gets a "password element" There is an ordering defined in the draft to ensure that the IDs are put in the same order on each side. 2. generate 2 random numbers between 0 and the order of the group, q: 0 < local_rand, local_mask < q 3. compute a scalar and an element: local_scalar = (local_rand + local_mask) mod q local_element = 1/(PE^local_mask) mod p where p is the prime and q is the order. Send local_scalar and local_element to other side 4. receive peer_scalar and peer_element from other side 5. compute shared key, K K = (PE^peer_scalar * peer_element)^local_rand mod p = (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p = PE^(peer_rand*local_rand) mod p 6. compute a confirmation local_confirm = H(K, local_scalar | local_element | peer_scalar | peer_element) send confirmation to peer 7. receive peer's confirmation, calculate verifier verifier = H(K, peer_scalar | peer_element | local_scalar | local_element) if verifier equals peer's confirmation the peer is authenticated. The peer does the same thing but from its perspective it is "local" and the side described above is "peer". Thank you in advance for any analysis that can be provided on this exchange. regards, Dan. From mrex@sap.com Tue Dec 20 13:53:22 2011 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 F063311E80A4 for ; Tue, 20 Dec 2011 13:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 fqE6BP675kGZ for ; Tue, 20 Dec 2011 13:53:22 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 245AF11E8097 for ; Tue, 20 Dec 2011 13:53:21 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBKLrJQW023810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 22:53:19 +0100 (MET) From: Martin Rex Message-Id: <201112202153.pBKLrIVh001975@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 20 Dec 2011 22:53:18 +0100 (MET) In-Reply-To: <201112202125.pBKLPh03000374@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 20, 11 10:25:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 20 Dec 2011 21:53:23 -0000 Martin Rex wrote: > > Florian Weimer wrote: > > > > TCP has the property that connection shutdowns can overtake application > > data if connections are used in full-duplex mode. > > > > Here's an example: > > > > X sends a fatal TLS alert to Y > > X shuts down the connection > > Y sends data to X > > X receives from Y, sends RST to signal data loss to Y > > Y receives RST > > > > At this point, when Y tries to send further data, it will receive EPIPE > > from the sockets API. When it tries to read data, it will receive > > ECONNRESET. According to the socket API sepcification, there is no way > > to access the initial TLS alert. Note that this behavior is not related > > to the SO_LINGER socket option. > > Could you point me to the particular section of the socket API spec > that defines such behaviour (for the TCP stack of Y) to be correct? > > The way that I read rfc1122 section 4.2.2.13, the TCP stack of Y is > only allowed to kill data upon the Y app performing a close operation > on the socket. If the app on Y does not call close when receiving > the EPIPE from send(), then the data must IMHO remain readable, > and the ECONNRESET will follow the TLS alert. Application calling close() upon receiving EPIPE from send() refers to "shutdown(socket,SHUT_WR)" in terms of BSD sockets. With respect to this paragraph of rfc1122 4.2.2.13: A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. This means that a TCP implementation could decide to treat shutdown(socket,SHUT_WR) and shutdown(socket,SHUT_RD) always and exactly the same as shutdown(socket,SHUT_RDWR), i.e. not support a unidirectional/partial closure. Who is inappropriately calling shutdown(socket,SHUT_WR) after a failed send() in the scenario that you're looking at? If there is none such code, then the TCP stack is not conforming to rfc1122. -Martin From chris@randomnonce.org Tue Dec 20 14:12:57 2011 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 B67B921F858D for ; Tue, 20 Dec 2011 14:12:57 -0800 (PST) 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 B+FPZxX84emP for ; Tue, 20 Dec 2011 14:12:57 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 169E621F858C for ; Tue, 20 Dec 2011 14:12:57 -0800 (PST) Received: by ggnk5 with SMTP id k5so5768588ggn.31 for ; Tue, 20 Dec 2011 14:12:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.72.74 with SMTP id b10mr3456831obv.69.1324419176508; Tue, 20 Dec 2011 14:12:56 -0800 (PST) Received: by 10.182.28.162 with HTTP; Tue, 20 Dec 2011 14:12:56 -0800 (PST) X-Originating-IP: [98.117.34.149] In-Reply-To: <20111214160803.137810@gmx.net> References: <20111214160803.137810@gmx.net> Date: Tue, 20 Dec 2011 17:12:56 -0500 Message-ID: From: Chris Richardson To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-10.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, 20 Dec 2011 22:12:57 -0000 Section 3: ... struct { CachedObject cached_info<1..2^16-1>; } CachedInformation; ... Section 4.1: ... which MAY contain zero or more cached objects (CachedObject).... I believe that, in Section 3, you want cached_info<0..2^16-1> On Wed, Dec 14, 2011 at 11:08 AM, Hannes Tschofenig wrote: > Hi all, > > Ekr suggested during the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of draft-wouters-tls-oob-pubkey-02. > > This week I had a chat with Joe about draft-ietf-tls-cached-info-10.txt. He added me as a co-author and encouraged me to interact with the group to move it forward. > > With version 10 I refreshed the document since it expired. > > I am planning to reach out to the smart objects folks to double-check whether it meets their requirements and to solicit reviews. > > In any case, please review the document and share your comments with us. > > Ciao > Hannes > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From sfluhrer@cisco.com Tue Dec 20 14:17:39 2011 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 02D4121F863E for ; Tue, 20 Dec 2011 14:17:39 -0800 (PST) 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 29+5b9o9-vK1 for ; Tue, 20 Dec 2011 14:17:38 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 48DC521F85EF for ; Tue, 20 Dec 2011 14:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=3664; q=dns/txt; s=iport; t=1324419458; x=1325629058; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nPGmmEZ8L1UUqLUwo0LrooHlHbqIf3YznXyn/szOEak=; b=jbyL9uwLxerNR1r4f8HKBrpszfE3ivznHgpGwOYlh1CEiDjjOUpTrh54 sab9G2E9RwTTEcXMuudn71+jZTQ6Oz63Mmcb8ox7hef4mtIHvs+aFXz+R m/e6U7ECUwQcWnSd/58BV1fStSK2oN1DIKStyJAVkhiexfcck/K9cciUr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAMQI8U6rRDoG/2dsb2JhbABDmzCQVYEFgXIBAQEDAQEBAQ8BHQoxAwsMBAIBCA4DBAEBCwYIDwEGASYfCQgBAQQBEggBGYdYCJh4AZ4viHSCNWMEiDefGQ X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; d="scan'208";a="21777492" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Dec 2011 22:17:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBKMHbHM030361; Tue, 20 Dec 2011 22:17:37 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 14:17:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2011 14:17:33 -0800 Message-ID: In-Reply-To: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] password-based key exchange Thread-Index: Acy/X7M8gT00/SasSmuwbuoIFdk5ugABQuWg References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> From: "Scott Fluhrer (sfluhrer)" To: "Dan Harkins" , X-OriginalArrivalTime: 20 Dec 2011 22:17:36.0496 (UTC) FILETIME=[2D9FEF00:01CCBF65] X-Mailman-Approved-At: Tue, 20 Dec 2011 14:47:24 -0800 Cc: tls@ietf.org Subject: Re: [TLS] [Cfrg] password-based key exchange 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, 20 Dec 2011 22:17:39 -0000 One minor comment (which might be totally obvious): > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Dan Harkins > Sent: Tuesday, December 20, 2011 4:38 PM > To: cfrg@irtf.org > Cc: tls@ietf.org > Subject: [Cfrg] password-based key exchange >=20 >=20 > Hello, >=20 > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: >=20 > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 >=20 > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, > asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving > mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). >=20 > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one > side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: >=20 > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: >=20 > - E =3D HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x =3D H(y) returns a random stream, x, given some input, y. >=20 > The key exchange works like this: >=20 > 1. PE =3D HashToElement(local_ID | peer_ID | password) > gets a "password element" >=20 > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. >=20 > 2. generate 2 random numbers between 0 and the order of the group, q: >=20 > 0 < local_rand, local_mask < q >=20 > 3. compute a scalar and an element: > local_scalar =3D (local_rand + local_mask) mod q > local_element =3D 1/(PE^local_mask) mod p >=20 > where p is the prime and q is the order. Send local_scalar and > local_element to other side >=20 > 4. receive peer_scalar and peer_element from other side >=20 > 5. compute shared key, K >=20 > K =3D (PE^peer_scalar * peer_element)^local_rand mod p =3D > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p > =3D > PE^(peer_rand*local_rand) mod p You probably should have an explicit test and rejection for K =3D 1 ('point at infinity' for EC groups)... >=20 > 6. compute a confirmation >=20 > local_confirm =3D H(K, local_scalar | local_element | > peer_scalar | peer_element) >=20 > send confirmation to peer >=20 > 7. receive peer's confirmation, calculate verifier >=20 > verifier =3D H(K, peer_scalar | peer_element | local_scalar | > local_element) >=20 > if verifier equals peer's confirmation the peer is authenticated. >=20 > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". >=20 > Thank you in advance for any analysis that can be provided on this > exchange. >=20 > regards, >=20 > Dan. >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From dharkins@lounge.org Tue Dec 20 14:56:53 2011 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 C7C1411E8099 for ; Tue, 20 Dec 2011 14:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.965 X-Spam-Level: X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9iVYGRrfpn3b for ; Tue, 20 Dec 2011 14:56:53 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6913D11E80A2 for ; Tue, 20 Dec 2011 14:56:53 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 102B51022404A; Tue, 20 Dec 2011 14:56:53 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 20 Dec 2011 14:56:53 -0800 (PST) Message-ID: <3a8ab8150ea9fbe33b19ccb27a97634a.squirrel@www.trepanning.net> In-Reply-To: <20111220215232.GA23676@netbook.cypherspace.org> References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> <20111220215232.GA23676@netbook.cypherspace.org> Date: Tue, 20 Dec 2011 14:56:53 -0800 (PST) From: "Dan Harkins" To: "Adam Back" 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: Adam Back , cfrg@irtf.org, tls@ietf.org Subject: Re: [TLS] [Cfrg] password-based key exchange 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, 20 Dec 2011 22:56:53 -0000 Hello, On Tue, December 20, 2011 1:52 pm, Adam Back wrote: > I noticed no reference to SRP nor TLS-SRP draft. It seems this draft > duplicates the functionality? Note SRP can also operate in elliptic > curves > and SRP is specified in IEEE P1363 standard. Correct, there is no reference to TLS-SRP. > There is no reference to the specific password authenticated key exchange > that I saw. Is it an existing one, or one that you designed? I ask > because > its harder than it looks to design EKE / AKE related protocols and some of > the early ones were broken, and others had their design security eroded. > SRP has at least been published for quite some time. It's one I designed. It's been incorporated into 802.11 and will be part of the forthcoming -2012 version of that standard. It is also an EAP method (RFC 5931). The difficulty in designing these sorts of protocols is acknowledged and is, in fact, the whole basis for this request. regards, Dan. From pgut001@login01.cs.auckland.ac.nz Tue Dec 20 18:29:34 2011 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 6471711E808A for ; Tue, 20 Dec 2011 18:29:34 -0800 (PST) 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 L0rGQX5ftrQP for ; Tue, 20 Dec 2011 18:29:33 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7F811E8073 for ; Tue, 20 Dec 2011 18:29:31 -0800 (PST) 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=1324434573; x=1355970573; h=from:to:subject:in-reply-to:message-id:date; bh=sXr3c7FckKrec/e6pn0CKb/RMKcmc6SisC9FaivPGRY=; b=SoLJB7XVhs+dSvQ1GvSjoWRMEEtxKKs8xkNcefYFh+d8ctwPRNmdDujf nTPx4C9YIQ1/8HyAP4KOQBdTXrMFty6SXJ11Bvu/xGNonYRYGsUkbZ47y QTHp/+xyDCjBw6PaA1+vmzRmqxzHIlyoEj3LweratuwiMOZhkvfcCPTkI w=; X-IronPort-AV: E=Sophos;i="4.71,385,1320577200"; d="scan'208";a="95590598" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Dec 2011 15:29:24 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RdBvn-0004or-PG; Wed, 21 Dec 2011 15:29:23 +1300 From: Peter Gutmann To: fweimer@bfk.de, tls@ietf.org In-Reply-To: <82ehvzidu4.fsf@mid.bfk.de> Message-Id: Date: Wed, 21 Dec 2011 15:29:23 +1300 Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 02:29:34 -0000 Florian Weimer writes: >What is the best way to deal with this? If it's the other side that does it then there's not much you can do, if you're doing it then you need to wander into a twisty little maze of shutdown()/close() passages, all different, buggy, and incompatible: /* Close a connection. Safely handling closes is extremely difficult due to a combination of the way TCP/IP (and TCP stacks) work and various bugs and quirks in implementations. After a close (and particularly if short- timeout non-blocking writes are used) there can still be data left in TCP send buffers, and also as unacknowledged segments on the network. At this point there's no easy way for the TCP stack to know how long it should hang around trying to get the data out and waiting for acks to come back. If it doesn't wait long enough, it'll end up discarding unsent data. If it waits too long, it could potentially wait forever in the presence of network outages or crashed peers. What's worse, since the socket is now closed, there's no way to report any problems that may occur at this point back to the caller. We try and handle this with a combination of shutdown() and close(), but due to implementation bugs/quirks and the TCP stack issues mentioned above this doesn't work all of the time. The details get very implementation-specific, for example with glibc the manpage says that setting SO_LINGER causes shutdown() not to return until queued messages are sent (which is wrong, and non-glibc implementations like PHUX and Solaris specifically point out that only close() is affected), but that shutdown() discards unsent data. glibc in turn is dependent on the kernel it's running on top of, under Linux shutdown() returns immediately but data is still sent regardless of the SO_LINGER setting. BSD Net/2 and later (which many stacks are derived from, including non- Unix systems like OS/2) returned immediately from a close() but still sent queued data on a best-effort basis. With SO_LINGER set and a zero timeout the close was abortive (which Linux also implemented starting with the 2.4 kernel), and with a non-zero timeout it would wait until all the data was sent, which meant that it could block almost indefinitely (minutes or even hours, this is the worst-case behaviour mentioned above). This was finally fixed in 4.4BSD (although a lot of 4.3BSD- derived stacks ended up with the indefinite-wait behaviour), but even then there was some confusion as to whether the wait time was in machine- specific ticks or seconds (Posix finally declared it to be seconds). Under Winsock, close() simply discards queued data while shutdown() has the same effect as under Linux, sending enqueued data asynchronously regardless of the SO_LINGER setting. This is a real mess to sort out safely, the best that we can do is to perform a shutdown() followed later by a close(). Messing with SO_LINGER is too risky and something like performing an ioWait() doesn't work either because it just results in whoever initiated the shutdown being blocked for the I/O wait time, and waiting for a recv() of 0 bytes isn't safe because the higher-level code may need to read back a shutdown ack from the other side which a recv() performed at this point would interfere with. Under Windows we could handle it by waiting for an FD_CLOSE to be posted but this requires the use of a window handle which we don't have access to, and which may not even exist for some classes of applications */ Peter. From mrex@sap.com Tue Dec 20 19:52:47 2011 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 9CAC211E8073 for ; Tue, 20 Dec 2011 19:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 rFuSCkvqF1-k for ; Tue, 20 Dec 2011 19:52:46 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8A79821F846C for ; Tue, 20 Dec 2011 19:52:46 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBL3qcAH020729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2011 04:52:43 +0100 (MET) From: Martin Rex Message-Id: <201112210352.pBL3qcvd022885@fs4113.wdf.sap.corp> Orig-To: mrex@sap.com To: fweimer@bfk.de, tls@ietf.org Date: Tue, 20 Dec 2011 22:53:18 +0100 (MET) In-Reply-To: <201112202125.pBKLPh03000374@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 20, 11 10:25:43 pm Sender: mrex@sap.com X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 03:52:47 -0000 (clarified & re-sent) Martin Rex wrote: > > Florian Weimer wrote: > > > > TCP has the property that connection shutdowns can overtake application > > data if connections are used in full-duplex mode. No, it can not (for implementations conforming to rfc1122). >From rfc1122, Section 4.2.2.13 "Closing a connection": http://tools.ietf.org/html/rfc1122#page-88 A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost. "Application calling CLOSE" refers to calling shutdown() (rather than close(), which would destroy the socket handle) in terms of BSD sockets. That paragraph from rfc1122 means that a TCP implementation could decide to treat shutdown(socket,SHUT_WR) and shutdown(socket,SHUT_RD) always and exactly the same as shutdown(socket,SHUT_RDWR), i.e. not support a unidirectional/partial closure. > > > Here's an example: > > > > (1) X sends a fatal TLS alert to Y > > (2) X shuts down the connection > > (3) Y sends data to X > > (4) X receives from Y, sends RST to signal data loss to Y > > (5) Y receives RST > > > > (6) At this point, when Y tries to send further data, > > it will receive EPIPE from the sockets API. Correct. > > > When it tries to read data, it will receive ECONNRESET. That can not happen _unless_ some buggy code in the application on Y called shutdown(socket,SHUT_WR) when being faced with EPIPE on send(). > > > Note that this behavior is not related > > to the SO_LINGER socket option. I believe this is incorrect. If X is using SO_LINGER, then (2) will cause X to send a TCP FIN to Y, which the TCP implementation on X ought to translate into a regular End-Of-File on recv(), rather than ECONNRESET. > > > According to the socket API sepcification, there is no way > > to access the initial TLS alert. As long as Y does not call shutdown() on the socket, it will receive all data that arrived on the socket prior to seeing End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER) on recv(). If you have some app on Y _not_ seeing the fatal TLS alert (but you saw it coming in on the network with a tool like Wireshark, then there is probably incorrect app code that erroneously called shutdown(socket,SHUT_WR) while using a TCP implementation that does not support a full-duplex close, or an incorrect app that called shutdown(socket,SHUT_RDWR), maybe as an inappropriate knee-jerk reaction of being faced with EPIPE on send(), prior to trying to recv() the alert. -Martin From SRS0=wbl3=7B=acm.org=bmoeller@srs.kundenserver.de Wed Dec 21 02:07:12 2011 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 B2C7221F8467 for ; Wed, 21 Dec 2011 02:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.604 X-Spam-Level: X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 r6tQmy2fCX3u for ; Wed, 21 Dec 2011 02:07:12 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id C78A021F845F for ; Wed, 21 Dec 2011 02:07:11 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0La6Uk-1QyyJs2S1G-00m3vE; Wed, 21 Dec 2011 11:07:10 +0100 Received: by qadb15 with SMTP id b15so3733741qad.10 for ; Wed, 21 Dec 2011 02:07:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.98.8 with SMTP id o8mr7226639qan.79.1324462029588; Wed, 21 Dec 2011 02:07:09 -0800 (PST) Received: by 10.224.19.196 with HTTP; Wed, 21 Dec 2011 02:07:09 -0800 (PST) In-Reply-To: <201112210352.pBL3qcvd022885@fs4113.wdf.sap.corp> References: <201112202125.pBKLPh03000374@fs4113.wdf.sap.corp> <201112210352.pBL3qcvd022885@fs4113.wdf.sap.corp> Date: Wed, 21 Dec 2011 11:07:09 +0100 Message-ID: From: Bodo Moeller To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d9a6cac84104b497589e X-Provags-ID: V02:K0:3san2K86oKR2Yy1ZfBw9qJgrnYnr9WdPu8wjkvCawtQ V2tmoT9jLxb9HzKFw6MK/2TvPDv/kZoohWUzheFcyoDmezUvGa EGg47YL+PDGTNgJ1T48qWL1WtEMC7ZmrpDLQZ1054QWxn549Yr eA0+ar7Dasz7wQUbUYa/sgrbo7qluOvpqaKnsvT+93kK59wkao zhb0NJwIXYuE+6IDIDy0D0pTUdXsJc5Grrx79+c0uMV0HyQVOj +LamJEEswldI1QECIt5YXvZp70u/XYWTzyi073DUnY9gLrN5vd JgeAw/eAmm3FVjro25UwU/TSI3Yym0P1QrEVAcrDm+DQjoAijN 5UXKGw5XW/vBWroHg/M9kNGqBlvXe89fZz1HtH+oCc69+Z1cUG t46YbGm+hZG07jlo77QVNR8mt+yQPfBEk8lIQ0650HQcRaHZVX /yo5R Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 10:08:02 -0000 --20cf3074d9a6cac84104b497589e Content-Type: text/plain; charset=ISO-8859-1 > > > (1) X sends a fatal TLS alert to Y > > > (2) X shuts down the connection > > > (3) Y sends data to X > > > (4) X receives from Y, sends RST to signal data loss to Y > > > (5) Y receives RST > > > > > > (6) At this point, when Y tries to send further data, > > > it will receive EPIPE from the sockets API. > > > When it tries to read data, it will receive ECONNRESET. > > As long as Y does not call shutdown() on the socket, it will > receive all data that arrived on the socket prior to seeing > End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER) > on recv(). > > That's not right. Upon receiving RST, Y's TCP will reset the state for this connection and discard any data already buffered; no further data can be received by the application (in this case, by the TLS implementation); check RFC 793 for RST processing details. If X doesn't want that, it must not send an RST. (With a fatal alert, that doesn't sound *that* problematic because there's a problem anyway. I've seen TLS servers send RSTs instead of cleanly closing the connection when there was *no* error, which is very bad because then you depend on client-side scheduling -- if the TLS client isn't able to process the response before the TLS connection is killed, you have a problem.) Bodo --20cf3074d9a6cac84104b497589e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> > (1) =A0X sends a fatal TLS alert to Y
> > (2) =A0X shuts down the connection
> > (3) =A0Y sends data to X
> > (4) =A0X receives from Y, sends RST to signal data loss to Y
> > (5) =A0Y receives RST
> >
> > (6) At this point, when Y tries to send further data,
> > it will receive EPIPE from the sockets API.
> > When it tries to read data, it will receive ECONNRESET.
=
=A0
As long as Y does not call shutdown() on the socket, it will
receive all data that arrived on the socket prior to seeing
End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER)
on recv().


That's not right.=A0 Upon recei= ving RST, Y's TCP will reset the state for this connection and discard = any data already buffered; no further data can be received by the applicati= on (in this case, by the TLS implementation); check RFC 793 for RST process= ing details.=A0 If X doesn't want that, it must not send an RST.

(With a fatal alert, that doesn't sound *that* problematic because = there's a problem anyway.=A0 I've seen TLS servers send RSTs instea= d of cleanly closing the connection when there was *no* error, which is ver= y bad because then you depend on client-side scheduling -- if the TLS clien= t isn't able to process the response before the TLS connection is kille= d, you have a problem.)

Bodo

--20cf3074d9a6cac84104b497589e-- From fweimer@bfk.de Wed Dec 21 04:32:23 2011 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 70B6B21F84FB for ; Wed, 21 Dec 2011 04:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 30cpJ451tjE2 for ; Wed, 21 Dec 2011 04:32:22 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 95E5A21F84E5 for ; Wed, 21 Dec 2011 04:32:22 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RdLLG-0000SU-Jf; Wed, 21 Dec 2011 12:32:18 +0000 Received: by bfk.de with local id 1RdLLG-0008Sd-FU; Wed, 21 Dec 2011 12:32:18 +0000 From: Florian Weimer To: Peter Gutmann References: Date: Wed, 21 Dec 2011 12:32:18 +0000 In-Reply-To: (Peter Gutmann's message of "Wed, 21 Dec 2011 15:29:23 +1300") Message-ID: <82hb0ugl65.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 12:32:23 -0000 * Peter Gutmann: > Florian Weimer writes: > >>What is the best way to deal with this?=20 > > If it's the other side that does it then there's not much you can do, if > you're doing it then you need to wander into a twisty little maze of > shutdown()/close() passages, all different, buggy, and incompatible: Yeah, that's about as much fine print as I feared. Thanks. Fortunately, I'm only trying to resolve an interoperability problem between GNUTLS and the OpenJDK implementation. There seems to be some confusion about the error reporting for connection failures, and I'm trying to provide better messages to consumers. It turns out that both GNUTLS and OpenJDK properly report the certificate_unknown alert during handshake failure when talking to themselves implementation. The difference between GNUTLS and OpenJDK when talking to an OpenJDK server is this: the GNUTLS client sends the Certificate and Client Key Exchange messages in separate TLS records and (in the way we use it) TCP segments, while the OpenJDK client uses a single TLS record in a single TCP segment. As a result, the race leading to reception of an early RST is rarely lost by the OpenJDK client (if ever). I changed the GNUTLS client to create just one TCP segment per server round-trip, and I can now read the TLS alert before the RST segment arrives. So the fix was quite trivial after all. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mrex@sap.com Wed Dec 21 11:13:40 2011 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 5653E21F84FA for ; Wed, 21 Dec 2011 11:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.403 X-Spam-Level: X-Spam-Status: No, score=-7.403 tagged_above=-999 required=5 tests=[AWL=-2.754, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35, J_CHICKENPOX_101=0.6, 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 IrxGw4LlxxGS for ; Wed, 21 Dec 2011 11:13:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3478521F84E5 for ; Wed, 21 Dec 2011 11:13:38 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pBLJDYhX001815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2011 20:13:34 +0100 (MET) From: Martin Rex Message-Id: <201112211913.pBLJDXBM014049@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Wed, 21 Dec 2011 20:13:33 +0100 (MET) In-Reply-To: from "Bodo Moeller" at Dec 21, 11 11:07:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 19:13:40 -0000 Bodo Moeller wrote: > > > > > (1) X sends a fatal TLS alert to Y > > > > (2) X shuts down the connection > > > > (3) Y sends data to X > > > > (4) X receives from Y, sends RST to signal data loss to Y > > > > (5) Y receives RST > > > > > > > > (6) At this point, when Y tries to send further data, > > > > it will receive EPIPE from the sockets API. > > > > When it tries to read data, it will receive ECONNRESET. > > > > > As long as Y does not call shutdown() on the socket, it will > > receive all data that arrived on the socket prior to seeing > > End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER) > > on recv(). > > > > That's not right. Upon receiving RST, Y's TCP will reset the state for > this connection and discard any data already buffered; no further data can > be received by the application (in this case, by the TLS implementation); > check RFC 793 for RST processing details. If X doesn't want that, it must > not send an RST. That is not what my copies of rfc793 and rfc1122 specify. Unless the local application performs a shutdown(), the TCP implementation of Y MUST continue to deliver data that was received. (4) from above indicates that X must have changed the SO_LINGER socket option and called close() on the connection rather than shutdown(SHUT_RD). (see Stevens, Unix Network Programming Vol.1, on my second edition it is section 7.5, figure 7.10, page 191, "close, l_onoff=1, l_linger=0") with the result that the TCP of X has no more memories about the connection and considers the connection "CLOSED". In the alternative situation, X's TCP would have sent a TCP FIN and be in the synchronized state FIN_WAIT_1. rfc793 on Reset generation: http://tools.ietf.org/html/rfc793#page-36 Reset Generation As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case. Specified processing for X in (CLOSED): There are three groups of states: 1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means. If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the CLOSED state. which means that X must send an RST with a SEQ number of 0! Specified processing for X in (FIN_WAIT_1): 3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state. If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment. which means that X must not send an RST at all. On Shutdown() X dropped its receive buffer (so that the receive window is now 0 (Zero)), but still knows the incoming Seqence number. So any further incoming data is "out of window" and must elicit only an empty acknowledgement segment (rather than RST). Now looking at the requirements for the RST processing: http://tools.ietf.org/html/rfc793#page-37 Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state. The RST generated by X at (CLOSED) has a SEQ 0, so it very probably fail SEQ-validation and must be completely ignored by Y's TCP Y is still in ESTABLISHED, because X didn't send a FIN. If X had sent a FIN, then Y would be in CLOSE_WAIT, but X would have been prohibited to sent a FIN (and required to send an empty ACK instead). 3.5. Closing a Connection CLOSE is an operation meaning "I have no more data to send." The notion of closing a full-duplex connection is subject to ambiguous interpretation, of course, since it may not be obvious how to treat the receiving side of the connection. We have chosen to treat CLOSE in a simplex fashion. The user who CLOSEs may continue to RECEIVE until he is told that the other side has CLOSED also. Thus, a program could initiate several SENDs followed by a CLOSE, and then continue to RECEIVE until signaled that a RECEIVE failed because the other side has CLOSED. We assume that the TCP will signal a user, even if no RECEIVEs are outstanding, that the other side has closed, so the user can terminate his side gracefully. A TCP will reliably deliver all buffers SENT before the connection was CLOSED so a user who expects no data in return need only wait to hear the connection was CLOSED successfully to know that all his data was received at the destination TCP. Users must keep reading connections they close for sending until the TCP says no more data. -Martin From marsh@extendedsubset.com Wed Dec 21 11:25:00 2011 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 D5B451F0C4D for ; Wed, 21 Dec 2011 11:25:00 -0800 (PST) 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 xx0lTIPgJYy0 for ; Wed, 21 Dec 2011 11:25:00 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 242B91F0C4C for ; Wed, 21 Dec 2011 11:25:00 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RdRmd-00065C-Nd; Wed, 21 Dec 2011 19:24:59 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CEAC46067; Wed, 21 Dec 2011 19:24:57 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+NxUj9lcy84520Zi2BFKppD4yCeSIR6gw= Message-ID: <4EF2328A.9060604@extendedsubset.com> Date: Wed, 21 Dec 2011 13:24:58 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: mrex@sap.com References: <201112211913.pBLJDXBM014049@fs4113.wdf.sap.corp> In-Reply-To: <201112211913.pBLJDXBM014049@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 19:25:01 -0000 On 12/21/2011 01:13 PM, Martin Rex wrote: > > Unless the local application performs a shutdown(), the TCP implementation > of Y MUST continue to deliver data that was received. This seems relevant http://tools.ietf.org/html/rfc793 > [when in state:] ESTABLISHED FIN-WAIT-1 FIN-WAIT-2 CLOSE-WAIT > > If the RST bit is set then, any outstanding RECEIVEs and SEND > should receive "reset" responses. All segment queues should be > flushed. Users should also receive an unsolicited general > "connection reset" signal. Enter the CLOSED state, delete the > TCB, and return. This part about "all segment queues should be flushed" suggests to me that received-but-undelivered application data MAY or SHOULD be discarded. Deleting the TCB altogether certainly sounds final. - Marsh From mrex@sap.com Wed Dec 21 11:40:02 2011 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 E71DB11E80A3 for ; Wed, 21 Dec 2011 11:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.559 X-Spam-Level: X-Spam-Status: No, score=-9.559 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 ZT8Ung2m4npa for ; Wed, 21 Dec 2011 11:40:02 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B645711E8073 for ; Wed, 21 Dec 2011 11:40:01 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBLJdonc011636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2011 20:39:55 +0100 (MET) From: Martin Rex Message-Id: <201112211939.pBLJdovn015672@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 21 Dec 2011 20:39:50 +0100 (MET) In-Reply-To: <4EF2328A.9060604@extendedsubset.com> from "Marsh Ray" at Dec 21, 11 01:24:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 19:40:03 -0000 Marsh Ray wrote: > > On 12/21/2011 01:13 PM, Martin Rex wrote: > > > > Unless the local application performs a shutdown(), the TCP implementation > > of Y MUST continue to deliver data that was received. > > This seems relevant http://tools.ietf.org/html/rfc793 > > > [when in state:] ESTABLISHED FIN-WAIT-1 FIN-WAIT-2 CLOSE-WAIT > > > > If the RST bit is set then, any outstanding RECEIVEs and SEND > > should receive "reset" responses. All segment queues should be > > flushed. Users should also receive an unsolicited general > > "connection reset" signal. Enter the CLOSED state, delete the > > TCB, and return. > > This part about "all segment queues should be flushed" suggests to me > that received-but-undelivered application data MAY or SHOULD be > discarded. Deleting the TCB altogether certainly sounds final. In case that you're referring to page 70, this text appears in a section "second check the RST bit," and can only be ever reached when it was not fully processed by the previous "first check sequence number" a page before, which says: first check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. There are four cases for the acceptability test for an incoming segment: Segment Receive Test Length Window ------- ------- ------------------------------------------- 0 0 SEG.SEQ = RCV.NXT 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 0 not acceptable >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND If the RCV.WND is zero, no segments will be acceptable, but special allowance should be made to accept valid ACKs, URGs and RSTs. *> If an incoming segment is not acceptable, an acknowledgment *> should be sent in reply (unless the RST bit is set, if so drop *> the segment and return): After sending the acknowledgment, drop the unacceptable segment and return. -Martin From SRS0=wbl3=7B=acm.org=bmoeller@srs.kundenserver.de Wed Dec 21 11:50:47 2011 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 527B71F0C5C for ; Wed, 21 Dec 2011 11:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.066 X-Spam-Level: X-Spam-Status: No, score=-99.066 tagged_above=-999 required=5 tests=[AWL=-2.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HELO_EQ_DE=0.35, HTML_MESSAGE=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 b2m2hf8m1m99 for ; Wed, 21 Dec 2011 11:50:44 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73F1F0C51 for ; Wed, 21 Dec 2011 11:50:43 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lb96v-1Qy1hg2siv-00kFGk; Wed, 21 Dec 2011 20:50:42 +0100 Received: by qcsf15 with SMTP id f15so5660685qcs.31 for ; Wed, 21 Dec 2011 11:50:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.98.8 with SMTP id o8mr9919391qan.79.1324497040678; Wed, 21 Dec 2011 11:50:40 -0800 (PST) Received: by 10.224.19.196 with HTTP; Wed, 21 Dec 2011 11:50:40 -0800 (PST) In-Reply-To: <201112211913.pBLJDXBM014049@fs4113.wdf.sap.corp> References: <201112211913.pBLJDXBM014049@fs4113.wdf.sap.corp> Date: Wed, 21 Dec 2011 20:50:40 +0100 Message-ID: From: Bodo Moeller To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d9a69d9d9604b49f7f6c X-Provags-ID: V02:K0:gWw5ndvUkqfKgIZUsgQYk/eKHSZgjvDVHkXBPyCIG32 A1wAeBaGaaD/TjWNAj40eIqL0mtZskDET+gfXBd7C4CEc0LvUy SFQhJta1+gqgACLzDAVHjUCLPsL2aUDW10XF+nAm9NYZ9drW/I PumqYwvGX59dDk7Uq8EELeHCSIP/I1JZp6fub6I+JYvpcjzkSq RQ+c/Y/LiK+lTu+vvgWFwzNnfUDtVQjHJ1FCErgIfnEpMhIrk5 kWwFbkdMlFeYcsFFkP07qb2ejdrA1yfs/HNcgdEflHorL6hCZK EkOZ7Kw9zZyDZZYZk1H+j/Xm6kQRZFtQ8apJCAkKmE3kH0yRxY HZNYedVEJC9Satd3+IErkE/u4O8b6j4kdUU36rFhRuEriE2w2e lYcb/GVf0r3LrDDQieKscRqfVbFmMgpFC67eRP3rMQL+hkJefk eXE4q Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 19:50:47 -0000 --20cf3074d9a69d9d9604b49f7f6c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 21, 2011 at 8:13 PM, Martin Rex wrote: > > > > > (1) X sends a fatal TLS alert to Y > > > > > (2) X shuts down the connection > > > > > (3) Y sends data to X > > > > > (4) X receives from Y, sends RST to signal data loss to Y > > > > > (5) Y receives RST > > > > > > > > > > (6) At this point, when Y tries to send further data, > > > > > it will receive EPIPE from the sockets API. > > > > > When it tries to read data, it will receive ECONNRESET. > > > > As long as Y does not call shutdown() on the socket, it will > > > receive all data that arrived on the socket prior to seeing > > > End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER) > > > on recv(). > > > That's not right. Upon receiving RST, Y's TCP will reset the state for > > this connection and discard any data already buffered; no further data > can > > be received by the application (in this case, by the TLS implementation); > > check RFC 793 for RST processing details. If X doesn't want that, it > must > > not send an RST. > Specified processing for X in (CLOSED): > > If the incoming segment has an ACK field, the reset takes its > sequence number from the ACK field of the segment, otherwise the > reset has sequence number zero and the ACK field is set to the sum > of the sequence number and segment length of the incoming segment. > The connection remains in the CLOSED state. > > > which means that X must send an RST with a SEQ number of 0! > The segment sent by Y in step (3) will have the ACK bit set, so the RST sent by X in (4) will have the appropriate sequence number that causes Y to accept the RST in step (5), and thus to discard all data. (By the way, I think the Linux TCP implementation will send a RST in that situation if close() has been used to shut down the connection regardless of SO_LINGER settings. Stevens doesn't describe that particular TCP implementation.) Bodo --20cf3074d9a69d9d9604b49f7f6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 8:13 PM, Martin Rex <mrex@sap.com> wrote:
=A0
> > > > (1) =A0X sends a fatal TLS alert to Y
> > > > (2) =A0X shuts down the connection
> > > > (3) =A0Y sends data to X
> > > > (4) =A0X receives from Y, sends RST to signal data loss= to Y
> > > > (5) =A0Y receives RST
> > > >
> > > > (6) At this point, when Y tries to send further data, > > > > it will receive EPIPE from the sockets API.
> > > > When it tries to read data, it will receive ECONNRESET.=
=A0
> > As long as Y does not call shutdown() on the socket, it will
> > receive all data that arrived on the socket prior to seeing
> > End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER= )
> > on recv().
=A0
> That's not right. =A0Upon receiving RST, Y's TCP will reset th= e state for
> this connection and discard any data already buffered; no further data= can
> be received by the application (in this case, by the TLS implementatio= n);
> check RFC 793 for RST processing details. =A0If X doesn't want tha= t, it must
> not send an RST.

Specified processing for X in (CLOSED):
=A0
=A0 =A0If the incoming segment has an ACK field, the reset takes its
=A0 =A0sequence number from the ACK field of the segment, otherwise the =A0 =A0reset has sequence number zero and the ACK field is set to the sum<= br> =A0 =A0of the sequence number and segment length of the incoming segment.<= br> =A0 =A0The connection remains in the CLOSED state.


which means that X must send an RST with a SEQ number of 0!

The segment sent by Y in step (3) will have the ACK bit set, so t= he RST sent by X in (4) will have the appropriate sequence number that caus= es Y to accept the RST in step (5), and thus to discard all data.

(By the way, I think the Linux TCP implementation will send a RST in th= at situation if close() has been used to shut down the connection regardles= s of SO_LINGER settings.=A0 Stevens doesn't describe that particular TC= P implementation.)

Bodo
--20cf3074d9a69d9d9604b49f7f6c-- From marsh@extendedsubset.com Wed Dec 21 12:04:03 2011 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 E91951F0C5E for ; Wed, 21 Dec 2011 12:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 XXQlrP7wiJC7 for ; Wed, 21 Dec 2011 12:04:03 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4701F0C5C for ; Wed, 21 Dec 2011 12:04:03 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RdSOR-00069G-2w; Wed, 21 Dec 2011 20:04:03 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7A78B63C5; Wed, 21 Dec 2011 20:04:01 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qEZBOl/GZJ/aXFEG8XoQtM1TnQd+gxxo= Message-ID: <4EF23BB2.600@extendedsubset.com> Date: Wed, 21 Dec 2011 14:04:02 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: mrex@sap.com References: <201112211939.pBLJdovn015672@fs4113.wdf.sap.corp> In-Reply-To: <201112211939.pBLJdovn015672@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 20:04:04 -0000 On 12/21/2011 01:39 PM, Martin Rex wrote: > > In case that you're referring to page 70, > this text appears in a section > > "second check the RST bit," > > and can only be ever reached when it was > not fully processed by the previous "first check sequence number" > a page before, which says: > *> If an incoming segment is not acceptable, an acknowledgment > *> should be sent in reply (unless the RST bit is set, if so [...] But let's say the RST segment passes the sequence number check. It seems that this language applies: > Initial tests on arrival are used to discard old duplicates, > but further processing is done in SEG.SEQ order. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So maybe I am starting to agree with you (but for a different reason :-) - Marsh From SRS0=wbl3=7B=acm.org=bmoeller@srs.kundenserver.de Wed Dec 21 12:28:36 2011 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 4C3771F0C62 for ; Wed, 21 Dec 2011 12:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.917 X-Spam-Level: X-Spam-Status: No, score=-100.917 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 8i-0iabpGRwA for ; Wed, 21 Dec 2011 12:28:35 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4701F0C61 for ; Wed, 21 Dec 2011 12:28:35 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MaXEr-1ROHH905sX-00Jw5C; Wed, 21 Dec 2011 21:28:34 +0100 Received: by qadb15 with SMTP id b15so4100199qad.10 for ; Wed, 21 Dec 2011 12:28:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.30.194 with SMTP id v2mr10091096qac.53.1324499312956; Wed, 21 Dec 2011 12:28:32 -0800 (PST) Received: by 10.224.19.196 with HTTP; Wed, 21 Dec 2011 12:28:32 -0800 (PST) In-Reply-To: <4EF23BB2.600@extendedsubset.com> References: <201112211939.pBLJdovn015672@fs4113.wdf.sap.corp> <4EF23BB2.600@extendedsubset.com> Date: Wed, 21 Dec 2011 21:28:32 +0100 Message-ID: From: Bodo Moeller To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d6a40dd57104b4a00711 X-Provags-ID: V02:K0:Bn5WV+zogMssqm2cYPEJd3ZE/KS/eSwOCu2daRWm5Dm 6/LWtVVrdWklXo3JLHLpqy4pgB9MrnYtvmLesz3984W/VNitr1 7ydePYL7XwWO6hQ7Z98dk+JFl8hIS9fRWWDp7YvkH2IxTci32k xgGVzl+R6h5hoXaVR4DCAkCiSbZRuHOjl9OqKTS1pSIu50+jWt +hwlPp/IYupMf6KkaUJU1cUven8+rq9+IKhjh0LxSqekWBItwZ IyEBHXL1Tk7bLBgsqQcFqHTcGHhioDfy/2EYtvtnU/LajZKKwx fzZ9aeob04TfYawrI/sQeNngahn3tvNeG3SS/f02q06QeOyGt7 FCLmc74O0/FzpJ9+lhEbGkJLokKNqJo0v1rOHClCmdKW3DF3Rr p9eWiBQqrgQFuggTjeiJ8LELg7UfbtRuA7nCPOiKyoZoEmUhq8 j8xTN Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 20:28:36 -0000 --20cf3074d6a40dd57104b4a00711 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 21, 2011 at 9:04 PM, Marsh Ray wrote: > But let's say the RST segment passes the sequence number check. > > It seems that this language applies: > > Initial tests on arrival are used to discard old duplicates, >> but further processing is done in SEG.SEQ order. >> > Note that this only implies that Y's TCP needs to process the segment containing X's TLS alert before it can process the RST segment. Processing the segment with the alert merely means queuing it; the TLS layer would have to "RECEIVE" it from the TCP to do something with it. If the RST segment gets processed before the TLS layer has received the TLS alert, the receiving queue will be flushed, and the alert will be gone. --20cf3074d6a40dd57104b4a00711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 9:04 PM, Marsh Ray <marsh@extendedsubset.com> w= rote:
=A0
But let's say the RST segment passes the sequence number check.

It seems that this language applies:

Initial tests on arrival =A0are used to discard old duplicates,
=A0but further processing is =A0done in SEG.SEQ order.

Note that this only implies that Y's TCP needs= to process the segment containing X's TLS alert before it can process = the RST segment. Processing the segment with the alert merely means queuing= it; the TLS layer would have to "RECEIVE" it from the TCP to do = something with it.=A0 If the RST segment gets processed before the TLS laye= r has received the TLS alert, the receiving queue will be flushed, and the = alert will be gone.

--20cf3074d6a40dd57104b4a00711-- From mrex@sap.com Wed Dec 21 13:40:42 2011 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 D095521F8AA8 for ; Wed, 21 Dec 2011 13:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.869 X-Spam-Level: X-Spam-Status: No, score=-9.869 tagged_above=-999 required=5 tests=[AWL=0.380, 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 NwXk3mJV1xf7 for ; Wed, 21 Dec 2011 13:40:42 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0F81521F8A7A for ; Wed, 21 Dec 2011 13:40:41 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pBLLebqo000790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2011 22:40:37 +0100 (MET) From: Martin Rex Message-Id: <201112212140.pBLLeb3b022306@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Wed, 21 Dec 2011 22:40:37 +0100 (MET) In-Reply-To: from "Bodo Moeller" at Dec 21, 11 08:50:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 21:40:42 -0000 Bodo Moeller wrote: > >>>>>> (1) X sends a fatal TLS alert to Y >>>>>> (2) X shuts down the connection >>>>>> (3) Y sends data to X >>>>>> (4) X receives from Y, sends RST to signal data loss to Y >>>>>> (5) Y receives RST >>>>>> >>>>>> (6) At this point, when Y tries to send further data, >>>>>> it will receive EPIPE from the sockets API. >>>>>> When it tries to read data, it will receive ECONNRESET. > > The segment sent by Y in step (3) will have the ACK bit set, so the RST > sent by X in (4) will have the appropriate sequence number that causes Y to > accept the RST in step (5), and thus to discard all data. Whooops. It seems I got lost in the woods. I'm sorry. You were correct. TCP seems to not provide a means to gently signal "I'm no longer listening", but only for "I'm finished talking" (FIN). And the only alternative to signal "I'm no longer listening" is (RST), but that has quite rude side-effects of potentially killing stuff that may still be in the receivers incoming TCP segment buffers not yet known to the receiver. And SO_LINGER seems to help only for gently conveying the "I'm finished talking" situation, but does not help in the "I'm no longer listening" situation, as Florian asserted, due to the lack of such a feature in the TCP design. While the non-lingering close is similar to the "A Crashed" (X=A, Y=B) in rfc793 page 35, Figure 11: An interesting alternative case occurs when TCP A crashes and TCP B tries to send data on what it thinks is a synchronized connection. This is illustrated in figure 11. In this case, the data arriving at TCP A from TCP B (line 2) is unacceptable because no such connection exists, so TCP A sends a RST. The RST is acceptable so TCP B processes it and aborts the connection. TCP A TCP B 1. (CRASH) (send 300,receive 100) 2. (??) <-- <-- ESTABLISHED 3. --> --> (ABORT!!) Active Side Causes Half-Open Connection Discovery Figure 11. What I haven't found is a description of the message flow for "I'm no longer listening" situation. The TCP Connection State Diagram (rfc793, page 23, figure 6.) contains a "CLOSE/snd FIN" state transition, but that means "I'm finished talking", but lacks the state transition from ESTAB for "I'm finished listening". So I'm slightly confused what that means for the POSIX API function shutdown() that does offer the semantics "I'm no longer listening" (first entry of the table in Stevens, Network programming vol.1 2nd ed, page 191, Figure 7.10): shutdown, SHUT_RD No more receives can be issued on socket; process can still send on socket; socket receive buffer is discarded; any further data received is discarded by TCP (Excercise 6.5); no effect on socket send buffer -Martin From nico@cryptonector.com Wed Dec 21 14:31:22 2011 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 8D76511E80CD for ; Wed, 21 Dec 2011 14:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] 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 wntwF0bOk88M for ; Wed, 21 Dec 2011 14:31:22 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAA11E80C0 for ; Wed, 21 Dec 2011 14:31:21 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 6F2D810058 for ; Wed, 21 Dec 2011 14:31:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=h2vUhcYy8DYXo5k6cJoOb 24Kx2SeBxmWY3AwvKdGvY8aFYfgSCAJ6kZvrxADVNcYX/8OMOMi3jtgUBD8vbFyG dE2J93R9lLObUYrrwVFXdSmgCgb59qmYQ87YGno18CM8SO6OLZn+GKI5R//WFnDF cB0k6dshXpZ0Zl0f/vlmhg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dy547Yoer4c379DYI52Z Sl48158=; b=grKUhRQvEvy7Bl/dTf+Ie9117U0B+ItgWML0H++rZ+iThTsSUTAL L2mob62Q3T0JDRMm3R+pz8GzV8C0o0968ox8gIQoOaiK91s7S/+eV751DT6e3MVH IBlVx1X9rjRWJi1mHa5NTVVPTkq8gz+Xsv5vwPf0/MtQvcRibNra79g= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 53FB310056 for ; Wed, 21 Dec 2011 14:31:21 -0800 (PST) Received: by dajz8 with SMTP id z8so7374240daj.31 for ; Wed, 21 Dec 2011 14:31:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.192.42 with SMTP id hd10mr16856959pbc.84.1324506680587; Wed, 21 Dec 2011 14:31:20 -0800 (PST) Received: by 10.68.32.227 with HTTP; Wed, 21 Dec 2011 14:31:20 -0800 (PST) In-Reply-To: <201112212140.pBLLeb3b022306@fs4113.wdf.sap.corp> References: <201112212140.pBLLeb3b022306@fs4113.wdf.sap.corp> Date: Wed, 21 Dec 2011 16:31:20 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 21 Dec 2011 22:31:22 -0000 Stevens suggests[0] doing a shutdown(2) of SHUT_WR then read(2)ing or select(2)ing (or more modern equivalent) for read events on the same socket to wait for the FIN|ACK from the peer; read(2) is supposed to return 0 at that point (though I suppose it could also actually read data if there's data to be read, as only the write-side of the socket will have been shutdown at that point). That wouldn't be an indication that the application received the fatal alert, of course. Nothing short of waiting for the peer to close its end of the socket will do, but we can't wait forever. Setting SO_LINGER with a zero l_linger is out, and a non-zero value is useless unless the thread is willing to block in close(2) -- a terrible waste of resources. It may well be that the best thing to do is to shutdown(socket, SHUT_WR) then queue up the socket for a later close(2) with SO_LINGER and zero l_linger. This gives the peer application a pretty good chance to receive the fatal alert and close the socket normally, while also limiting resource usage on the side that sent the alert. And if you already have an event-based async I/O framework you can trivially set a timer upon which to close() the socket, and even process any further data sent by the peer. [0] Unix Network Programming volume 1, 2nd ed., section 7.5, page 189 / fig. 7.8. Nico -- From pgut001@login01.cs.auckland.ac.nz Wed Dec 21 20:15:00 2011 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 3399211E80EE for ; Wed, 21 Dec 2011 20:15:00 -0800 (PST) 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 Mbp1BYdh0dIF for ; Wed, 21 Dec 2011 20:14:59 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1111E8096 for ; Wed, 21 Dec 2011 20:14:57 -0800 (PST) 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=1324527299; x=1356063299; h=from:to:subject:in-reply-to:message-id:date; bh=x2YB03PAtprl8ORB+k1FPc/TMSe7efdus3OjC+F32Wg=; b=OrtruOM2iGYMhZxUn7wWaD6KX/vNUPVbJSgwrFJk9W9ZZzsto4JN1x+v 6zCPL2BcFOhxzVSOVkJJhe/hwJD3tXLHOhefQ7ey6blnOIRqPQLABiSfF E/94/DKnubU0pJbGKHTivif2YNadp9v5TbbjfM8FpmONVFeO7B93vOjIg E=; X-IronPort-AV: E=Sophos;i="4.71,391,1320577200"; d="scan'208";a="95749057" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Dec 2011 17:14:50 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Rda3N-0001mW-UJ; Thu, 22 Dec 2011 17:14:49 +1300 From: Peter Gutmann To: bmoeller@acm.org, tls@ietf.org In-Reply-To: Message-Id: Date: Thu, 22 Dec 2011 17:14:49 +1300 Subject: Re: [TLS] Sending fatal alerts over TCP 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, 22 Dec 2011 04:15:00 -0000 Bodo Moeller writes: >[quoting RFC] For situations like this, in which the OP asked about dealing with real-world behaviour, you can't quote the TCP RFCs, you can't even quote the Berkely sockets specs or manpages, you have to look at what the actual implementation(s) do, because that often bears little or no resemblance to the specs. That's not just because of bugs, it's because the implementations are based on extensive real-world experience and tuning (and, sometimes, de- tuning) which require slight... adaptations away from what the specs say. Going from the TCP RFC is at best going to give you an abstract model of what some implementations may do in certain circumstances, but it won't tell you how to deal with real-world implementations and behaviour. Peter. From SRS0=ruXs=7C=acm.org=bmoeller@srs.kundenserver.de Thu Dec 22 05:34:52 2011 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 79C0721F8AFE for ; Thu, 22 Dec 2011 05:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.231 X-Spam-Level: X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 qM0WVxinaUGZ for ; Thu, 22 Dec 2011 05:34:52 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id A540221F86AA for ; Thu, 22 Dec 2011 05:34:51 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LhThA-1QrPT723FI-00mjO4; Thu, 22 Dec 2011 14:34:49 +0100 Received: by qcsf15 with SMTP id f15so6155238qcs.31 for ; Thu, 22 Dec 2011 05:34:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.77.134 with SMTP id g6mr4090023qck.125.1324560888446; Thu, 22 Dec 2011 05:34:48 -0800 (PST) Received: by 10.224.19.196 with HTTP; Thu, 22 Dec 2011 05:34:48 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Dec 2011 14:34:48 +0100 Message-ID: From: Bodo Moeller To: tls@ietf.org Content-Type: multipart/alternative; boundary=00235433297e3d3e5304b4ae5dab X-Provags-ID: V02:K0:NhQLIp5LYAEUUZcameoKMo5+t8+b3fs5s1q1LzIX2QB u//Yx5VAfHBC2XCswtw08b77IeBD+o/1i5AoWwbzBAiJrXAm0V oQMeRyxoYmcPlxdYYYMWtzT/44kHf7PZlw6k8UjfEHwHRtf2BA cdiSZa947UodIzYyP/dKCe/pSvU4YzZ7uJmmi3X1RKUwQXwGpn 7f6frO+9VD+5J/7dnuJ6bXErMqpzP5hfdLuDah0LP6dI1FBiJZ sWlISdDSIhbb88veiRnOLxpPcpZYqTIwWhrN7ScttDFcZpC/Bp It3PzXKqPyCOiUdfpyf+aJRlJ6zBPD89uSSsgVcx58yS2AYUy9 Ibz/8FK/5Oow8VuppTmQB1xq4vmeGluhwXWsoJEudQcLx/hHKF yIfSwmVClVYksDSzwDEN81amEd+um73GEsCIuhNS1hHEpkw2SC mmdRP Subject: Re: [TLS] Sending fatal alerts over TCP 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, 22 Dec 2011 13:35:56 -0000 --00235433297e3d3e5304b4ae5dab Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 22, 2011 at 5:14 AM, Peter Gutmann wrote: > Bodo Moeller writes: > > >[quoting RFC] > > For situations like this, in which the OP asked about dealing with > real-world > behaviour, you can't quote the TCP RFCs, you can't even quote the Berkely > sockets specs or manpages, you have to look at what the actual > implementation(s) do, because that often bears little or no resemblance to > the > specs. That's not just because of bugs, it's because the implementations > are > based on extensive real-world experience and tuning (and, sometimes, de- > tuning) which require slight... adaptations away from what the specs say. > Indeed. However, I haven't quoted the RFCs to prove what real-world implementation are doing -- I have looked at the RFCs to confirm that what real-world implementations seem to be doing is, as far as relevant to this discussion, not in violation of the RFC. --00235433297e3d3e5304b4ae5dab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2011 at 5:14 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Bodo Moeller <bmoeller@acm.org&g= t; writes:
=A0
>[quoting RFC]
=A0
For situations like this, in which the OP asked about dealing with real-wor= ld
behaviour, you can't quote the TCP RFCs, you can't even quote the B= erkely
sockets specs or manpages, you have to look at what the actual
implementation(s) do, because that often bears little or no resemblance to = the
specs. =A0That's not just because of bugs, it's because the impleme= ntations are
based on extensive real-world experience and tuning (and, sometimes, de- tuning) which require slight... adaptations away from what the specs say.

Indeed.=A0 However, I haven't quoted the RFCs t= o prove what real-world implementation are doing -- I have looked at the RF= Cs to confirm that what real-world implementations seem to be doing is, as = far as relevant to this discussion, not in violation of the RFC.

--00235433297e3d3e5304b4ae5dab-- From paul.hoffman@vpnc.org Thu Dec 22 06:48:46 2011 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 0FAD621F8B23 for ; Thu, 22 Dec 2011 06:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 MJZu3DzP4eNV for ; Thu, 22 Dec 2011 06:48:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9541921F8B14 for ; Thu, 22 Dec 2011 06:48:45 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBMEmhlu028874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Dec 2011 07:48:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Thu, 22 Dec 2011 06:48:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9DEC1880-F418-49E8-9C14-8458303068CF@vpnc.org> References: To: tls@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [TLS] Sending fatal alerts over TCP 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, 22 Dec 2011 14:48:46 -0000 If someone wants to summarize where they think that this thread ended = and send it over to the TCPM WG (tcpm@ietf.org), we can get a sanity = check from the people who actually know how implementations act and how = they are supposed to. --Paul Hoffman= From fweimer@bfk.de Thu Dec 22 07:03:43 2011 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 96DBB21F8AAA for ; Thu, 22 Dec 2011 07:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 X1aND18nqd-1 for ; Thu, 22 Dec 2011 07:03:39 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 614A721F8A7D for ; Thu, 22 Dec 2011 07:03:39 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RdkBF-0002W1-Sr; Thu, 22 Dec 2011 15:03:37 +0000 Received: by bfk.de with local id 1RdkBF-0002OJ-PQ; Thu, 22 Dec 2011 15:03:37 +0000 From: Florian Weimer To: Bodo Moeller References: <201112211939.pBLJdovn015672@fs4113.wdf.sap.corp> <4EF23BB2.600@extendedsubset.com> Date: Thu, 22 Dec 2011 15:03:37 +0000 In-Reply-To: (Bodo Moeller's message of "Wed, 21 Dec 2011 21:28:32 +0100") Message-ID: <82ipl8d4xi.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Sending fatal alerts over TCP 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, 22 Dec 2011 15:03:43 -0000 * Bodo Moeller: > Note that this only implies that Y's TCP needs to process the segment > containing X's TLS alert before it can process the RST segment. Processing > the segment with the alert merely means queuing it; the TLS layer would > have to "RECEIVE" it from the TCP to do something with it. If the RST > segment gets processed before the TLS layer has received the TLS alert, t= he > receiving queue will be flushed, and the alert will be gone. Indeed, this is the correct explanation. This flushing behavior was introduced that when you hit ^C in your FTP client during a transfer, the transfer actually stops quickly, and does not continue until the server has transmitted all data. As a result, it is impossible to tear down full-duplex connections without potential data loss, unless the connection teardown is negotiated above the TCP layer. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From internet-drafts@ietf.org Mon Dec 26 00:50:26 2011 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 BDCA721F8AD3; Mon, 26 Dec 2011 00:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 TQyfSNPD31n4; Mon, 26 Dec 2011 00:50:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1021F8AB0; Mon, 26 Dec 2011 00:50:26 -0800 (PST) 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: 3.64p1 Message-ID: <20111226085026.30666.94584.idtracker@ietfa.amsl.com> Date: Mon, 26 Dec 2011 00:50:26 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-11.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, 26 Dec 2011 08:50:27 -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 Grou= p of the IETF. Title : Transport Layer Security (TLS) Cached Information Extens= ion Author(s) : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-11.txt Pages : 14 Date : 2011-12-26 Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt From hannes.tschofenig@gmx.net Mon Dec 26 01:47:02 2011 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 C363321F84D2 for ; Mon, 26 Dec 2011 01:47:02 -0800 (PST) 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 a-tQeDrIZClZ for ; Mon, 26 Dec 2011 01:47:01 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9BA2E21F8AEA for ; Mon, 26 Dec 2011 01:47:00 -0800 (PST) Received: (qmail invoked by alias); 26 Dec 2011 09:46:59 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp008) with SMTP; 26 Dec 2011 10:46:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182B/tKzi02z3XqxPdTkHotsihJYvYNn3JHTUwi86 TCfPRj8eQINmQB Message-ID: <4EF84292.50201@gmx.net> Date: Mon, 26 Dec 2011 11:46:58 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [TLS] TLS Cached Information Extension - version 11 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, 26 Dec 2011 09:47:02 -0000 Hi all, Nikos provided review comments (see http://www.ietf.org/mail-archive/web/tls/current/msg08338.html) and I have incorporated them in version 11 of the draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt As you can see, there are a number of smaller changes here and there. I hope that readability has improved. There is an open issue: algorithm negotiation Currently, the draft defines a registry for hash algorithms that are used to produce the hashes of cached information. The client can tell the server that it has already cached, for example, the certificate chain. The server then has to only send the fingerprint of it (rather than the complete certificate chain). The other information (besides certificate chains) that can be "fingerprinted" is the list of trusted CAs. Does this cover all use cases? A few algorithms are defined, namely SHA-1, SHA-224, SHA-256, SHA-384, SHA-512. Is this a good list to start with? The draft does not define a way for the client to tell the server that it only supports a certain hash algorithm. Should we allow the client to indicate what algorithm it supports? Ciao Hannes