From demoss.matt@gmail.com Fri Mar 4 09:16:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6923A6866 for ; Fri, 4 Mar 2011 09:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFhT7K2l7FDe for ; Fri, 4 Mar 2011 09:16:32 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AA00A3A6820 for ; Fri, 4 Mar 2011 09:16:29 -0800 (PST) Received: by fxm15 with SMTP id 15so2511491fxm.31 for ; Fri, 04 Mar 2011 09:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tNphEcMAogW72YjsCSZ7SW2b0nkwY5nlkoac4Yi/09s=; b=oPnNO0y5kzXTAWE/Kwr6EfhR0/bi+n8Xfct/GeXBAWxxphxEqiU2iyKmMZFYdMg3HN U6mFwwv10LNAj3J/FITOgGJrXPF033fi3wqMT+Cn0x2/sLh/QKkbP4Z4V42bg/QBBXcv HY7kL57cDfxHdF+VzBV40Ud0baMr+WUay4z4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QuopnDAae9Rr7hb8Mj3pPBJY6PiecQ4iY6ntUctYkm4maTL7PbG/zT/55NtxKXb/v0 9VGv8u+NTSFgA5E+V/TI8+Rkqqd5Jp656VULOY1jQZicClO/sxu0u6HLFJ55vNNSoEj+ W2w7BDj/zp14QfGyhZ5kikv1OQDUfekvhBR08= MIME-Version: 1.0 Received: by 10.223.16.148 with SMTP id o20mr1096302faa.149.1299259042849; Fri, 04 Mar 2011 09:17:22 -0800 (PST) Received: by 10.223.116.212 with HTTP; Fri, 4 Mar 2011 09:17:22 -0800 (PST) In-Reply-To: References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> Date: Fri, 4 Mar 2011 12:17:22 -0500 Message-ID: From: Matt DeMoss To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, Kyle Hamilton Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:16:32 -0000 I'd encourage consideration of client certificates also. If the client has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it needs a way to choose which chain to send during periods of transition where some servers will reject SHA2 and others will reject SHA3. An alternative design might have been to allow the client to send multiple chains and let the server choose the end-entity certificate of the chain it likes, but as it is now it looks to me like the only options for the server are to "either continue the handshake (considering the client unauthenticated) or send a fatal alert." On Mon, Feb 21, 2011 at 3:42 AM, Nikos Mavrogiannopoulos wrote: > On Mon, Feb 21, 2011 at 1:36 AM, Kyle Hamilton wrote= : >>> Forcing the TLS implementation to buffer all handshake messages is one >>> thing that probably a performance problem in TLSv1.2, but it's not a >>> compatibility issue and as someone said fixing it would require releasi= ng >>> TLSv1.3. However I don't see ANY sensible reasons why TLS would care ab= out >>> which signature algorithm is used for signing the actual certificate. A= s >>> long as the certificate contains the keys necessary to sign the key exc= hange >>> it should be fine just like it was before. >> Because TLS is the layer where communications policies are negotiated. = =A0The >> client is informing the server that (e.g.) it doesn't accept MD5 as a va= lid >> hash algorithm for realtime communication. =A0If it doesn't accept it fo= r >> realtime communication, there is also no reason to accept it for an offl= ine >> proof -- because an attacker has that much more time to find a preimage. > > Actually TLS negotiates things related to the TLS connection. The whole > communication policy is something TLS shouldn't be concerned with. > You say that the certificate signature algorithms are important enough > to be negotiated with TLS, I would add that not only signature algorithms= , > but also the key length of the certificate, and even the issuing date of > the certificate and the type of the SubjectAlternative name. This is perf= ectly > valid under your assumption that TLS should handle this stuff. > > Fortunately TLS left all the "communication policy" parts that do not > concern TLS (i.e. details of certificates), outside its negotiation. The > signatureAlgorithms was the first extension to negotiate something that > is not relevant for the TLS protocol. > >> Two reasons why this is inappropriate. =A0First, if the server doesn't h= ave a >> certificate chain the client will accept, it doesn't need to waste the >> bandwidth (it doesn't need to broadcast the server's details to someone = who >> won't accept them anyway). > > Well, given the way certificates are being used today, that extension can= not > really do much. A server will not request a new certificate from a CA, > just because a > client added the signatureAlgorithms extension in his clientHello and req= uested > SHA-224. > > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mike-list@pobox.com Fri Mar 4 12:15:04 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B073A6878 for ; Fri, 4 Mar 2011 12:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAArk5RbTuiB for ; Fri, 4 Mar 2011 12:15:03 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 78AAA3A6844 for ; Fri, 4 Mar 2011 12:15:02 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B69763896; Fri, 4 Mar 2011 15:17:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=zvfcRDiMQSjU aWbhoJV88A33feQ=; b=uuSRFEEJncTAfuL1hFmPfVS3hjMe7CsgyoJK9kFPI/Yl cT1LwTrl4eItl1M0NRQFBpfhhyoRZ/PMXi7Ya0B+tODOzsu05qsRWQsmHerVFraF EgiZ730HbLTnRhQTb2K0MHjchOrr+UQrA7VdTu9gANTu0J1Ob+dzD0Ucczmdp9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=BcqJcU XV9ubdBXPj7MG108Zpyxn0ZE3XO/Yt79wfHyTKY9Vfq+W07d4BlnnwlVg1vN1FvS QB2VD5KDFzEDd48YV1ZFWVGBznHWn6SlTJBpg7LpwMh/KG7z9FbpPM4LIavvXzic zMPxWs4kB2anqglJIkd88cvMu/O0wBkE8Begg= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A356E3895; Fri, 4 Mar 2011 15:17:32 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id F02AF3894; Fri, 4 Mar 2011 15:17:30 -0500 (EST) Message-ID: <4D714887.6060003@pobox.com> Date: Fri, 04 Mar 2011 12:16:07 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Matt DeMoss References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 6FC7B4B8-469C-11E0-BFAC-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 20:15:04 -0000 Matt DeMoss wrote: > I'd encourage consideration of client certificates also. If the client > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it > needs a way to choose which chain to send during periods of transition > where some servers will reject SHA2 and others will reject SHA3. Isn't this already in TLS 1.2? When the server requests a client certificate, the CertificateRequest includes a list of acceptable signature algorithms. The client can then check each of its certificate chains to find the best one the server can handle. Mike From mrex@sap.com Fri Mar 4 13:26:43 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCE33A6A36 for ; Fri, 4 Mar 2011 13:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIzX2KcAH1FR for ; Fri, 4 Mar 2011 13:26:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 612F33A67EF for ; Fri, 4 Mar 2011 13:26:42 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p24LRjVR011724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2011 22:27:50 +0100 (MET) From: Martin Rex Message-Id: <201103042127.p24LRix4011668@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 4 Mar 2011 22:27:44 +0100 (MET) In-Reply-To: <4D714887.6060003@pobox.com> from "Michael D'Errico" at Mar 4, 11 12:16:07 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] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 04 Mar 2011 21:26:43 -0000 Michael D'Errico wrote: > > Matt DeMoss wrote: > > I'd encourage consideration of client certificates also. If the client > > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it > > needs a way to choose which chain to send during periods of transition > > where some servers will reject SHA2 and others will reject SHA3. > > Isn't this already in TLS 1.2? When the server requests a client > certificate, the CertificateRequest includes a list of acceptable > signature algorithms. The client can then check each of its > certificate chains to find the best one the server can handle. It is *MUCH* worse than that. TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extension is sent, that the receiver MUST ensure that all certificates in the chain are from the signature_algorithm set. That is not just shooting yourself in the foot, that is shooting "the whole nine yards" (the entire ammunition belt) in your foot. -Martin From geoffk@geoffk.org Fri Mar 4 14:05:16 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CE128C0E7 for ; Fri, 4 Mar 2011 14:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dq2UUEXt5so for ; Fri, 4 Mar 2011 14:05:16 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 0A78028C0EB for ; Fri, 4 Mar 2011 14:05:16 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 7657533D199; Fri, 4 Mar 2011 22:06:24 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <4D714887.6060003@pobox.com> <201103042127.p24LRix4011668@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 04 Mar 2011 14:06:24 -0800 In-Reply-To: <201103042127.p24LRix4011668@fs4113.wdf.sap.corp> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 22:05:17 -0000 Martin Rex writes: > Michael D'Errico wrote: > > > > Matt DeMoss wrote: > > > I'd encourage consideration of client certificates also. If the client > > > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it > > > needs a way to choose which chain to send during periods of transition > > > where some servers will reject SHA2 and others will reject SHA3. > > > > Isn't this already in TLS 1.2? When the server requests a client > > certificate, the CertificateRequest includes a list of acceptable > > signature algorithms. The client can then check each of its > > certificate chains to find the best one the server can handle. > > It is *MUCH* worse than that. > > TLSv1.2 goes as far as _requiring_ that if the signature_algorithm > extension is sent, that the receiver MUST ensure that all certificates > in the chain are from the signature_algorithm set. That's in the server's chain, though, not the client's. For the client, the possible certificate algorithms and types are listed in the CertificateRequest, not in an extension, and the list is not optional. From mrex@sap.com Fri Mar 4 15:40:29 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196963A6A44 for ; Fri, 4 Mar 2011 15:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJlExeX8gxls for ; Fri, 4 Mar 2011 15:40:27 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 705A73A69DA for ; Fri, 4 Mar 2011 15:40:27 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p24NfWw9016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Mar 2011 00:41:32 +0100 (MET) From: Martin Rex Message-Id: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Sat, 5 Mar 2011 00:41:31 +0100 (MET) In-Reply-To: from "Geoffrey Keating" at Mar 4, 11 02:06:24 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] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 04 Mar 2011 23:40:29 -0000 Geoffrey Keating wrote: > > Martin Rex writes: > > > Michael D'Errico wrote: > > > > > > Matt DeMoss wrote: > > > > I'd encourage consideration of client certificates also. If the client > > > > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it > > > > needs a way to choose which chain to send during periods of transition > > > > where some servers will reject SHA2 and others will reject SHA3. > > > > > > Isn't this already in TLS 1.2? When the server requests a client > > > certificate, the CertificateRequest includes a list of acceptable > > > signature algorithms. The client can then check each of its > > > certificate chains to find the best one the server can handle. > > > > It is *MUCH* worse than that. > > > > TLSv1.2 goes as far as _requiring_ that if the signature_algorithm > > extension is sent, that the receiver MUST ensure that all certificates > > in the chain are from the signature_algorithm set. > > That's in the server's chain, though, not the client's. For the > client, the possible certificate algorithms and types are listed in the > CertificateRequest, not in an extension, and the list is not optional. http://tools.ietf.org/html/rfc5246#section-7.4.4 7.4.4. Certificate Request struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; supported_signature_algorithms A list of the hash/signature algorithm pairs that the server is able to verify, listed in descending order of preference. - Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. Adding support for sha256WithRsaEncryption in X.509 certs to the PKI module of an existing implementation of SSLv3 or TLSv1.0 in your installed base is an almost trivial software change. About a magnitude(!) less work&testing than implementing rfc-5746 (TLS extension RI). It is so easy that even Microsoft did it for XP & Win2K3 (unfortunately they only included it in XPsp3 -- for XPsp2 and XP 64-bit/Win2K3 it is manual work to download and install hotfix KB968730.) rfc5246 is a failed specification, because it adds several undue limitations and interop problems to the protocol that did not exist in TLSv1.0 and v1.1, that are technically inappropriate, completely unnecessary and in massive conflict with rfc-2119 section 6. The TLS spec should not mess around with PKI and X.509 issues. Negotiation of the algorithm used for the "digitally signed" struct ought to be _completely_ seperate from characteristics of certificates. A TLS extension to convey hints about digital signature algorithms ought to be a fairly black box to TLS, containing a list of ASN.1 AlgIds, and with the semantic of a "hint to the PKI software for selecting the most appropriate certificates", i.e. "MAY" not "MUST". Having the prerequisite for a signature algorithm to be used with TLSv1.2 that first official code points must be assigned by the IETF and then all TLS implementation must be updated to know how to translate a particular AlgId() into a newly defined TLS SignatureAlgorithm codepoint before a client certificate with a different crypto algorithm can be used looks like a pretty deep rathole with lots of huge and nasty rats at the bottom. Even Microsoft managed to design their TLSv1.0 protocol stack in Microsoft Windows XP in a fashion that it can be used with completely different cryptoalgorithms (like entirely from the GOST suite) with the installation of a CryptoCSP. Changing TLS in a fashion that makes this _much_ harder to get working is the wrong direction for the evolution of the TLS protocol. Personally, I consider several aspects of TLSv1.2 _unimplementable_ (i.e. it would break functionality we use and have shippped). But I believe it is possible to fix TLSv1.2, and in a fashion that remains interoperable with implementations of rfc-5246 (i.e. without breaking them). I also think there is a necessity for smoothing the transition to certificates with sha-2 based signatures for the installed base of pre-TLSv1.2. A transition that comes about 1/4 of the cost of RFC-5746 in terms of implementation and testing effort. Something that is so affordable that even Microsoft could ship it for WindowsXP. -Martin From geoffk@geoffk.org Fri Mar 4 16:23:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647703A6921 for ; Fri, 4 Mar 2011 16:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLaUfQqgM6fa for ; Fri, 4 Mar 2011 16:23:13 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 944E13A68A9 for ; Fri, 4 Mar 2011 16:23:13 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B26E633D199; Sat, 5 Mar 2011 00:24:19 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 04 Mar 2011 16:24:19 -0800 In-Reply-To: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> Message-ID: Lines: 86 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 00:23:14 -0000 Martin Rex writes: > Geoffrey Keating wrote: > > > > Martin Rex writes: > > > > > Michael D'Errico wrote: > > > > > > > > Matt DeMoss wrote: > > > > > I'd encourage consideration of client certificates also. If the client > > > > > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it > > > > > needs a way to choose which chain to send during periods of transition > > > > > where some servers will reject SHA2 and others will reject SHA3. > > > > > > > > Isn't this already in TLS 1.2? When the server requests a client > > > > certificate, the CertificateRequest includes a list of acceptable > > > > signature algorithms. The client can then check each of its > > > > certificate chains to find the best one the server can handle. > > > > > > It is *MUCH* worse than that. > > > > > > TLSv1.2 goes as far as _requiring_ that if the signature_algorithm > > > extension is sent, that the receiver MUST ensure that all certificates > > > in the chain are from the signature_algorithm set. > > > > That's in the server's chain, though, not the client's. For the > > client, the possible certificate algorithms and types are listed in the > > CertificateRequest, not in an extension, and the list is not optional. > > > http://tools.ietf.org/html/rfc5246#section-7.4.4 > > 7.4.4. Certificate Request > > struct { > ClientCertificateType certificate_types<1..2^8-1>; > SignatureAndHashAlgorithm > supported_signature_algorithms<2^16-1>; > DistinguishedName certificate_authorities<0..2^16-1>; > } CertificateRequest; > > supported_signature_algorithms > A list of the hash/signature algorithm pairs that the server is > able to verify, listed in descending order of preference. > > - Any certificates provided by the client MUST be signed using a > hash/signature algorithm pair found in > supported_signature_algorithms. > > > Adding support for sha256WithRsaEncryption in X.509 certs to the PKI > module of an existing implementation of SSLv3 or TLSv1.0 in your > installed base is an almost trivial software change. About a magnitude(!) > less work&testing than implementing rfc-5746 (TLS extension RI). I think you're talking here about the signature_algorithms extension, which is sent by the client to the server, not the CertificateRequest you quoted immediately above, which is sent by the server to the client. The CertificateRequest in TLSv1.1 does not include a supported_signature_algorithms field, so if you're using 1.1 or earlier there's just no way for the server to tell the client which hash algorithm to use if there's a choice. So, the software change required (to support a choice) is to implement TLSv1.2, which is possibly another order of magnitude more complicated than deploying basic TLS extension support. > Even Microsoft managed to design their TLSv1.0 protocol stack in > Microsoft Windows XP in a fashion that it can be used with completely > different cryptoalgorithms (like entirely from the GOST suite) > with the installation of a CryptoCSP. What do they send for certificate_types for GOST? IANA does not seem to have allocated a ClientCertificateType identifier, and the certificate_types field is present even in TLSv1.0. All your other points are good, but most are not relevant to the discussion of client certificates. A point which you didn't quite make, but which is close to one of the points that you did make and which I would have agreed with, is that the CertificateRequest should use OIDs to specify certificate types and algorithms rather than values assigned using IANA registries, and I'd support this for TLS 1.4. However, this is not quite as trivial as it sounds, because you must still consider how this interacts with OpenPGP certificates. From pgut001@login01.cs.auckland.ac.nz Fri Mar 4 22:38:29 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FD03A689F for ; Fri, 4 Mar 2011 22:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooN5u9paPBOM for ; Fri, 4 Mar 2011 22:38:27 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 063263A684D for ; Fri, 4 Mar 2011 22:38:24 -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=1299307177; x=1330843177; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20TLS=20v1.2 =20performance=20(was=20Re:=20TLSv1.2=20with=20DSA=20clie nt|Cc:=20tls@ietf.org|In-Reply-To:=20<201103042127.p24LRi x4011668@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Sat,=2005=20Mar =202011=2019:39:31=20+1300; bh=I+tCNJ4zjJgVKk6wDcs8dB6RI084EB68GyjZfCbzzXM=; b=EsC68EA31NWjC00vAJCnasAnWytmndX2JMqr4Uq//bwGkIfrQ/rjdbj4 yKJUKKDiCuQAaa8tSamFygGRXSkeuOaEBeOWa2JqU90qnyc1icGTpRl5+ AWtSy6oCTyr6/0eOb4DJ7WkuOnpxUDf27ZzCaK0zaR+pzQD4WryN2FvRm k=; X-IronPort-AV: E=Sophos;i="4.62,268,1296990000"; d="scan'208";a="49273925" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Mar 2011 19:39:32 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Pvl9H-0007dx-Ik; Sat, 05 Mar 2011 19:39:31 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Pvl9H-0006Ng-Oe; Sat, 05 Mar 2011 19:39:31 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201103042127.p24LRix4011668@fs4113.wdf.sap.corp> Message-Id: Date: Sat, 05 Mar 2011 19:39:31 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 06:38:29 -0000 Martin Rex writes: >It is *MUCH* worse than that. > >TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extension >is sent, that the receiver MUST ensure that all certificates in the chain are >from the signature_algorithm set. > >That is not just shooting yourself in the foot, that is shooting "the whole >nine yards" (the entire ammunition belt) in your foot. Just out of interest, how are other implemeters dealing with this? I looked at that requirement in the spec, decided it was totally crazy, and ignored it. So far I haven't found any other TLS 1.2 implementation (of the very few that are around) that has any problems with this, so my guess is everyone else is ignoring it as well. (There are a couple of other things in there that are completely nuts as well, if we could document the general consensus on what to ignore it might help other implementors who, God help us, decide to try and follow the spec). Peter. From mike-list@pobox.com Fri Mar 4 23:36:11 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2439B3A689E for ; Fri, 4 Mar 2011 23:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI9Lfand6nxd for ; Fri, 4 Mar 2011 23:36:09 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id B16C23A6800 for ; Fri, 4 Mar 2011 23:36:08 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C7A4D2719; Sat, 5 Mar 2011 02:38:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=+tB3/bIDZn7E 1wjSsFknXQyf7zM=; b=dzsZah4Re3JclrVJPSAvRZVCT4NMI6sfnr4OeWXtn430 euM08YVSRYa70Z67YahVtCK8qZDXxZhNtMF+tNloiy6GEDIfPqvSKNWbrkjOBNEg XLp4bNZ+aeDAZyrsu+CDMTfq8d1VdOkul1Mt+1/DsjYJ8ithwaTHpGSyd22npTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=YKvKJ2 So1VJCKBfC5PdvzDUCTLQlkHwk9elCVMe3iwFSYNv3MEKC7kLutrQTY9AnNuS7nF Juu2JyQNtO9pkfdb16k2rT4F0J3VV9R1biK/lv2a9JPaLVqi6sx0DtK290Y/BNcl yWSPmkive8a3GNDgaYGTfy7DSD7dsMScKjPQY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B30712718; Sat, 5 Mar 2011 02:38:40 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 2E5532717; Sat, 5 Mar 2011 02:38:38 -0500 (EST) Message-ID: <4D71E82A.2010702@pobox.com> Date: Fri, 04 Mar 2011 23:37:14 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 971A593A-46FB-11E0-A3C6-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 07:36:11 -0000 Peter Gutmann wrote: > Martin Rex writes: > >> It is *MUCH* worse than that. >> >> TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extension >> is sent, that the receiver MUST ensure that all certificates in the chain are >>from the signature_algorithm set. >> That is not just shooting yourself in the foot, that is shooting "the whole >> nine yards" (the entire ammunition belt) in your foot. > > Just out of interest, how are other implemeters dealing with this? I looked > at that requirement in the spec, decided it was totally crazy, and ignored it. > So far I haven't found any other TLS 1.2 implementation (of the very few that > are around) that has any problems with this, so my guess is everyone else is > ignoring it as well. My TLS code doesn't validate the server's certificate chain. Instead it passes all of the information to a callback function registered by the application; the return code determines whether to continue the handshake or not. See, TLS 1.2 isn't so hard to implement after all. :-) > (There are a couple of other things in there that are completely nuts as well, > if we could document the general consensus on what to ignore it might help > other implementors who, God help us, decide to try and follow the spec). Can you please list the other things you found to be completely nuts? Thanks, Mike From mrex@sap.com Fri Mar 4 23:54:19 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5E83A684D for ; Fri, 4 Mar 2011 23:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYHBKEovDETU for ; Fri, 4 Mar 2011 23:54:18 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id E41713A68B8 for ; Fri, 4 Mar 2011 23:54:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p257tJ7T005139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Mar 2011 08:55:19 +0100 (MET) From: Martin Rex Message-Id: <201103050755.p257tIPI016555@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 5 Mar 2011 08:55:18 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Mar 5, 11 07:39: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] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 05 Mar 2011 07:54:19 -0000 Peter Gutmann wrote: > > Martin Rex writes: > > >It is *MUCH* worse than that. > > > >TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extension > >is sent, that the receiver MUST ensure that all certificates in the chain are > >from the signature_algorithm set. > > > >That is not just shooting yourself in the foot, that is shooting "the whole > >nine yards" (the entire ammunition belt) in your foot. > > Just out of interest, how are other implemeters dealing with this? I looked > at that requirement in the spec, decided it was totally crazy, and ignored it. > So far I haven't found any other TLS 1.2 implementation (of the very few that > are around) that has any problems with this, so my guess is everyone else is > ignoring it as well. > > (There are a couple of other things in there that are completely nuts as well, > if we could document the general consensus on what to ignore it might help > other implementors who, God help us, decide to try and follow the spec). In case that you saw any of the I-D proposals and discussions around "document maturity" -- documents at "Proposed Standard" should be assumed to contain defects and Working Groups are expected to fix them... So rather than documenting the quirks in TLSv1.2, we should really fix them. But honestly, I'd really like to give a TLS extension for negotiating signature algorithms in a less aggresive fashion some implementation experience and a few miles on the road of usage before I would make it a mandatory part of a TLS spec, i.e. it should come in a fashion that it can be easily adopted by the large installed base of what is currently out there TLSv1.0 and v1.1. I think it was a sensible idea to make IPSEC an optional feature for IPv4 in order to gather experience, rather than holding it off for everybody until IPv6 is deployed... -Martin From n.mavrogiannopoulos@gmail.com Sat Mar 5 00:39:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E175C3A693D for ; Sat, 5 Mar 2011 00:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.69 X-Spam-Level: X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftQKscAnz1cN for ; Sat, 5 Mar 2011 00:39:06 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C699E3A6916 for ; Sat, 5 Mar 2011 00:39:05 -0800 (PST) Received: by eye13 with SMTP id 13so1090624eye.31 for ; Sat, 05 Mar 2011 00:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=lS8ty8RDgLgpVChaKdlu7ekAgK+li1aUr2hkXS0ynUY=; b=PoxK3LXkclj5OkHen21QGSjbWkm7FCgLVtgP0g8qMDLmGVcB83MnMmqjfothumZGDu DncW4u6Sp//yh1hd/9YZacDxZ2jjr4ksTqv901g5wPjyJ+0ljKgU41yqvYvf5o81Jj3N KBaHiOFd4/vB8WIXtBxisKd+JVXthTavij5/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=qlsbvYp6456vXOBB7IMW4RWzEJDKKKXVdm7Kukhs/RgAJbmJUVNdzY8NM0jF3Nb+A7 BJ4cK8C2dDnhr7yDm4a23BNaHZEJgmpxOrdMDvk7GrNnxU4N3kcePAQGf6WY/yWWpdor c2LDEZvpmKwRRwiOcdwv+SGmI24ZlkK2lv7Ek= Received: by 10.213.110.208 with SMTP id o16mr267756ebp.0.1299314415432; Sat, 05 Mar 2011 00:40:15 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id w59sm224140eeh.21.2011.03.05.00.40.13 (version=SSLv3 cipher=OTHER); Sat, 05 Mar 2011 00:40:14 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D71F6ED.2070100@gnutls.org> Date: Sat, 05 Mar 2011 09:40:13 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 08:39:07 -0000 On 03/05/2011 07:39 AM, Peter Gutmann wrote: > Martin Rex writes: > >> It is *MUCH* worse than that. >> TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extension >> is sent, that the receiver MUST ensure that all certificates in the chain are >>from the signature_algorithm set. >> That is not just shooting yourself in the foot, that is shooting "the whole >> nine yards" (the entire ammunition belt) in your foot. > Just out of interest, how are other implemeters dealing with this? I looked > at that requirement in the spec, decided it was totally crazy, and ignored it. Same for gnutls. regards, Nikos From n.mavrogiannopoulos@gmail.com Tue Mar 8 05:35:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1853A687A for ; Tue, 8 Mar 2011 05:35:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tURq1ogg74ba for ; Tue, 8 Mar 2011 05:35:35 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 72ED83A686C for ; Tue, 8 Mar 2011 05:35:35 -0800 (PST) Received: by qyk7 with SMTP id 7so4272501qyk.10 for ; Tue, 08 Mar 2011 05:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TtDlLfeOBZ9Djd7upaDMc2K+p2Allzy1sbFhhdWkN9I=; b=bQdlsD2kIEDdtH1bqlRtKEo1szPNaY3SsCrSNR6RgJBRf191Usg3hGvSDhGm+fP+M3 i/AJ24l6TrYsuUSettLTQ5lKDCaioYhUTHLftz9K7iARgdGakkRSdfaGxNzB2x/4QkNQ ptUZVOCMesljmnQlQKrJeQSkJwM8ObL0KfuvY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=fEy5ex5JPF9ytN1WYJJrbjKipL/2wLPURh7kl74UhTCFd/HfX6fwBjYlaBGRDPTvzq srn5PCMm/Fg8OeeDOSeKtqmS40RA9MMAii6eKvJRS7zxu/FIUlNPn7XmYnA+MMNB38X9 U1WboM4k3SRIgOIAz5xsRNeARShxedqQ0fu6Q= MIME-Version: 1.0 Received: by 10.229.114.80 with SMTP id d16mr4024953qcq.18.1299591409965; Tue, 08 Mar 2011 05:36:49 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Tue, 8 Mar 2011 05:36:49 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Tue, 8 Mar 2011 14:36:49 +0100 X-Google-Sender-Auth: ScctVKomRQIS2ls22BNEH3thA4w Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 13:35:36 -0000 On Mon, Feb 21, 2011 at 3:26 PM, Nikos Mavrogiannopoulos wrote: >> There is some guidance in 4.2.4.1 (1 second doubling up to 60 seconds.). >> Can you give me an idea of what sort of more detailed guidance you woud >> like? > How long would the client need to wait for the last flight retransmit (in order > to retransmit his finished)? If the application protocol requires the client > to start sending application data this is an issue. If there is no answer to that, then a DTLS handshake would always require a fixed amount of time (additional to calculations), e.g. 60 seconds - if we take the maximum time allowed for retransmission - to complete. That is because I see protocol transition from "handshake" -> "application data exchange" only after handshake has been fully completed. Or is it implicit that "draft-bmoeller-tls-falsestart-00" applies to DTLS? (in that case it should be explicit). regards, Nikos From ekr@rtfm.com Tue Mar 8 05:58:49 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FDE3A68A9 for ; Tue, 8 Mar 2011 05:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOeuUcU9+WbN for ; Tue, 8 Mar 2011 05:58:48 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9FBA93A68A6 for ; Tue, 8 Mar 2011 05:58:48 -0800 (PST) Received: by iwl42 with SMTP id 42so6135476iwl.31 for ; Tue, 08 Mar 2011 06:00:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.74.71 with SMTP id v7mr6654025icj.232.1299592803478; Tue, 08 Mar 2011 06:00:03 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 06:00:03 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Tue, 8 Mar 2011 06:00:03 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 13:58:49 -0000 On Tue, Mar 8, 2011 at 5:36 AM, Nikos Mavrogiannopoulos wrote: > On Mon, Feb 21, 2011 at 3:26 PM, Nikos Mavrogiannopoulos > wrote: > >>> There is some guidance in 4.2.4.1 (1 second doubling up to 60 seconds.). >>> Can you give me an idea of what sort of more detailed guidance you woud >>> like? >> How long would the client need to wait for the last flight retransmit (in order >> to retransmit his finished)? If the application protocol requires the client >> to start sending application data this is an issue. > > If there is no answer to that, then a DTLS handshake would always require > a fixed amount of time (additional to calculations), e.g. 60 seconds - > if we take > the maximum time allowed for retransmission - to complete. That is because > I see protocol transition from > "handshake" -> "application data exchange" > only after handshake has been fully completed. Or is it implicit that > "draft-bmoeller-tls-falsestart-00" applies to DTLS? (in that case it > should be explicit). I don't think I understand the question. As soon as either side has *received* the last message it expects to get from the other side, it can start sending data. However, it needs to buffer the last message that it sent in order to do a retransmit in case said message was lost. That retransmit is triggered by the other side retransmitting their last message (which has already been received and processed by the first side). So, to abstract away from DTLS, say that the last two messages of the handshake are; Alice -> Bob: Foo Bob -> Alice: Bar Alice sends "Foo" and waits for Bob to send "Bar". As soon as Bob has sent "Bar" he considers the handshake over and can start sending data. Alice needs to wait to receive "Bar". If she doesn't, then she times out and sends "Foo" which triggers Bob to retransmit "Bar". Note that this is actually partly true of TLS as well. Consider that in the normal handshake, the server receives the client's Finished and then sends his own Finished and then can start sending data. He has no way of knowing that the client actually received the server Finished (though TCP guarantees that the messages will be processed in order on the client.) We're just enforcing a looser version of the same property here. -Ekr From turners@ieca.com Tue Mar 8 07:28:03 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABAF3A68A6 for ; Tue, 8 Mar 2011 07:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+KOy4hxFInN for ; Tue, 8 Mar 2011 07:28:01 -0800 (PST) Received: from nm3-vm0.bullet.mail.ac4.yahoo.com (nm3-vm0.bullet.mail.ac4.yahoo.com [98.139.53.204]) by core3.amsl.com (Postfix) with SMTP id 311A63A68CC for ; Tue, 8 Mar 2011 07:28:01 -0800 (PST) Received: from [98.139.52.192] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 15:29:13 -0000 Received: from [98.139.52.172] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 15:29:13 -0000 Received: from [127.0.0.1] by omp1055.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 15:29:13 -0000 X-Yahoo-Newman-Id: 279010.65327.bm@omp1055.mail.ac4.yahoo.com Received: (qmail 31808 invoked from network); 8 Mar 2011 15:29:13 -0000 Received: from thunderfish.local (turners@96.231.129.124 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 08 Mar 2011 07:29:12 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: .bMWNqwVM1kW6KHexdXvS6lYkdHZ_zP_y8hQQO8RBCTYJzS xl_46ZTwqBZb05D1WdOsFaefC8xkrzXGCdzRs.qwBK7xnKBrP_c2OTKoDEqj PrSD_FRPatA_SIGSQSpnVpmoFIy1nNaahRk7sCg9NS3AHDhBOaTurI5er.d9 6RW_WmJ.tA4vkl8sgxWHO.Vjx0sVJHr.vxzBFKNKaFGkn21h6xgcJci0LvmY l0IPCF4bpWZAlsGUAinSUeQaKr_gnKdqzRHEKUmh9uiSev2dp8OqduIjRu87 eLKS69rAec7cjJDo6d75PQbRRqEnRxY7My7C6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D764B49.4080203@ieca.com> Date: Tue, 08 Mar 2011 10:29:13 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <20110223172955.27054.7913.idtracker@localhost> <4D654B4D.8020800@gnutls.org> <4D6B423D.1010402@po.ntts.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:28:03 -0000 On 2/28/11 3:45 AM, Nikos Mavrogiannopoulos wrote: > On Mon, Feb 28, 2011 at 7:35 AM, Satoru Kanno > wrote: > >>> I see that this document defines ciphersuites with a PRF based on >>> SHA384... However it does not specify the verify_data_length, thus >>> the default value of 12 applies, and the SHA384 PRF is being truncated >>> to 96 bits. Is this intentional? If yes, then what is the purpose to >>> use the SHA384 as PRF? >> Hi Nikos, >> Thank you for your comment. >> I think that the verify_data_length with a PRF based on >> SHA384 is specified in RFC5246. >> As a result, I refer to RFC5246 as well as other documents( e.g., RFC5289, >> RFC5487, and draft-nsri-tls-aria etc.,) in our document. >> I think that your comment is not only our draft but all documents specifying >> the PRF base on SHA384 for TLS. > > Yours was the first document I noticed to use SHA384 as PRF. If there > are other documents that specify that, and don't set the verify_data_length > size then it applies to those as well. (just noticed that applies to RFC5288 > as well). If the verify_data_length default is 12 (from 5246) then saying nothing means that it's still 12 right? Or, do you think an explicit statement saying "the default value for verify_data_length of 12 is used" is needed? spt From mrex@sap.com Tue Mar 8 07:58:59 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984083A68D9; Tue, 8 Mar 2011 07:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMKUjAbaKhja; Tue, 8 Mar 2011 07:58:58 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 792C83A68CE; Tue, 8 Mar 2011 07:58:58 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28Fxmd9018630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 16:59:48 +0100 (MET) From: Martin Rex Message-Id: <201103081559.p28Fxl3p027770@fs4113.wdf.sap.corp> To: turners@ieca.com (Sean Turner) Date: Tue, 8 Mar 2011 16:59:47 +0100 (MET) In-Reply-To: <4D764B49.4080203@ieca.com> from "Sean Turner" at Mar 8, 11 10:29:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 15:58:59 -0000 Sean Turner wrote: > > > > Yours was the first document I noticed to use SHA384 as PRF. If there > > are other documents that specify that, and don't set the verify_data_length > > size then it applies to those as well. (just noticed that applies to RFC5288 > > as well). > > If the verify_data_length default is 12 (from 5246) then saying nothing > means that it's still 12 right? Or, do you think an explicit statement > saying "the default value for verify_data_length of 12 is used" is needed? Truncating the PRF output to 12 octets for TLSv1.2 seems like an error. If truncating a SHA-1 based PRF in TLSv1.0/TLSv1.1 to 12 Octets is considered adequate (20/12), then truncation in TLSv1.2 with a SHA-256 based PRF should have been (32/20) and truncation for a SHA-384 based PRF should be more like (48/28) or (48/32). To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like unreasonable cutdown of the security margin for the Finished messages. -Martin From ekr@rtfm.com Tue Mar 8 08:28:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F403A68D9; Tue, 8 Mar 2011 08:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asiV0OltBArP; Tue, 8 Mar 2011 08:28:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id A73033A68B1; Tue, 8 Mar 2011 08:28:01 -0800 (PST) Received: by iyj8 with SMTP id 8so6236288iyj.31 for ; Tue, 08 Mar 2011 08:29:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr6968322icb.31.1299601754900; Tue, 08 Mar 2011 08:29:14 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 08:29:14 -0800 (PST) In-Reply-To: <201103081559.p28Fxl3p027770@fs4113.wdf.sap.corp> References: <4D764B49.4080203@ieca.com> <201103081559.p28Fxl3p027770@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 08:29:14 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:28:02 -0000 I don't understand this reasoning. Why does the output size of the pre-truncated PRF influence the desirable length of the verify_data (provided that the output size is > than the length of the verify_data of course). -Ekr On Tue, Mar 8, 2011 at 7:59 AM, Martin Rex wrote: > Sean Turner wrote: >> > >> > Yours was the first document I noticed to use SHA384 as PRF. If there >> > are other documents that specify that, and don't set the verify_data_l= ength >> > size then it applies to those as well. (just noticed that applies to R= FC5288 >> > as well). >> >> If the verify_data_length default is 12 (from 5246) then saying nothing >> means that it's still 12 right? =A0Or, do you think an explicit statemen= t >> saying "the default value for verify_data_length of 12 is used" is neede= d? > > > Truncating the PRF output to 12 octets for TLSv1.2 seems like an error. > > If truncating a SHA-1 based PRF in TLSv1.0/TLSv1.1 to 12 Octets is > considered adequate (20/12), then truncation in TLSv1.2 with > a SHA-256 based PRF should have been (32/20) and truncation for > a SHA-384 based PRF should be more like (48/28) or (48/32). > > To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like > unreasonable cutdown of the security margin for the Finished messages. > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From marsh@extendedsubset.com Tue Mar 8 08:51:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734C93A68F1; Tue, 8 Mar 2011 08:51:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m4N2G23ZZoY; Tue, 8 Mar 2011 08:51:36 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 44D343A68B1; Tue, 8 Mar 2011 08:51:36 -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 1PwzqP-000Jm6-CF; Tue, 08 Mar 2011 16:33:09 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 949C260CC; Tue, 8 Mar 2011 16:52:30 +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: U2FsdGVkX184tgt1NESkOO8LqptfCcs87kHmVwCKZno= Message-ID: <4D765ECD.105@extendedsubset.com> Date: Tue, 08 Mar 2011 10:52:29 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: mrex@sap.com References: <201103081559.p28Fxl3p027770@fs4113.wdf.sap.corp> In-Reply-To: <201103081559.p28Fxl3p027770@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:51:37 -0000 On 03/08/2011 09:59 AM, Martin Rex wrote: > > To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like > unreasonable cutdown of the security margin for the Finished messages. I agree. Last I looked into it, I came to the conclusion that collisions of any efficient 96 bit hash function are likely within range of today's supercomputers and botnets. But the logistics of it probably make it impractical for an actual attack. You need the master secret to manipulate the verify_data in any valid way (and if the attacker had that there'd be no security left to attack anyway). Otherwise, a useful attack on the finished message probably has to involve 2^48 or so live network connections to collide among. - Marsh From mrex@sap.com Tue Mar 8 09:19:20 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3903A6827; Tue, 8 Mar 2011 09:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOdvAxTxu6Ti; Tue, 8 Mar 2011 09:19:19 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4EDD63A68AF; Tue, 8 Mar 2011 09:19:19 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28HKV7L029197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 18:20:32 +0100 (MET) From: Martin Rex Message-Id: <201103081720.p28HKVFM002537@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 8 Mar 2011 18:20:31 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 8, 11 08:29:14 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 17:19:20 -0000 Eric Rescorla wrote: > > I don't understand this reasoning. Why does the output size of the > pre-truncated PRF > influence the desirable length of the verify_data (provided that the > output size is > than > the length of the verify_data of course). One of the purposes of a cryptographic hash function is to protect from collisions (both random and fabricated collisions). Cutting down the SHA-384 output from 48 to 12 octets significantly impairs its ability to protect from collisions. It's comparable to truncating the SHA-1 output from 20 to 5 octets. Unless you have _a_very_good_reason_ to truncate a hash output so severely, you very probably should not do it. -Martin From ekr@rtfm.com Tue Mar 8 09:32:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEFFC3A6936; Tue, 8 Mar 2011 09:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8E331h2E80R; Tue, 8 Mar 2011 09:32:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id EE5E03A6933; Tue, 8 Mar 2011 09:32:44 -0800 (PST) Received: by iyj8 with SMTP id 8so6304052iyj.31 for ; Tue, 08 Mar 2011 09:34:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.164.199 with SMTP id h7mr6957588icy.165.1299605639926; Tue, 08 Mar 2011 09:33:59 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 09:33:59 -0800 (PST) In-Reply-To: <201103081720.p28HKVFM002537@fs4113.wdf.sap.corp> References: <201103081720.p28HKVFM002537@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 09:33:59 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:32:46 -0000 On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> I don't understand this reasoning. Why does the output size of the >> pre-truncated PRF >> influence the desirable length of the verify_data (provided that the >> output size is > than >> the length of the verify_data of course). > > One of the purposes of a cryptographic hash function is to protect > from collisions (both random and fabricated collisions). > > Cutting down the SHA-384 output from 48 to 12 octets significantly impair= s > its ability to protect from collisions. =A0It's comparable to > truncating the SHA-1 output from 20 to 5 octets. I don't understand this analysis. Consider two ideal PRFs: * R-160 with a 160-bit output * R-256 with a 256-bit output Now, consider the function R-256-Reduced, which takes the first 160 bits of R-256. Are you arguing that R-256-Reduced is weaker than R-160? If so, why? -Ekr From mrex@sap.com Tue Mar 8 10:06:43 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82003A68F7; Tue, 8 Mar 2011 10:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlVjjl952Ho8; Tue, 8 Mar 2011 10:06:43 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C4A323A6921; Tue, 8 Mar 2011 10:06:42 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p28I7pIh027017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 19:07:56 +0100 (MET) From: Martin Rex Message-Id: <201103081807.p28I7o8C005329@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 8 Mar 2011 19:07:50 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 8, 11 09:33:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 18:06:43 -0000 Eric Rescorla wrote: > > On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex wrote: > > Eric Rescorla wrote: > >> > >> I don't understand this reasoning. Why does the output size of the > >> pre-truncated PRF > >> influence the desirable length of the verify_data (provided that the > >> output size is > than > >> the length of the verify_data of course). > > > > One of the purposes of a cryptographic hash function is to protect > > from collisions (both random and fabricated collisions). > > > > Cutting down the SHA-384 output from 48 to 12 octets significantly impairs > > its ability to protect from collisions.  It's comparable to > > truncating the SHA-1 output from 20 to 5 octets. > > I don't understand this analysis. Consider two ideal PRFs: > > * R-160 with a 160-bit output > * R-256 with a 256-bit output > > Now, consider the function R-256-Reduced, > which takes the first 160 bits of R-256. > Are you arguing that R-256-Reduced is weaker than R-160? If so, why? What we're having are the two cases: 1) R-160 truncated to 96 bits 2) R-256 truncated to 96 bits 3) R-160 with full 160-bits If your primary focus was collision avoidance, then 3) is stronger than 1) and 2) by a huge margin. There may be reasons why you don't want (3), like an attackers ability to verify when he guesses keys correctly that are input to the PRF. When 20/12 is a good truncation ratio for a 160-bit PRF, then 48/12 looks like a poor truncation ratio for a 384-bit PRF (and SHA-384 is already a truncated SHA-512 anyway). Applying the 20/12 tradeoff to R-256 results in approximately (32/20) and to R-384 results in approximately (48/28) -- with (48/32) probably sufficiently close. -Martin From ekr@rtfm.com Tue Mar 8 10:10:24 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3893A6936; Tue, 8 Mar 2011 10:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa6GBmZVQBeW; Tue, 8 Mar 2011 10:10:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7FBE03A68F7; Tue, 8 Mar 2011 10:10:23 -0800 (PST) Received: by iyj8 with SMTP id 8so6342386iyj.31 for ; Tue, 08 Mar 2011 10:11:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr7105290icb.31.1299607898642; Tue, 08 Mar 2011 10:11:38 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 10:11:38 -0800 (PST) In-Reply-To: <201103081807.p28I7o8C005329@fs4113.wdf.sap.corp> References: <201103081807.p28I7o8C005329@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 10:11:38 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:10:24 -0000 On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex wrote: >> > Eric Rescorla wrote: >> >> >> >> I don't understand this reasoning. Why does the output size of the >> >> pre-truncated PRF >> >> influence the desirable length of the verify_data (provided that the >> >> output size is > than >> >> the length of the verify_data of course). >> > >> > One of the purposes of a cryptographic hash function is to protect >> > from collisions (both random and fabricated collisions). >> > >> > Cutting down the SHA-384 output from 48 to 12 octets significantly imp= airs >> > its ability to protect from collisions. =A0It's comparable to >> > truncating the SHA-1 output from 20 to 5 octets. >> >> I don't understand this analysis. Consider two ideal PRFs: >> >> * R-160 with a 160-bit output >> * R-256 with a =A0256-bit output >> >> Now, consider the function R-256-Reduced, >> which takes the first 160 bits of R-256. >> Are you arguing that R-256-Reduced is weaker than R-160? If so, why? > > What we're having are the two cases: > > =A01) =A0R-160 truncated to 96 bits > =A02) =A0R-256 truncated to 96 bits > =A03) =A0R-160 with full 160-bits > > > If your primary focus was collision avoidance, then > 3) is stronger than 1) and 2) by a huge margin. Yes, I totally agree. > There may be reasons why you don't want (3), like an attackers ability > to verify when he guesses keys correctly that are input to the PRF. > > When 20/12 is a good truncation ratio for a 160-bit PRF, > then 48/12 looks like a poor truncation ratio for a 384-bit PRF > (and SHA-384 is already a truncated SHA-512 anyway). > Applying the 20/12 tradeoff to R-256 results in approximately (32/20) > and to R-384 results in approximately (48/28) -- with (48/32) probably > sufficiently close. I don't understand this analysis at all. Again, are you arguing that (1) and (2) have different security properties? If not, then why does it matter what the size of the input PRF is, as long as it is >=3D the size to which it is truncated? -Ekr From marsh@extendedsubset.com Tue Mar 8 10:14:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7F43A6960; Tue, 8 Mar 2011 10:14:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glcqeQw2q7nI; Tue, 8 Mar 2011 10:14:36 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id F10ED3A68EC; Tue, 8 Mar 2011 10:14:35 -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 1Px18j-0008Nc-AW; Tue, 08 Mar 2011 17:56:09 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CC6436314; Tue, 8 Mar 2011 18:15:31 +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/2S0IcN2fvbk5sdoWP9NKyg+XzcpKBxig= Message-ID: <4D767242.10202@extendedsubset.com> Date: Tue, 08 Mar 2011 12:15:30 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla References: <201103081720.p28HKVFM002537@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:14:37 -0000 On 03/08/2011 11:33 AM, Eric Rescorla wrote: > On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex wrote: >> Eric Rescorla wrote: >>> >>> I don't understand this reasoning. Why does the output size of the >>> pre-truncated PRF >>> influence the desirable length of the verify_data (provided that the >>> output size is> than >>> the length of the verify_data of course). >> >> One of the purposes of a cryptographic hash function is to protect >> from collisions (both random and fabricated collisions). As I mentioned, that appears not to be the case here, but I have found no written rationale for this design subtlety. I could be missing something. It's also possible that some cipher suite or mode could be added in the future that makes a collision on the verify_data significant. >> Cutting down the SHA-384 output from 48 to 12 octets significantly impairs >> its ability to protect from collisions. It's comparable to >> truncating the SHA-1 output from 20 to 5 octets. I think it's more comparable truncating SHA-1 down to 12 octets. > I don't understand this analysis. Consider two ideal PRFs: > > * R-160 with a 160-bit output > * R-256 with a 256-bit output > > Now, consider the function R-256-Reduced, which takes the first 160 > bits of R-256. > Are you arguing that R-256-Reduced is weaker than R-160? If so, why? I think he's arguing that anything cut down to 96 bits represents a lousy hash function allowing practical collisions on today's hardware. The implication for TLS protocol evolution (and anything else interpreting bytes-on-the-wire) is to keep in mind that the Finished.verify_data is simply not designed to resist offline collision attacks. Remember to bring this up the next time somebody suggests permitting endpoints to use lousy RNGs, particularly in conjunction with certificates with fixed DH parameters. - Marsh From ekr@rtfm.com Tue Mar 8 10:21:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB103A68AF; Tue, 8 Mar 2011 10:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKxLox9qk0PA; Tue, 8 Mar 2011 10:21:12 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4ED883A689A; Tue, 8 Mar 2011 10:21:12 -0800 (PST) Received: by iwl42 with SMTP id 42so6415959iwl.31 for ; Tue, 08 Mar 2011 10:22:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr7118916icb.31.1299608547144; Tue, 08 Mar 2011 10:22:27 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 10:22:27 -0800 (PST) In-Reply-To: <4D767242.10202@extendedsubset.com> References: <201103081720.p28HKVFM002537@fs4113.wdf.sap.corp> <4D767242.10202@extendedsubset.com> Date: Tue, 8 Mar 2011 10:22:27 -0800 Message-ID: From: Eric Rescorla To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:21:14 -0000 On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray wrote= : > On 03/08/2011 11:33 AM, Eric Rescorla wrote: >> >> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex =A0wrote: >>> Cutting down the SHA-384 output from 48 to 12 octets significantly >>> impairs >>> its ability to protect from collisions. =A0It's comparable to >>> truncating the SHA-1 output from 20 to 5 octets. > > I think it's more comparable truncating SHA-1 down to 12 octets. Yes, this matches my analysis. >> I don't understand this analysis. Consider two ideal PRFs: >> >> * R-160 with a 160-bit output >> * R-256 with a =A0256-bit output >> >> Now, consider the function R-256-Reduced, which takes the first 160 >> bits of R-256. >> Are you arguing that R-256-Reduced is weaker than R-160? If so, why? > > I think he's arguing that anything cut down to 96 bits represents a lousy > hash function allowing practical collisions on today's hardware. Perhaps, but this isn't a digest but rather a MAC, and so the attack model is different. Without knowing the key, you basically have a 2^{-b} chance of producing an input which will pass the MA= C check, where b is the length of the MAC. Note that additional computational power doesn't help much here because you still need to search the entire key space, not the output space, in order to break the MAC. However, the answer to *this* question is a distinct from whether a differe= nt size hash function used as the basis for a MAC demands a different truncati= on. -Ekr From mrex@sap.com Tue Mar 8 10:29:54 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0C63A6921; Tue, 8 Mar 2011 10:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE88CKqVPHIY; Tue, 8 Mar 2011 10:29:27 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C51F93A693F; Tue, 8 Mar 2011 10:29:26 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28IUdL0006668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 19:30:39 +0100 (MET) From: Martin Rex Message-Id: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 8 Mar 2011 19:30:39 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 8, 11 10:11:38 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 18:29:54 -0000 Eric Rescorla wrote: > > On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex wrote: > > Eric Rescorla wrote: > >> > >> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex wrote: > >> > Eric Rescorla wrote: > >> >> > >> >> I don't understand this reasoning. Why does the output size of the > >> >> pre-truncated PRF > >> >> influence the desirable length of the verify_data (provided that the > >> >> output size is > than > >> >> the length of the verify_data of course). > >> > > >> > One of the purposes of a cryptographic hash function is to protect > >> > from collisions (both random and fabricated collisions). > >> > > >> > Cutting down the SHA-384 output from 48 to 12 octets significantly impairs > >> > its ability to protect from collisions.  It's comparable to > >> > truncating the SHA-1 output from 20 to 5 octets. > >> > >> I don't understand this analysis. Consider two ideal PRFs: > >> > >> * R-160 with a 160-bit output > >> * R-256 with a  256-bit output > >> > >> Now, consider the function R-256-Reduced, > >> which takes the first 160 bits of R-256. > >> Are you arguing that R-256-Reduced is weaker than R-160? If so, why? > > > > What we're having are the two cases: > > > >  1)  R-160 truncated to 96 bits > >  2)  R-256 truncated to 96 bits > >  3)  R-160 with full 160-bits > > > > > > If your primary focus was collision avoidance, then > > 3) is stronger than 1) and 2) by a huge margin. > > Yes, I totally agree. > > > > There may be reasons why you don't want (3), like an attackers ability > > to verify when he guesses keys correctly that are input to the PRF. > > > > When 20/12 is a good truncation ratio for a 160-bit PRF, > > then 48/12 looks like a poor truncation ratio for a 384-bit PRF > > (and SHA-384 is already a truncated SHA-512 anyway). > > Applying the 20/12 tradeoff to R-256 results in approximately (32/20) > > and to R-384 results in approximately (48/28) -- with (48/32) probably > > sufficiently close. > > I don't understand this analysis at all. Again, are you arguing that > (1) and (2) have different security properties? In case they were both "ideal" - no. But in that case, asking anyone for the effort to replace 1) with 2) would be a complete waste of resources. If we move in a new, stronger crypto-algorithm, then we should not unreasonably spoil its properties. Truncating a SHA-384 based PRF to 12 octets is like using an sha384WithRsaEncryption signature with a 1024 bit RSA key, it is an imbalanced pairing of algorithms&keys. -Martin From ekr@rtfm.com Tue Mar 8 10:34:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F293A68AF; Tue, 8 Mar 2011 10:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ddY9CFiCHC0; Tue, 8 Mar 2011 10:34:12 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B73053A689A; Tue, 8 Mar 2011 10:34:11 -0800 (PST) Received: by iwl42 with SMTP id 42so6430672iwl.31 for ; Tue, 08 Mar 2011 10:35:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.189.202 with SMTP id df10mr6109439icb.366.1299609326772; Tue, 08 Mar 2011 10:35:26 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 10:35:26 -0800 (PST) In-Reply-To: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp> References: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 10:35:26 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:34:13 -0000 On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex wrote: >> > Eric Rescorla wrote: >> >> >> >> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex wrote: >> >> > Eric Rescorla wrote: >> >> >> >> >> >> I don't understand this reasoning. Why does the output size of the >> >> >> pre-truncated PRF >> >> >> influence the desirable length of the verify_data (provided that t= he >> >> >> output size is > than >> >> >> the length of the verify_data of course). >> >> > >> >> > One of the purposes of a cryptographic hash function is to protect >> >> > from collisions (both random and fabricated collisions). >> >> > >> >> > Cutting down the SHA-384 output from 48 to 12 octets significantly = impairs >> >> > its ability to protect from collisions. =A0It's comparable to >> >> > truncating the SHA-1 output from 20 to 5 octets. >> >> >> >> I don't understand this analysis. Consider two ideal PRFs: >> >> >> >> * R-160 with a 160-bit output >> >> * R-256 with a =A0256-bit output >> >> >> >> Now, consider the function R-256-Reduced, >> >> which takes the first 160 bits of R-256. >> >> Are you arguing that R-256-Reduced is weaker than R-160? If so, why? >> > >> > What we're having are the two cases: >> > >> > =A01) =A0R-160 truncated to 96 bits >> > =A02) =A0R-256 truncated to 96 bits >> > =A03) =A0R-160 with full 160-bits >> > >> > >> > If your primary focus was collision avoidance, then >> > 3) is stronger than 1) and 2) by a huge margin. >> >> Yes, I totally agree. >> >> >> > There may be reasons why you don't want (3), like an attackers ability >> > to verify when he guesses keys correctly that are input to the PRF. >> > >> > When 20/12 is a good truncation ratio for a 160-bit PRF, >> > then 48/12 looks like a poor truncation ratio for a 384-bit PRF >> > (and SHA-384 is already a truncated SHA-512 anyway). >> > Applying the 20/12 tradeoff to R-256 results in approximately (32/20) >> > and to R-384 results in approximately (48/28) -- with (48/32) probably >> > sufficiently close. >> >> I don't understand this analysis at all. Again, are you arguing that >> (1) and (2) have different security properties? > > In case they were both "ideal" - no. > > But in that case, asking anyone for the effort to replace > 1) with 2) would be a complete waste of resources. > > > If we move in a new, stronger crypto-algorithm, then we should not > unreasonably spoil its properties. > > Truncating a SHA-384 based PRF to 12 octets is like using > an sha384WithRsaEncryption signature with a 1024 bit RSA key, > it is an imbalanced pairing of algorithms&keys. Again, I don't understand this: TLS already (as of TLS 1.0) truncated the PRF down to 12 bytes, so we are already producing an output that is substantially shorter than the digest that is the basis of the function. If the security arguments for why that is good are valid (and FWIW I think they are) then as far as I can tell they are equally applicable to SHA-384. -Ekr From mrex@sap.com Tue Mar 8 10:44:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009E93A699C; Tue, 8 Mar 2011 10:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB2qGSu1qgsI; Tue, 8 Mar 2011 10:44:01 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B4C383A695B; Tue, 8 Mar 2011 10:44:00 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28IjD6R008521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 19:45:13 +0100 (MET) From: Martin Rex Message-Id: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 8 Mar 2011 19:45:12 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 8, 11 10:22:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 18:44:02 -0000 Eric Rescorla wrote: > > Marsh Ray wrote: > > > > I think he's arguing that anything cut down to 96 bits represents a lousy > > hash function allowing practical collisions on today's hardware. > > Perhaps, but this isn't a digest but rather a MAC, and so the attack > model is different. You seem to be forgetting that the finished messages have been reused for other purposes already: RFC-5929 TLS Channel Bindings RFC-5746 TLS extension Renegotiation indication I'm sorry, but I think it is a bad idea to use a flawed design for the TLS finished message by subverting the collision resistence of stronger secure hash functions that are used for the PRF. -Martin From ekr@rtfm.com Tue Mar 8 10:49:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27863A693A; Tue, 8 Mar 2011 10:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-Syz+yThibb; Tue, 8 Mar 2011 10:49:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E7ECF3A68AF; Tue, 8 Mar 2011 10:49:50 -0800 (PST) Received: by iyj8 with SMTP id 8so6383731iyj.31 for ; Tue, 08 Mar 2011 10:51:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.58.135 with SMTP id wk7mr6796871icb.433.1299610265989; Tue, 08 Mar 2011 10:51:05 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 10:51:05 -0800 (PST) In-Reply-To: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> References: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 10:51:05 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:49:51 -0000 On Tue, Mar 8, 2011 at 10:45 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> Marsh Ray wrote: >> > >> > I think he's arguing that anything cut down to 96 bits represents a lo= usy >> > hash function allowing practical collisions on today's hardware. >> >> Perhaps, but this isn't a digest but rather a MAC, and so the attack >> model is different. > > You seem to be forgetting that the finished messages have been reused > for other purposes already: No, I'm not forgetting that. That doesn't change the fact that the computation is a MAC. > =A0 RFC-5929 TLS Channel Bindings > =A0 RFC-5746 TLS extension Renegotiation indication > > > I'm sorry, but I think it is a bad idea to use a flawed design for > the TLS finished message by subverting the collision resistence > of stronger secure hash functions that are used for the PRF. Yes, I realize you think that, but until you offer a cryptographic argument for that opinion I guess we're just going to have to disagree. -Ekr From mrex@sap.com Tue Mar 8 10:57:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6C53A691D; Tue, 8 Mar 2011 10:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G721Bm5W6t+D; Tue, 8 Mar 2011 10:57:40 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5EEEA3A6817; Tue, 8 Mar 2011 10:57:39 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28Iwmsf009699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 19:58:53 +0100 (MET) From: Martin Rex Message-Id: <201103081858.p28IwmZs008062@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 8 Mar 2011 19:58:48 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 8, 11 10:35:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 18:57:41 -0000 Eric Rescorla wrote: > > > > > If we move in a new, stronger crypto-algorithm, then we should not > > unreasonably spoil its properties. > > > > Truncating a SHA-384 based PRF to 12 octets is like using > > an sha384WithRsaEncryption signature with a 1024 bit RSA key, > > it is an imbalanced pairing of algorithms&keys. > > Again, I don't understand this: TLS already (as of TLS 1.0) truncated > the PRF down to 12 bytes, so we are already producing an output that is > substantially shorter than the digest that is the basis of the function. > If the security arguments for why that is good are valid (and FWIW I > think they are) then as far as I can tell they are > equally applicable to SHA-384. The truncation of hashes/PRFs/HMACs is a trade-off. A trade-off between collision-resistance and how much clue is provided about the input. A (20/0) trade-off provides the smalles possible clue, but completely spoils the collision-resistance (i.e. it becomes useless for verification purposes). A (20/20) trade-off retains the full collision resistance, but provides the largest amount of clue for verification of input paramters. The trade-off that was chosen for SHA-1 was (20/12) or (160/96). which is 1.666666666 TLS uses a different trade-off, but I'm not aware of any rationale why the original trade-off in TLSv1.0/TLSv1.1 should have been inappropriate. The logical choice in TLSv1.2 would therefore have been to use (32/20) = 1.6 for a PRF that uses SHA-256. And any _other_ trade-off (such as the one in rfc-5246) should require a _new_ justification. -Martin From mrex@sap.com Tue Mar 8 11:22:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E873A693A; Tue, 8 Mar 2011 11:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQfEVAb1bxQi; Tue, 8 Mar 2011 11:22:36 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0865D3A680F; Tue, 8 Mar 2011 11:22:35 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28JNmUx011847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 20:23:48 +0100 (MET) From: Martin Rex Message-Id: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 8 Mar 2011 20:23:47 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 8, 11 10:51:05 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 19:22:37 -0000 Eric Rescorla wrote: > > > > > I'm sorry, but I think it is a bad idea to use a flawed design for > > the TLS finished message by subverting the collision resistence > > of stronger secure hash functions that are used for the PRF. > > Yes, I realize you think that, but until you offer a cryptographic > argument for that opinion I guess we're just going to have to disagree. You got it backwards. I say that it is a bad idea to truncate a PRF based on SHA-256 to 96, and even worse idea to truncate a PRF based on SHA-384 -- and anyone who wants to do that should better provide a good cryptograhic argument. Truncating HMACs and PRFs may have become first popular in the IETF within IPSEC. Looking at this table: http://tools.ietf.org/html/rfc4868#section-2.6 +------------------+--------+--------+--------+--------+------------+ | Algorithm | Block | Output | Trunc. | Key | Algorithm | | ID | Size | Length | Length | Length | Type | +==================+========+========+========+========+============+ | HMAC-SHA-256-128 | 512 | 256 | 128 | 256 | auth/integ | +------------------+--------+--------+--------+--------+------------+ | HMAC-SHA-384-192 | 1024 | 384 | 192 | 384 | auth/integ | +------------------+--------+--------+--------+--------+------------+ | HMAC-SHA-512-256 | 1024 | 512 | 256 | 512 | auth/integ | +------------------+--------+--------+--------+--------+------------+ | PRF-HMAC-SHA-256 | 512 | 256 | (none) | var | PRF | +------------------+--------+--------+--------+--------+------------+ | PRF-HMAC-SHA-384 | 1024 | 384 | (none) | var | PRF | +------------------+--------+--------+--------+--------+------------+ | PRF-HMAC-SHA-512 | 1024 | 512 | (none) | var | PRF | +------------------+--------+--------+--------+--------+------------+ If there existed a cryptographic argument (which you insist on) then I'm sure there would be an HMAC-SHA-394-96 in the above list. What is your argument why there should be a HMAC-SHA-384-96 in that list? (which would apply to a ciphersuite with a SHA-384 based PRF and finished messages truncated to 12 octets). -Martin From marsh@extendedsubset.com Tue Mar 8 11:32:01 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62153A6959; Tue, 8 Mar 2011 11:32: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdLIUqpOjvyN; Tue, 8 Mar 2011 11:31:23 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 0E73A3A67F2; Tue, 8 Mar 2011 11:31:23 -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 1Px2L2-000LCC-Ek; Tue, 08 Mar 2011 19:12:56 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A9C1D62E4; Tue, 8 Mar 2011 19:32:20 +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+S/CntOWbeW9W9jUBPlXgKeIdOG7jyboA= Message-ID: <4D768442.20902@extendedsubset.com> Date: Tue, 08 Mar 2011 13:32:18 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: mrex@sap.com References: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> In-Reply-To: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:32:04 -0000 On 03/08/2011 12:45 PM, Martin Rex wrote: > > RFC-5746 TLS extension Renegotiation indication Yes, it would be bad if those could be collided. > I'm sorry, but I think it is a bad idea to use a flawed design for > the TLS finished message by subverting the collision resistence > of stronger secure hash functions that are used for the PRF. Here's how my reasoning goes. I could be wrong. The Finished.verify_data represents a 96-bit MAC, not a general-purpose cryptographic hash function. The attacker is presumed to have the ability to modify data at some points in the protocol stream. The protocol relies on correct validiation of the verify_data to detect this condition and abort. Master_secret is not known to the attacker, if the connection is properly authenticated. The authentication only depends on the verify_data to prevent downgrade attacks. But if the authentication is broken, the attacker can simply issue the proper MAC and has no need to collide them. Master_secret is very long, changes every full handshake, and is required to compute the MAC. Any offline precomputation the attacker could do in support of collision finding requires the ability to compute the MAC function for the actual master_secret (as computed by the client or the server including locally-generated entropy not received from the attacker). Therefore, collisions on the Finshed.verify_data require active sessions to be useful and the attacker will need to amass a pool of about 2^48 of them to collide between. - Marsh From prvs=2048c768d4=uri@ll.mit.edu Tue Mar 8 11:35:21 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32DA3A693A for ; Tue, 8 Mar 2011 11:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucngfIFJ+F73 for ; Tue, 8 Mar 2011 11:35:20 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 9B3423A6814 for ; Tue, 8 Mar 2011 11:35:20 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p28JaZd5015608 for ; Tue, 8 Mar 2011 14:36:35 -0500 From: "Blumenthal, Uri - 0668 - MITLL" To: "'tls@ietf.org'" Date: Tue, 8 Mar 2011 14:36:34 -0500 Thread-Topic: [TLS] Last Call: (Additionx Thread-Index: Acvdxl6uFcU47Fz6RN+4QJ1Sr6rPiAAAbTWu In-Reply-To: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_07:2011-03-08, 2011-03-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103080118 Message-Id: <20110308193520.9B3423A6814@core3.amsl.com> Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:35:22 -0000 In general - since pseudorandom-ness of the output was NOT a design princip= le or criteria of hash functions (until SHA3) - truncating hash output is p= roblematic from crypto point because you cannot reasonably assume that all = the output bits have the "entropy" spread over them equally. =20 -- Regards, Uri ----- Original Message ----- From: Martin Rex [mailto:mrex@sap.com] Sent: Tuesday, March 08, 2011 02:23 PM=0A= To: Eric Rescorla Cc: tls@ietf.org ; ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx Eric Rescorla wrote: >=20 > > > > I'm sorry, but I think it is a bad idea to use a flawed design for > > the TLS finished message by subverting the collision resistence > > of stronger secure hash functions that are used for the PRF. >=20 > Yes, I realize you think that, but until you offer a cryptographic > argument for that opinion I guess we're just going to have to disagree. You got it backwards. I say that it is a bad idea to truncate a PRF based on SHA-256 to 96, and even worse idea to truncate a PRF based on SHA-384 -- and anyone who wants to do that should better provide a good cryptograhic argument. Truncating HMACs and PRFs may have become first popular in the IETF within IPSEC. Looking at this table: http://tools.ietf.org/html/rfc4868#section-2.6 +------------------+--------+--------+--------+--------+------------+ | Algorithm | Block | Output | Trunc. | Key | Algorithm | | ID | Size | Length | Length | Length | Type | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | HMAC-SHA-256-128 | 512 | 256 | 128 | 256 | auth/integ | +------------------+--------+--------+--------+--------+------------+ | HMAC-SHA-384-192 | 1024 | 384 | 192 | 384 | auth/integ | +------------------+--------+--------+--------+--------+------------+ | HMAC-SHA-512-256 | 1024 | 512 | 256 | 512 | auth/integ | +------------------+--------+--------+--------+--------+------------+ | PRF-HMAC-SHA-256 | 512 | 256 | (none) | var | PRF | +------------------+--------+--------+--------+--------+------------+ | PRF-HMAC-SHA-384 | 1024 | 384 | (none) | var | PRF | +------------------+--------+--------+--------+--------+------------+ | PRF-HMAC-SHA-512 | 1024 | 512 | (none) | var | PRF | +------------------+--------+--------+--------+--------+------------+ If there existed a cryptographic argument (which you insist on) then I'm sure there would be an HMAC-SHA-394-96 in the above list. What is your argument why there should be a HMAC-SHA-384-96 in that list? (which would apply to a ciphersuite with a SHA-384 based PRF and finished messages truncated to 12 octets). -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Tue Mar 8 12:14:43 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DD93A67B3; Tue, 8 Mar 2011 12:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McwtiEhuBv-2; Tue, 8 Mar 2011 12:14:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 7FB723A6781; Tue, 8 Mar 2011 12:14:42 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p28KFpwC011952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 21:15:56 +0100 (MET) From: Martin Rex Message-Id: <201103082015.p28KFo12012459@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 8 Mar 2011 21:15:50 +0100 (MET) In-Reply-To: <201103081858.p28IwmZs008062@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 8, 11 07:58:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 20:14:43 -0000 Martin Rex wrote: > > The truncation of hashes/PRFs/HMACs is a trade-off. > > A trade-off between collision-resistance and how much clue > is provided about the input. TLSv1.0 (rfc2246) references RFC-2104 (HMAC) TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC) TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC) http://tools.ietf.org/html/rfc2104#section-5 5. Truncated output Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 ! above but the end result is truncated to t bits). We recommend that ! the output length t be not less than half the length of the hash ! output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). That rfc-5246 did not increase the finished messages to at least 16 octets (128) when using a SHA-256 based PRF, without providing any rationale, seems like a defect to me, since it is clearly against the rationale in the normative reference. The difference is not so much about TLSv1.2 itself, where truncation to 96 bits is used with SHA-256 instead of the recommended minimum length of 128, but the bad precedent for successor specs using longer hashes, suggesting a truncation of 96 for a PRF-386 based hash, which is extremely far off the recommended minimum length of 192 bits. I think that a TLS cipher suite definition that uses a PRF based on SHA-384 ought to be required to provide a rationale when truncating the finished messages to 96 bits, instead of the minimum "half the length of the hash" recommended by rfc-2104. -Martin From mrex@sap.com Tue Mar 8 12:18:29 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B173E3A6359; Tue, 8 Mar 2011 12:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNRYTLdrj6rl; Tue, 8 Mar 2011 12:18:29 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A186A3A6768; Tue, 8 Mar 2011 12:18:28 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p28KJgF2017881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 21:19:42 +0100 (MET) From: Martin Rex Message-Id: <201103082019.p28KJfaD012916@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 8 Mar 2011 21:19:41 +0100 (MET) In-Reply-To: <201103082015.p28KFo12012459@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 8, 11 09:15:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 20:18:29 -0000 resend (Sorry, for the typos.) Martin Rex wrote: > > The truncation of hashes/PRFs/HMACs is a trade-off. > > A trade-off between collision-resistance and how much clue > is provided about the input. TLSv1.0 (rfc2246) references RFC-2104 (HMAC) TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC) TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC) http://tools.ietf.org/html/rfc2104#section-5 5. Truncated output Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 ! above but the end result is truncated to t bits). We recommend that ! the output length t be not less than half the length of the hash ! output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). That rfc-5246 did not increase the finished messages to at least 16 octets (128) when using a SHA-256 based PRF, without providing any rationale, seems like a defect to me. It is clearly against the recommendation in the normative reference. The difference is not so much about TLSv1.2 itself, where truncation to 96 bits is used with SHA-256 instead of the recommended minimum length of 128, but the bad precedent for successor specs using longer hashes, suggesting a truncation to 96 bits for a SHA-384 based PRF, which is extremely far off the recommended minimum HMAC truncation length of 192 bits for SHA-384. I think that a TLS cipher suite definition that uses a PRF based on SHA-384 ought to be required to provide a rationale when truncating the finished messages to 96 bits, instead of the minimum "half the length of the hash" recommended by rfc-2104. -Martin From hovav@eng.ucsd.edu Tue Mar 8 12:19:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B46D3A6768 for ; Tue, 8 Mar 2011 12:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hGTlKZhsksv for ; Tue, 8 Mar 2011 12:19:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 185A53A6359 for ; Tue, 8 Mar 2011 12:19:07 -0800 (PST) Received: by vxg33 with SMTP id 33so5963527vxg.31 for ; Tue, 08 Mar 2011 12:20:23 -0800 (PST) Received: by 10.52.90.171 with SMTP id bx11mr6201827vdb.36.1299615612071; Tue, 08 Mar 2011 12:20:12 -0800 (PST) MIME-Version: 1.0 Sender: hovav@eng.ucsd.edu Received: by 10.52.166.197 with HTTP; Tue, 8 Mar 2011 12:19:52 -0800 (PST) In-Reply-To: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp> References: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp> From: Hovav Shacham Date: Tue, 8 Mar 2011 12:19:52 -0800 X-Google-Sender-Auth: uwASuAv6qezLlIZbAXzNP9gMWHI Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3071c97ce6f0e1049dfe56fa Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:22:23 -0000 --20cf3071c97ce6f0e1049dfe56fa Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex wrote: Truncating a SHA-384 based PRF to 12 octets is like using > an sha384WithRsaEncryption signature with a 1024 bit RSA key, > it is an imbalanced pairing of algorithms&keys. > It is, Martin, but not in the way you suggest. The generic success probability for a PRF forgery of a k-bit PRF [or a longer PRF truncated to k bits] is 2^{-k}, so a 96-bit PRF like TLS' verify_data provides 96-bit security. By contrast, no one thinks that 1024-bit RSA provides more than 80 bits of security. If you'e worried about balance, you should propose to shorten the verify_data to 10 octets from 12 when 1024-bit RSA is used. PRFs, unlike collision-resistant hashes, are not subject to birthday attacks. This holds true even when they are constructed using using components originating in hash functions, as HMAC is. -hs. --20cf3071c97ce6f0e1049dfe56fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex <mrex@sap.com> wrote:

Truncating a SHA-384 based PRF to 12 octe= ts is like using
an sha384WithRsaEncryption signature with a 1024 bit RSA key,
it is an imbalanced pairing of algorithms&keys.
It is, Martin, but not in the way you suggest.

<= /div>
The generic success probability for a PRF forgery of a k-bit PRF = [or a longer PRF truncated to k bits] is 2^{-k}, so a 96-bit PRF like TLS&#= 39; verify_data provides 96-bit security. =A0By contrast, no one thinks tha= t 1024-bit RSA provides more than 80 bits of security. =A0If you'e worr= ied about balance, you should propose to shorten the verify_data to 10 octe= ts from 12 when 1024-bit RSA is used.

PRFs, unlike collision-resistant hashes, are not subjec= t to birthday attacks. =A0This holds true even when they are constructed us= ing using components originating in hash functions, as HMAC is.

-hs.
--20cf3071c97ce6f0e1049dfe56fa-- From mrex@sap.com Tue Mar 8 12:50:08 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46913A696E for ; Tue, 8 Mar 2011 12:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYbGNqROI9zY for ; Tue, 8 Mar 2011 12:50:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id DF8BC3A695B for ; Tue, 8 Mar 2011 12:50:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p28KpJog016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 21:51:19 +0100 (MET) From: Martin Rex Message-Id: <201103082051.p28KpIXS014777@fs4113.wdf.sap.corp> To: hovav@cs.ucsd.edu (Hovav Shacham) Date: Tue, 8 Mar 2011 21:51:18 +0100 (MET) In-Reply-To: from "Hovav Shacham" at Mar 8, 11 12:19:52 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] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 20:50:09 -0000 Hovav Shacham wrote: > > PRFs, unlike collision-resistant hashes, are not subject to birthday > attacks. This holds true even when they are constructed using using > components originating in hash functions, as HMAC is. I'm sorry, I fail to understand your argument. 5. HMAC and the Pseudorandom Function http://tools.ietf.org/html/rfc5246#section-5 7.4.9. Finished http://tools.ietf.org/html/rfc5246#section-7.4.9 The PRF when used for the generation of the finished messages looks sufficiently similar to HMAC (a keyed hash) and is used like HMAC for integrity protection and authentication. So to me, it looks that the recommendation of rfc-2104 section 5 about truncation should apply here as well. -Martin From marsh@extendedsubset.com Tue Mar 8 12:54:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492443A63D3 for ; Tue, 8 Mar 2011 12:54:57 -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_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJNKI8H16L98 for ; Tue, 8 Mar 2011 12:54:56 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 7CB253A635F for ; Tue, 8 Mar 2011 12:54:56 -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 1Px3du-000IkD-1n; Tue, 08 Mar 2011 20:36:30 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DE63E62E4; Tue, 8 Mar 2011 20:56:04 +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: U2FsdGVkX18uvY2p/kG+3aQmq9BdbLdiQ/QsV2wM4ms= Message-ID: <4D7697E2.2060506@extendedsubset.com> Date: Tue, 08 Mar 2011 14:56:02 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Blumenthal, Uri - 0668 - MITLL" References: <20110308193520.9B3423A6814@core3.amsl.com> In-Reply-To: <20110308193520.9B3423A6814@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:54:57 -0000 On 03/08/2011 01:36 PM, Blumenthal, Uri - 0668 - MITLL wrote: > In general - since pseudorandom-ness of the output was NOT a design > principle or criteria of hash functions (until SHA3) - truncating > hash output is problematic from crypto point because you cannot > reasonably assume that all the output bits have the "entropy" spread > over them equally. But if you can find a systematic way to generate patterns in the output, then you have a publication-worthy attack on the function. E.g. if you have a way to cause any specific bit position of the output of SHA-256 to be a '0' 75% of the time, then you have reduced it to a 255.2-bit function. (Hilarity ensued when this turned out to be case with RC4). The TLS doesn't use a raw hash function though. It doesn't even use a raw HMAC. It uses recursive application of an HMAC to generate an arbitrary amount of output, essentially making a stream cipher. This is probably the most conservative aspect of TLS's design, making me a big fan. For TLS 1.2 it's: verify_data PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; PRF(secret, label, seed) = P_(secret, label + seed) P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + ... A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) Each HMAC represents two hash function invocations, each SHA-256 represents 64 rounds. So before they are used to generate the first block of output, the handshake_messages are hashed something like 5 times mixing in additional pseudorandom key material all but the first time. Don't get me wrong, I think 96 bits is too short and is probably a holdover from the days when we (wisely) didn't trust our ability to design hash functions. But insufficient diffusion does not look like a problem. - Marsh From prvs=2048c768d4=uri@ll.mit.edu Tue Mar 8 13:14:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028723A63C9 for ; Tue, 8 Mar 2011 13:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRT-g9+b-j+7 for ; Tue, 8 Mar 2011 13:14:27 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id EE5803A6359 for ; Tue, 8 Mar 2011 13:14:26 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p28LFe8n021498; Tue, 8 Mar 2011 16:15:40 -0500 From: "Blumenthal, Uri - 0668 - MITLL" To: "'marsh@extendedsubset.com'" Date: Tue, 8 Mar 2011 16:15:40 -0500 Thread-Topic: [TLS] Last Call: (Additionx Thread-Index: Acvd00Iz7EVKSIimSDe4r05ByktRaAAAqksu In-Reply-To: <4D7697E2.2060506@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_08:2011-03-08, 2011-03-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103080141 Message-Id: <20110308211426.EE5803A6359@core3.amsl.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:14:28 -0000 The thing is - we don't know. If such an attack is found - the algorithm is= certifiably broken for these applications (but not as a hash!). As it is -= it's just a set of conjectures and assertions on BOTH sides: "we think/hop= e SHA is..." Vs "it was not a design consideration so maybe SHA isn't...". -- Regards, Uri ----- Original Message ----- From: Marsh Ray [mailto:marsh@extendedsubset.com] Sent: Tuesday, March 08, 2011 03:56 PM=0A= To: Blumenthal, Uri - 0668 - MITLL Cc: 'tls@ietf.org' Subject: Re: [TLS] Last Call: (Additionx On 03/08/2011 01:36 PM, Blumenthal, Uri - 0668 - MITLL wrote: > In general - since pseudorandom-ness of the output was NOT a design > principle or criteria of hash functions (until SHA3) - truncating > hash output is problematic from crypto point because you cannot > reasonably assume that all the output bits have the "entropy" spread > over them equally. But if you can find a systematic way to generate patterns in the output,=20 then you have a publication-worthy attack on the function. E.g. if you=20 have a way to cause any specific bit position of the output of SHA-256=20 to be a '0' 75% of the time, then you have reduced it to a 255.2-bit=20 function. (Hilarity ensued when this turned out to be case with RC4). The TLS doesn't use a raw hash function though. It doesn't even use a=20 raw HMAC. It uses recursive application of an HMAC to generate an=20 arbitrary amount of output, essentially making a stream cipher. This is=20 probably the most conservative aspect of TLS's design, making me a big fan. For TLS 1.2 it's: verify_data PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; PRF(secret, label, seed) =3D P_(secret, label + seed) P_hash(secret, seed) =3D HMAC_hash(secret, A(1) + seed) + ... A(0) =3D seed A(i) =3D HMAC_hash(secret, A(i-1)) Each HMAC represents two hash function invocations, each SHA-256=20 represents 64 rounds. So before they are used to generate the first block of output, the=20 handshake_messages are hashed something like 5 times mixing in=20 additional pseudorandom key material all but the first time. Don't get me wrong, I think 96 bits is too short and is probably a=20 holdover from the days when we (wisely) didn't trust our ability to=20 design hash functions. But insufficient diffusion does not look like a=20 problem. - Marsh From marsh@extendedsubset.com Tue Mar 8 13:14:55 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184E23A6407 for ; Tue, 8 Mar 2011 13:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rayKC7pHETtO for ; Tue, 8 Mar 2011 13:14:54 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 027713A6359 for ; Tue, 8 Mar 2011 13:14:50 -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 1Px3x9-0004km-Hz for tls@ietf.org; Tue, 08 Mar 2011 20:56:23 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2AA4360CF; Tue, 8 Mar 2011 21:15:44 +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: U2FsdGVkX18k6357xsgI5Y7dG13x/DCTpcnsGgLYB74= Message-ID: <4D769C7D.1000204@extendedsubset.com> Date: Tue, 08 Mar 2011 15:15:41 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Hovav Shacham References: <201103081830.p28IUdtN006451@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:14:55 -0000 On 03/08/2011 02:19 PM, Hovav Shacham wrote: > > PRFs, unlike collision-resistant hashes, are not subject to birthday > attacks. This holds true even when they are constructed using using > components originating in hash functions, as HMAC is. Ah but how easily theory is defeated by practice. The inputs to the PRF _are_ subject to birthday attacks. Note that in each case the handshake messages are is bottlenecked through a plain hash function rather than an HMAC. verify_data (TLS 1.0) PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; verify_data (TLS 1.2) PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; So that gives master_secret - 384 bits ought to be enough for anybody. TLS 1.0 MD5(handshake_messages) + SHA-1(handshake_messages) Little better than the stronger of MD5 or SHA-1. TLS 1.2 Hash(handshake_messages) SHA-256 Approx 2^128 collisions. I don't see any real problem there, but the TLS 1.0 case is worth keeping an eye on. - Marsh From ekr@rtfm.com Tue Mar 8 13:44:21 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2533A6452; Tue, 8 Mar 2011 13:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A42qdDX5bG5; Tue, 8 Mar 2011 13:44:20 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id A57393A6405; Tue, 8 Mar 2011 13:44:20 -0800 (PST) Received: by iyj8 with SMTP id 8so6547565iyj.31 for ; Tue, 08 Mar 2011 13:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.189.202 with SMTP id df10mr6340025icb.366.1299620735932; Tue, 08 Mar 2011 13:45:35 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 13:45:35 -0800 (PST) In-Reply-To: <201103082019.p28KJfaD012916@fs4113.wdf.sap.corp> References: <201103082015.p28KFo12012459@fs4113.wdf.sap.corp> <201103082019.p28KJfaD012916@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 13:45:35 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:44:21 -0000 On Tue, Mar 8, 2011 at 12:19 PM, Martin Rex wrote: > resend (Sorry, for the typos.) > > > Martin Rex wrote: >> >> The truncation of hashes/PRFs/HMACs is a trade-off. >> >> A trade-off between collision-resistance and how much clue >> is provided about the input. > > =A0TLSv1.0 (rfc2246) references RFC-2104 (HMAC) > =A0TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC) > =A0TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC) > > http://tools.ietf.org/html/rfc2104#section-5 > > =A05. Truncated output > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Applications > =A0 of HMAC can choose to truncate the output of HMAC by outputting the t > =A0 leftmost bits of the HMAC computation for some parameter t (namely, > =A0 the computation is carried in the normal way as defined in section 2 > ! =A0above but the end result is truncated to t bits). We recommend that > ! =A0the output length t be not less than half the length of the hash > ! =A0output (to match the birthday attack bound) and not less than 80 bit= s > =A0 (a suitable lower bound on the number of bits that need to be > =A0 predicted by an attacker). Ok, but this is just a handwavy rationale. As far as I'm aware, the actual cryptographic analysis is as Hovav has stated. -Ekr From hovav@eng.ucsd.edu Tue Mar 8 14:34:39 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091043A659B for ; Tue, 8 Mar 2011 14:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9n6KFwRssVE for ; Tue, 8 Mar 2011 14:34:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 125663A67A3 for ; Tue, 8 Mar 2011 14:34:37 -0800 (PST) Received: by vxg33 with SMTP id 33so6094635vxg.31 for ; Tue, 08 Mar 2011 14:35:53 -0800 (PST) Received: by 10.52.0.107 with SMTP id 11mr655840vdd.236.1299623753138; Tue, 08 Mar 2011 14:35:53 -0800 (PST) MIME-Version: 1.0 Sender: hovav@eng.ucsd.edu Received: by 10.52.166.197 with HTTP; Tue, 8 Mar 2011 14:35:33 -0800 (PST) In-Reply-To: <201103082051.p28KpIXS014777@fs4113.wdf.sap.corp> References: <201103082051.p28KpIXS014777@fs4113.wdf.sap.corp> From: Hovav Shacham Date: Tue, 8 Mar 2011 14:35:33 -0800 X-Google-Sender-Auth: ydAY65P7DwOjVulwbl6NoJVz8eQ Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3054aad925c3a0049e003c07 Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:34:39 -0000 --20cf3054aad925c3a0049e003c07 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 8, 2011 at 12:51 PM, Martin Rex wrote: > PRFs, unlike collision-resistant hashes, are not subject to birthday > > attacks. This holds true even when they are constructed using using > > components originating in hash functions, as HMAC is. > > I'm sorry, I fail to understand your argument. [...] > it looks that the recommendation of rfc-2104 section 5 about truncation should apply here as well. > What RFC 2104 is saying is that the security of a k-bit truncation of HMAC when using an underlying n-bit hash is min{k,n/2}. Setting k to a value less than n/2 means that you k-bit security; setting k to a value equal to or larger than n/2 means you have (n/2)-bit security. Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2 = 192 bits means you are in the former regime rather than the latter. That's fine, provided k-bit security is sufficient, as 96-bit security is here; it just means that having built HMAC using SHA384 was overkill, which it of course was. -hs. --20cf3054aad925c3a0049e003c07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 8, 2011 at 12:51 PM, Martin Rex <mrex@sap.com> wrot= e:

> PRFs, unlike collision-resistant hashes, are not subject to birth= day
> attacks. =A0This holds true even when they are constructed using using=
> components originating in hash functions, as HMAC is.

I'm sorry, I fail to understand your argument. =A0
[...]=A0
it looks=A0that the recomme= ndation of rfc-2104 section 5 about truncation
should apply here as well.

What RFC 210= 4 is saying is that the security of a k-bit truncation of HMAC when using a= n underlying n-bit hash is min{k,n/2}. =A0Setting k to a value less than n/= 2 means that you k-bit security; setting k to a value equal to or larger th= an n/2 means you have (n/2)-bit security.

Any truncation of HMAC-SHA384 -- the PRF at hand -- to = fewer than 384/2 =3D=A0192 bits means you are in the former regime rather t= han the latter. =A0That's fine, provided k-bit security is sufficient, = as 96-bit security is here; it just means that having built HMAC using SHA3= 84 was overkill, which it of course was.

-hs.
--20cf3054aad925c3a0049e003c07-- From pgut001@login01.cs.auckland.ac.nz Tue Mar 8 15:44:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F793A67AB; Tue, 8 Mar 2011 15:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT4rzJS+DNmS; Tue, 8 Mar 2011 15:44:50 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 684BE3A67B1; Tue, 8 Mar 2011 15:44:50 -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=1299627966; x=1331163966; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20Last=20Call: =20=20(Additionx|Cc:=20i etf@ietf.org,=20tls@ietf.org|In-Reply-To:=20<201103081559 .p28Fxl3p027770@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Wed,=200 9=20Mar=202011=2012:45:55=20+1300; bh=3NhMxcNI8VCzDkkf6K3/vtcp6snrvEguHtelK4H0x1U=; b=fi3TtiopuyGjWBx3KTa26vIRmRyhG2qaLIMZsTwnf1c3nmD1AMvRpPj0 vJdanH+x/SFDVMfVxKRwYS8BAt3W+tuUlCYQZtGx8hIy2X+O9C2sl211m n2kQ/hVNPZT4KL9IXMDAciLxSrb2MxeKBkyq5FzmaV7CJhpOwnkGtMy8w k=; X-IronPort-AV: E=Sophos;i="4.62,286,1296990000"; d="scan'208";a="49992741" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Mar 2011 12:45:55 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Px6bD-0006WH-Hv; Wed, 09 Mar 2011 12:45:55 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Px6bD-0001Gg-GM; Wed, 09 Mar 2011 12:45:55 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201103081559.p28Fxl3p027770@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 09 Mar 2011 12:45:55 +1300 Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:44:51 -0000 Martin Rex writes: >Truncating the PRF output to 12 octets for TLSv1.2 seems like an error. It's not an error, it's IPsec cargo cult design. OK, using cargo cult design for a security protocol probably rates as an error, but the choice of exactly 96 bits was deliberate rather than the full size was deliberate. Peter. From pgut001@login01.cs.auckland.ac.nz Tue Mar 8 15:53:52 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58EF23A67AB; Tue, 8 Mar 2011 15:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6evHV89hlDoB; Tue, 8 Mar 2011 15:53:51 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1A18B3A67C2; Tue, 8 Mar 2011 15:53:50 -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=1299628507; x=1331164507; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20Last=20Call: =20=20(Additionx|Cc:=20i etf@ietf.org,=20tls@ietf.org|In-Reply-To:=20<201103081923 .p28JNl08009539@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Wed,=200 9=20Mar=202011=2012:55:06=20+1300; bh=SE28R5EsrUF9pYmv6zUdoCcPIe884gQcNVkZzO1DNdw=; b=gHzE8CU3WjkhgPT+BOOUztzxEzXICautxHhAiKXkyvN5Bq0nm6oftxQ/ PsVFLWDIu2oY8zbell92q9xmgJ/6QNehodAMjWrqmpkp4rB8ZxS6rJoKP AVaQ2WTGTJf/MwGyuBXXHKH+FLUlypAsjwiN4cEOqtMGnLdEkZCuXYwTc I=; X-IronPort-AV: E=Sophos;i="4.62,286,1296990000"; d="scan'208";a="49995605" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Mar 2011 12:55:06 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Px6k6-0006uO-GJ; Wed, 09 Mar 2011 12:55:06 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Px6k6-0001We-0G; Wed, 09 Mar 2011 12:55:06 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 09 Mar 2011 12:55:06 +1300 Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:53:52 -0000 Martin Rex writes: >Truncating HMACs and PRFs may have become first popular in the IETF within >IPSEC. It wasn't any "may have become first popular", there was only room for 96 bits of MAC data in the IP packet, so MD5 was truncated to that size. Since then an army of cargo-cult designers have copied it without knowing why, but if IPsec did it it had to be good, right? Peter. From prvs=204905fbab=uri@ll.mit.edu Tue Mar 8 16:15:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980A23A67D2 for ; Tue, 8 Mar 2011 16:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqzFE2+dsKRE for ; Tue, 8 Mar 2011 16:15:31 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id B4C7A3A67AB for ; Tue, 8 Mar 2011 16:15:31 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p290GkD5005680 for ; Tue, 8 Mar 2011 19:16:46 -0500 From: "Blumenthal, Uri - 0668 - MITLL" To: "'tls@ietf.org'" Date: Tue, 8 Mar 2011 19:16:45 -0500 Thread-Topic: [TLS] Last Call: (Additionx Thread-Index: Acvd7EKlkVOQt1RUTIGB9DZuWto9NAAAvRwy In-Reply-To: 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_09:2011-03-08, 2011-03-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=6 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103080177 Message-Id: <20110309001531.B4C7A3A67AB@core3.amsl.com> Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:15:32 -0000 Funny to observe how habits, rituals and superstitions are formed, isn't it= ? :) -- Regards, Uri ----- Original Message ----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] Sent: Tuesday, March 08, 2011 06:55 PM=0A= To: mrex@sap.com Cc: ietf@ietf.org ; tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx Martin Rex writes: >Truncating HMACs and PRFs may have become first popular in the IETF within= =20 >IPSEC. It wasn't any "may have become first popular", there was only room for 96 b= its=20 of MAC data in the IP packet, so MD5 was truncated to that size. Since the= n an army of cargo-cult designers have copied it without knowing why, but if IPs= ec did it it had to be good, right? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From ekr@rtfm.com Tue Mar 8 17:07:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3383A67ED; Tue, 8 Mar 2011 17:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V214z7o5d6aI; Tue, 8 Mar 2011 17:07:24 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 615263A67E6; Tue, 8 Mar 2011 17:07:24 -0800 (PST) Received: by iwl42 with SMTP id 42so52392iwl.31 for ; Tue, 08 Mar 2011 17:08:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr7595778icb.31.1299632918148; Tue, 08 Mar 2011 17:08:38 -0800 (PST) Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 17:08:38 -0800 (PST) In-Reply-To: References: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> Date: Tue, 8 Mar 2011 17:08:38 -0800 Message-ID: From: Eric Rescorla To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 01:07:25 -0000 On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann wrote: > > Martin Rex writes: > >>Truncating HMACs and PRFs may have become first popular in the IETF within >>IPSEC. > > It wasn't any "may have become first popular", there was only room for 96 bits > of MAC data in the IP packet, so MD5 was truncated to that size. This is an odd claim, since: (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally specified not HMAC but a keyed MD5 variant with a 128-bit output. (b) The document that Martin points to has MACs > 96 bits long. Can you please point to where in IP there is a limit that requires a MAC no greater than 96 bits. -Ekr From n.mavrogiannopoulos@gmail.com Wed Mar 9 01:09:03 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73FF3A67E2; Wed, 9 Mar 2011 01:09:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNySRtlgRbmD; Wed, 9 Mar 2011 01:09:01 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 996243A68AA; Wed, 9 Mar 2011 01:09:01 -0800 (PST) Received: by qwh6 with SMTP id 6so264730qwh.31 for ; Wed, 09 Mar 2011 01:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=u1YJUSG2BuVPmlpq/vov+F4/pDlk7+GRASuZ+1Esc9k=; b=VCNPUpEIWYPc72YpUX/T5upxHQfpEBx+CKr1SWQPMAEN/+CaYfya63LYV5nI6t9ur9 1VGDxTqsVT3RNXxQ1Arowybk3M6kjPaYgnlwFVHSgNXEeLovQz1wDrKeNc6DMXdciMK7 cZMBu53o6dAKEPXDM24dZN+QDaJ+cm5mMV0Yg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=PoUSS1/+GKCPxTnzeCpktH1qlO2j9NkQo8kDCQXLwbnIeSFAm1wwcHPmh8s8L/55ao 52H1B527h/E6TlVZpBMWjs5RaNajfV2Y9J2rft1g7yBsoViplI/WJUPUiaqYmUdAikQ7 Wy1Rm1uFGQ5Hz7YRlUMUvlYCk8O/RdEIAgHtY= MIME-Version: 1.0 Received: by 10.229.79.196 with SMTP id q4mr4933161qck.132.1299661817309; Wed, 09 Mar 2011 01:10:17 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 01:10:17 -0800 (PST) In-Reply-To: References: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 10:10:17 +0100 X-Google-Sender-Auth: ubB3Ve5dc5xJjvtQg1gPbYsz8rE Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:09:03 -0000 On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla wrote: >>> Perhaps, but this isn't a digest but rather a MAC, and so the attack >>> model is different. >> You seem to be forgetting that the finished messages have been reused >> for other purposes already: > No, I'm not forgetting that. That doesn't change the fact that the > computation is > a MAC. I'm not a specialist in MAC algorithms but by checking the ECRYPT II[0] report of 2009-2010, I can try making some points. A MAC has a security level that depends on the size of the MAC and the size of the key. That is a 12-byte MAC has security level of MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used. As I understand the addition of SHA-384 as PRF was to increase the security margin of TLS comparing to the SHA-1 PRF. This is not occuring now because a MAC based on algorithm that returns 384-bits and truncates it to 96 can offer nothing more than an algorithm that outputs 160 bits and are trucated to 96. Hence there is no significant difference than SHA-1 or SHA-384 in that case, so why define SHA-384 anyway? For me the ciphersuites defined in TLS should have a uniform security level. I.E. why use AES-256 with security level of 2^256 but use a MAC for a handshake of 2^96 bits? regards, Nikos [0]. http://www.ecrypt.eu.org/documents/D.SPA.13.pdf [1]. For an HMAC the square root of the internal state of the hash algorithm is also affecting the security level. From pgut001@login01.cs.auckland.ac.nz Wed Mar 9 01:56:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6968A3A67C3; Wed, 9 Mar 2011 01:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU5KtXIgXc7W; Wed, 9 Mar 2011 01:56:24 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 006EF3A67A1; Wed, 9 Mar 2011 01:56:22 -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=1299664661; x=1331200661; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ekr@rtfm.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[TLS]=20Last=20Call:=20=20(Additionx|Cc:=20ietf@ietf.org,=20mrex@sap.com ,=20tls@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=20 09=20Mar=202011=2022:57:37=20+1300; bh=TPF28jOsixDbIHDW2XdXrBMhlmzKNzKq5U5b/OZfxU4=; b=YZ57oYgyB/0smfhEfLVZCguzrduXEDeV1tL5ffZZOocwnv5hZrofNAHI Fpax0XYsx3jqw7RtANRhWQhTBtIC+hWIm3K6ijPiSc8OMsMD/EGSAhNCP TK1GgEvDd0SSDfZ0E5gc7QyPVtlqwGbGYjVEjJ5zo1gtAMx5AdWcigxkG E=; X-IronPort-AV: E=Sophos;i="4.62,289,1296990000"; d="scan'208";a="50107916" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Mar 2011 22:57:37 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PxG9B-0002tm-Ho; Wed, 09 Mar 2011 22:57:37 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PxG9B-0007K0-FK; Wed, 09 Mar 2011 22:57:37 +1300 From: Peter Gutmann To: ekr@rtfm.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 09 Mar 2011 22:57:37 +1300 Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:56:25 -0000 Eric Rescorla writes: >Can you please point to where in IP there is a limit that requires a MAC no >greater than 96 bits. The AH had room for exactly 96 bits of MAC value, any more and it'd have to overflow to another 32 bits worth (the size of the non-MAC data is 96 bits and the MAC data adds the other 96 bits), see RFC 2402. The original AH used a 64-bit data field (RFC 1826) and didn't truncate MD5 (RFC 1828), so it was also 192 bits long. With the expansion of the non-MAC data to 96 bits, it was necessary to truncate the MAC to keep the same overall size. Peter. From mrex@sap.com Wed Mar 9 04:04:52 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A903A6983 for ; Wed, 9 Mar 2011 04:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.925 X-Spam-Level: X-Spam-Status: No, score=-9.925 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjL7Iia9Hvyi for ; Wed, 9 Mar 2011 04:04:51 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 55C923A6971 for ; Wed, 9 Mar 2011 04:04:50 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p29C611E016858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 13:06:01 +0100 (MET) From: Martin Rex Message-Id: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> To: hovav@cs.ucsd.edu (Hovav Shacham) Date: Wed, 9 Mar 2011 13:06:01 +0100 (MET) In-Reply-To: from "Hovav Shacham" at Mar 8, 11 02:35:33 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] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 12:04:52 -0000 Hovav Shacham wrote: > > Martin Rex wrote: > > > > it looks that the recommendation of rfc-2104 section 5 about truncation > > should apply here as well. > > What RFC 2104 is saying is that the security of a k-bit truncation of HMAC > when using an underlying n-bit hash is min{k,n/2}. Setting k to a value > less than n/2 means that you k-bit security; setting k to a value equal to > or larger than n/2 means you have (n/2)-bit security. > > Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2 > = 192 bits means you are in the former regime rather than the latter. > That's fine, provided k-bit security is sufficient, as 96-bit security is > here; it just means that having built HMAC using SHA384 was overkill, which > it of course was. What I'm reading here is that a truncation of an HMAC or an HMAC-like construct to 96 bits cuts the effective security down to 96-bit. You call the use of SHA-384 for the HMAC in such a situation "overkill", I call it cryptographic imbalance. A sensibly balanced truncation would truncate to _no_ less than half the output size of the underlying hash function, which means at least 192 bits in accordance with with the recommendation in rfc-2104 (HMAC) section 5. Is that correct? -Martin From ynir@checkpoint.com Wed Mar 9 05:26:20 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AAD3A69A2 for ; Wed, 9 Mar 2011 05:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2YC2+inkM-2 for ; Wed, 9 Mar 2011 05:26:19 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 2399E3A6992 for ; Wed, 9 Mar 2011 05:26:18 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p29DRUKM000337; Wed, 9 Mar 2011 15:27:30 +0200 X-CheckPoint: {4D778029-A-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 9 Mar 2011 15:27:30 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Wed, 9 Mar 2011 15:27:31 +0200 Thread-Topic: [TLS] Last Call: (Additionx Thread-Index: AcveXbzev27zO6PwRS6tYLjw8fhp+g== Message-ID: <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com> References: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> In-Reply-To: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:26:20 -0000 On Mar 9, 2011, at 2:06 PM, Martin Rex wrote: >=20 > What I'm reading here is that a truncation of an HMAC or an HMAC-like > construct to 96 bits cuts the effective security down to 96-bit. >=20 > You call the use of SHA-384 for the HMAC in such a situation "overkill", > I call it cryptographic imbalance. I've heard the balance argument before, and I don't really find it compelli= ng. It implies that if I'm using 1024-bit RSA, then it is inherently wrong = to use AES-128 or SHA-384. There are other considerations in design besides= bit-strength. Bit strength should be used as a minimum value, depending on= the estimated resources of your opponent. For example, there's been a known collision attack on SHA-1 with 64-bit com= plexity for over a year (or was it 69?). In that time, no researchers have = yet produced a pair of blocks with the same SHA-1 hash. This tells me that = 64-bits is still an effective strength against graduate students. It's prob= ably also enough against the neighbor's kid, but not strong enough if my op= ponent is the NSA, or even a well-funded crime organization with access to = a 100,000-strong botnet. Not sure about industrial espionage. If I don't think the NSA and the Russian mob are out to get me, I may decid= e that 64 bits of security are good enough, and even if I want to exclude a= ll but the NSA, I may decide that 80 bits are good enough. Fine, so 80-bits means I can use 3DES or AES for encryption, 1024 or 1536 b= its for RSA, SHA-256 or SHA-224 for hashes, and HMAC-SHA-1 is still good en= ough. As it turns out, on most modern hardware AES is faster than 3DES. ECDSA wit= h a 256-bit curve is stronger than 1024-bit RSA, but is also faster. Gate c= ount constraints may limit me to one algorithm, so I might prefer HMAC-SHA-= 256 even though it is too strong. The point is, that many factors may influence my choice of algorithms, and = there's nothing wrong with having an imbalanced suite. Just as long as all = the algorithms meet (or exceed) my target strength. Yoav= From n.mavrogiannopoulos@gmail.com Wed Mar 9 06:00:18 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE343A69BF for ; Wed, 9 Mar 2011 06:00:18 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC7CzoPL-l4p for ; Wed, 9 Mar 2011 06:00:18 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id D610F3A6821 for ; Wed, 9 Mar 2011 06:00:17 -0800 (PST) Received: by qyk7 with SMTP id 7so436437qyk.10 for ; Wed, 09 Mar 2011 06:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4myV0puXkDMFbfN5rIH3+khEmknOMp9y6IbE6n6kzjA=; b=KNcwB7/5EHAeFDYDQoeAWN+r7rHl2UJ0L3zmub2vUi5AaPElAqVZxQCcmeqE///KES 1pMrfWLR4v4EjE1XWLGwerdXSYsPHOwHmK/BjFSpa4SwTDg+UrcVrFeeGDJCH8RIUnR7 dpllk9Hck3u5cK3Qice9Alp8fanvM/tBkI2II= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=oAX07ITcdDhgh0HLyKVw2iKn05GdzSWO7DxjGQrv7Wf/evxvZ9u6Q+BLjtJgD8rQF8 N3cOb7KflE+DTLKZ5hpDPmZRA4OJGEP7Z52PrRItVwhu+5STR40kDUXZmP02JwULq8L7 xfPK7xIOaEg1+g17DKqmT6a2Ezm+VX/ElmdGg= MIME-Version: 1.0 Received: by 10.229.79.196 with SMTP id q4mr5201805qck.132.1299679292628; Wed, 09 Mar 2011 06:01:32 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 06:01:32 -0800 (PST) In-Reply-To: <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com> References: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com> Date: Wed, 9 Mar 2011 15:01:32 +0100 X-Google-Sender-Auth: 8bnFynZqayzSUfrXaNsE8fE4IMg Message-ID: From: Nikos Mavrogiannopoulos To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:00:18 -0000 On Wed, Mar 9, 2011 at 2:27 PM, Yoav Nir wrote: >> What I'm reading here is that a truncation of an HMAC or an HMAC-like >> construct to 96 bits cuts the effective security down to 96-bit. > I've heard the balance argument before, and I don't really find it compel= ling. It implies that if I'm using 1024-bit RSA, then it is inherently wron= g to use AES-128 or SHA-384. There are other considerations in design besid= es bit-strength. Bit strength should be used as a minimum value, depending = on the estimated resources of your opponent. [...] > The point is, that many factors may influence my choice of algorithms, an= d there's nothing wrong with having an imbalanced suite. Just as long as al= l the algorithms meet (or exceed) my target strength. This would be fine if the target strength was formally set in TLS cipher-suites. There is no such thing in them and this is the reason we see RC4 with a 96-bit MA= C on handshake, AES-128 with a 96-bit MAC, AES-256 with the same MAC etc. What was the target strength in those ciphersuites? regards, Nikos From mrex@sap.com Wed Mar 9 06:05:09 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC66C3A69DC for ; Wed, 9 Mar 2011 06:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bpsZ5c3-PlQ for ; Wed, 9 Mar 2011 06:05:07 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4E3A63A69E4 for ; Wed, 9 Mar 2011 06:05:07 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p29E6BEa017326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 15:06:11 +0100 (MET) From: Martin Rex Message-Id: <201103091406.p29E6ABc011887@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Wed, 9 Mar 2011 15:06:10 +0100 (MET) In-Reply-To: <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com> from "Yoav Nir" at Mar 9, 11 03:27: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] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 14:05:09 -0000 Yoav Nir wrote: > > On Mar 9, 2011, at 2:06 PM, Martin Rex wrote: > > > > > What I'm reading here is that a truncation of an HMAC or an HMAC-like > > construct to 96 bits cuts the effective security down to 96-bit. > > > > You call the use of SHA-384 for the HMAC in such a situation "overkill", > > I call it cryptographic imbalance. > > I've heard the balance argument before, and I don't really find it > compelling. It implies that if I'm using 1024-bit RSA, then it is > inherently wrong to use AES-128 or SHA-384. There are other > considerations in design besides bit-strength. Bit strength should > be used as a minimum value, depending on the estimated resources > of your opponent. There is a big difference whether a limitation is hardwired into a protocol, or whether a limitation is a side-effect of configuration and properties selected by the consumer of the technology. For most TLS implementations that I'm aware of, the cipher suites are user-configurable and the size of the keys in the server certificates and the hash that is used in the signature of the certificates are determined by the consumer. The truncation of the finished message hashes to 96-bits is an undue hard limit in TLSv1.2, and it becomes more aggravating if you're using a hash with an even larger output size than SHA-256 and the truncation of the finished messages is not changed to be no less than half the output size of the hash algorithm. I also prefer AES over 3DES-EDE cipher suites for our TLS implementation, which is why I made them prefered by default (the server has the privilege to chose the common cipher suite, though). TLS implementations of SSLv3, TLSv1.0 and TLSv1.1 that prefer AES256 over AES128 by default are imbalanced, because they're wasting resources. TLSv1.2 was supposed to provide a framework that can deliver TLS with a strength >128=bits of security. But it failed to deliver this by (1) not adjusting the truncation of the finished messages and (2) not documenting that the truncation of the finished messages MUST be done along with the use of stronger ciphers, stronger hashes and larger key lengths in order to actually obtain a balanced security of the desired higher strength. If anyone is wondering: No, I'm definitely _not_ looking for a backwards incompatible change of TLSv1.2. I didn't want to break interop with the installed base of SSLv3 when we did TLS extension RI, and neither do I want to break interop with the installed base of rfc-5246 now. Even when facing real non-compliance, like the botched client_version check on the premaster secret in Windows 7 schannel, I'm more interested in producing recommendations that avoid interop problems, because in the IETF interoperability used to be more important than academic purity in design. -Martin From ekr@rtfm.com Wed Mar 9 06:30:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4353A69FB; Wed, 9 Mar 2011 06:30:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFyoufuZifte; Wed, 9 Mar 2011 06:30:49 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 036AD3A69E4; Wed, 9 Mar 2011 06:30:48 -0800 (PST) Received: by gwb20 with SMTP id 20so26962gwb.31 for ; Wed, 09 Mar 2011 06:32:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.164.199 with SMTP id h7mr8397594icy.165.1299681124999; Wed, 09 Mar 2011 06:32:04 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 06:32:04 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Mar 2011 06:32:04 -0800 Message-ID: From: Eric Rescorla To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:30:50 -0000 Overflowing by another 32 bits is hardly the same as "there was only room f= or" -Ekr On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann w= rote: > Eric Rescorla writes: > >>Can you please point to where in IP there is a limit that requires a MAC = no >>greater than 96 bits. > > The AH had room for exactly 96 bits of MAC value, any more and it'd have = to > overflow to another 32 bits worth (the size of the non-MAC data is 96 bit= s and > the MAC data adds the other 96 bits), see RFC 2402. =A0The original AH us= ed a > 64-bit data field (RFC 1826) and didn't truncate MD5 (RFC 1828), so it wa= s > also 192 bits long. =A0With the expansion of the non-MAC data to 96 bits,= it was > necessary to truncate the MAC to keep the same overall size. > > Peter. > From ekr@rtfm.com Wed Mar 9 06:33:39 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0402E3A69F2; Wed, 9 Mar 2011 06:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lphQHSSej5zV; Wed, 9 Mar 2011 06:33:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0C5043A69EC; Wed, 9 Mar 2011 06:33:37 -0800 (PST) Received: by iwl42 with SMTP id 42so726048iwl.31 for ; Wed, 09 Mar 2011 06:34:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.74.71 with SMTP id v7mr8404229icj.232.1299681294424; Wed, 09 Mar 2011 06:34:54 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 06:34:54 -0800 (PST) In-Reply-To: References: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 06:34:54 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:33:39 -0000 On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos w= rote: > On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla wrote: >>>> Perhaps, but this isn't a digest but rather a MAC, and so the attack >>>> model is different. >>> You seem to be forgetting that the finished messages have been reused >>> for other purposes already: >> No, I'm not forgetting that. That doesn't change the fact that the >> computation is >> a MAC. > > I'm not a specialist in MAC algorithms but by checking > the ECRYPT II[0] report of 2009-2010, I can try making some points. > A MAC has a security level that depends on the size of the MAC > and the size of the key. That is a 12-byte MAC has security level of > MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used. > > As I understand the addition of SHA-384 as PRF was to increase > the security margin of TLS comparing to the SHA-1 PRF. This > is not occuring now because a MAC based on algorithm that > returns 384-bits and truncates it =A0to 96 can offer nothing more > than an algorithm that outputs 160 bits and are trucated to 96. > Hence there is no significant difference than SHA-1 or SHA-384 > in that case, so why define SHA-384 anyway? If you recall, the reason why TLS 1.2 was done was not primarily because of concerns about SHA-1's 160-bit output being large enough but because people started developing analytic attacks on MD5 and SHA-1 that brought it's security level down below the nominal level. In other words, there are many applications where 80 bits of security is fine, but people don't want to use SHA-1 because they don't trust it. > For me the ciphersuites defined in TLS should have a uniform > security level. I.E. why use AES-256 with security level of 2^256 > but use a MAC for a handshake of 2^96 bits? Because the attack model for MACs is not the same as the attack model for encryption. The encryption is susceptible to offline attack, whereas with a MAC all you need to do is get the guessing probability sufficiently low because *any* failed forgery causes connection termination. -Ekr From ekr@rtfm.com Wed Mar 9 06:45:18 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B81E3A69DE for ; Wed, 9 Mar 2011 06:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eeq+pzAO5pQC for ; Wed, 9 Mar 2011 06:45:17 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9C7093A683E for ; Wed, 9 Mar 2011 06:45:17 -0800 (PST) Received: by iwl42 with SMTP id 42so738634iwl.31 for ; Wed, 09 Mar 2011 06:46:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.74.71 with SMTP id v7mr8420407icj.232.1299681993886; Wed, 09 Mar 2011 06:46:33 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 06:46:33 -0800 (PST) In-Reply-To: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> References: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 06:46:33 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:45:18 -0000 On Wed, Mar 9, 2011 at 4:06 AM, Martin Rex wrote: > Hovav Shacham wrote: >> >> Martin Rex wrote: >> > >> > it looks that the recommendation of rfc-2104 section 5 about truncatio= n >> > should apply here as well. >> >> What RFC 2104 is saying is that the security of a k-bit truncation of HM= AC >> when using an underlying n-bit hash is min{k,n/2}. =A0Setting k to a val= ue >> less than n/2 means that you k-bit security; setting k to a value equal = to >> or larger than n/2 means you have (n/2)-bit security. >> >> Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2 >> =3D 192 bits means you are in the former regime rather than the latter. >> =A0That's fine, provided k-bit security is sufficient, as 96-bit securit= y is >> here; it just means that having built HMAC using SHA384 was overkill, wh= ich >> it of course was. > > What I'm reading here is that a truncation of an HMAC or an HMAC-like > construct to 96 bits cuts the effective security down to 96-bit. > > You call the use of SHA-384 for the HMAC in such a situation "overkill", > I call it cryptographic imbalance. > > A sensibly balanced truncation would truncate to _no_ less than half > the output size of the underlying hash function, which means at > least 192 bits in accordance with with the recommendation in > rfc-2104 (HMAC) section 5. > > Is that correct? As Hovav says, what's imbalanced isn't the truncation, it's the use of SHA-= 384. As I said to Nikos, it's useful to remember how we got here, which is not that the TLS WG suddenly developed a desire to modernize the hash functions at the c= ore of TLS. The combination of MD5 and SHA-1 would quite likely have been fine indefiintely except that Wang started breaking both MD5 and SHA-1. This left us in the situation where we needed new, non-broken hash functions. However, the only such functions *also* had a longer output size. Sometimes this is useful, sometimes it's annoying. As a simpler example, let's consider the case of the message MAC, currently untruncated HMAC-SHA-1 with an output size of 160 bits (20 bytes). The security level of this MAC against forgery/tampering is 160 bits under brute force attack. Now con= sider a world where HMAC-SHA-1 is really broken [not the current world] and we ne= ed to transition to HMAC-SHA-256. The "balance" argument you're proposing woul= d have us use accept an extra 12 bytes of MAC output size even though the pre= vious security level was fine. However, as Hovav suggests, the situation is that we just don't have another 160-bit hash function at hand to replace SHA-1, so instead we're forced into using one that's really too big. In other words, overkill. -Ekr From ekr@rtfm.com Wed Mar 9 06:50:35 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49143A6874 for ; Wed, 9 Mar 2011 06:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0LH17ibz-Pp for ; Wed, 9 Mar 2011 06:50:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id DA92B3A69FB for ; Wed, 9 Mar 2011 06:50:33 -0800 (PST) Received: by iyj8 with SMTP id 8so741504iyj.31 for ; Wed, 09 Mar 2011 06:51:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.74.71 with SMTP id v7mr8428206icj.232.1299682310218; Wed, 09 Mar 2011 06:51:50 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 06:51:50 -0800 (PST) In-Reply-To: <201103091406.p29E6ABc011887@fs4113.wdf.sap.corp> References: <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com> <201103091406.p29E6ABc011887@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 06:51:50 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:50:35 -0000 On Wed, Mar 9, 2011 at 6:06 AM, Martin Rex wrote: > Yoav Nir wrote: >> >> On Mar 9, 2011, at 2:06 PM, Martin Rex wrote: >> >> > >> > What I'm reading here is that a truncation of an HMAC or an HMAC-like >> > construct to 96 bits cuts the effective security down to 96-bit. >> > >> > You call the use of SHA-384 for the HMAC in such a situation "overkill= ", >> > I call it cryptographic imbalance. >> >> I've heard the balance argument before, and I don't really find it >> compelling. It implies that if I'm using 1024-bit RSA, then it is >> inherently wrong to use AES-128 or SHA-384. There are other >> considerations in design besides bit-strength. Bit strength should >> be used as a minimum value, depending on the estimated resources >> of your opponent. > > There is a big difference whether a limitation is hardwired into a > protocol, or whether a limitation is a side-effect of configuration > and properties selected by the consumer of the technology. > > For most TLS implementations that I'm aware of, the cipher suites > are user-configurable and the size of the keys in the server > certificates and the hash that is used in the signature of > the certificates are determined by the consumer. > > > The truncation of the finished message hashes to 96-bits is an undue > hard limit in TLSv1.2, and it becomes more aggravating if you're > using a hash with an even larger output size than SHA-256 and the > truncation of the finished messages is not changed to be no less > than half the output size of the hash algorithm. In that case, you'll be glad to know it's not a hard limit: http://tools.ietf.org/html/rfc5246#section-7.4.9 In previous versions of TLS, the verify_data was always 12 octets long. In the current version of TLS, it depends on the cipher suite. Any cipher suite which does not explicitly specify verify_data_length has a verify_data_length equal to 12. This includes all existing cipher suites. Note that this representation has the same encoding as with previous versions. Future cipher suites MAY specify other lengths but such length MUST be at least 12 bytes. > TLSv1.2 was supposed to provide a framework that can deliver TLS > with a strength >128=3Dbits of security. =A0But it failed to deliver > this by (1) not adjusting the truncation of the finished messages > and (2) not documenting that the truncation of the finished messages > MUST be done along with the use of stronger ciphers, stronger hashes > and larger key lengths in order to actually obtain a balanced > security of the desired higher strength. Well, as I've said during this thread, I believe your understanding of what "security level" means in this context is wrong. I.e., a 128-bit security level against offline attack is very different than a 2^{-128} chance of successful guessing exactly once on each connection. However, TLS 1.2 does in fact have the flexibility you are requesting. > Even when facing real non-compliance, like the botched client_version che= ck > on the premaster secret in Windows 7 schannel, I'm more interested > in producing recommendations that avoid interop problems, because > in the IETF interoperability used to be more important than > academic purity in design. Oddly, I think of this balance argument as not much more than academic puri= ty. -Ekr From n.mavrogiannopoulos@gmail.com Wed Mar 9 07:13:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAD13A6992 for ; Wed, 9 Mar 2011 07:13:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz56S60VLuMl for ; Wed, 9 Mar 2011 07:13:52 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 7F6963A683E for ; Wed, 9 Mar 2011 07:13:52 -0800 (PST) Received: by qyk7 with SMTP id 7so503974qyk.10 for ; Wed, 09 Mar 2011 07:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hf9znjD+Y5OcWJafXeFcDOB/vEOf1QOjHu2KuVkXrNE=; b=s+DZkkQaI1jdXV8sRX2/cfSLwNy7bUz8mV3k5EhypYVx85WrJcrPchYhrbfEw7OJbz M627m2Hlcc4hxKkyDQomGdaZVReuUdwxNFtdQxbA/x6pTECy3V1sX3l5sT+LqDHJuErP xt9dAo312ea02Wm6VYu73Deiosdro6J9X/oY0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=LX3xISoL4BSUUtxJEHb3pkxyPrhXZQsSnXS6sZVZd0YbUj6i2LDt9yw134Q6vawhLG Stnnyx8J+lz3mJais1OOZYynMm2uZNZ/SvUSV9O2sPV2Lt2AwVodcbWhpsDNQN2rOSrx 3fLFQoNtRu+P0P8Qm73QoLqmqpjo7D/pof+pc= MIME-Version: 1.0 Received: by 10.229.114.80 with SMTP id d16mr5312357qcq.18.1299683708594; Wed, 09 Mar 2011 07:15:08 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 07:15:08 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Wed, 9 Mar 2011 16:15:08 +0100 X-Google-Sender-Auth: I-OIQe9kNGMbG9Eqig-Q9rwcR6w Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:13:53 -0000 On Tue, Mar 8, 2011 at 3:00 PM, Eric Rescorla wrote: >> If there is no answer to that, then a DTLS handshake would always require >> a fixed amount of time (additional to calculations), e.g. 60 seconds - >> if we take >> the maximum time allowed for retransmission - to complete. That is because >> I see protocol transition from >> "handshake" -> "application data exchange" >> only after handshake has been fully completed. Or is it implicit that >> "draft-bmoeller-tls-falsestart-00" applies to DTLS? (in that case it >> should be explicit). > > I don't think I understand the question. > As soon as either side has *received* the last message it expects to > get from the > other side, it can start sending data. Ok I think I got the point, but I don't think this is obvious. What you are suggesting here is that a handshake such as: Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished **lost** <-------- Application Data Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished **lost** <-------- Application Data <-------- Application Data Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data is valid for DTLS. My impression after reading draft-ietf-tls-rfc4347-bis-04 was that it is similar to TLS, in the sense that the handshake protocol has to finish (for both parties) before application data are to be exchanged (and thus the above handshake would be invalid). Something out of curiocity. Why was the handshake layer retransmission and reassembly was preferred comparing to a retransmission and reassembly layer at the record protocol (for records exchanged during the handshake protocol)? regards, Nikos From mrex@sap.com Wed Mar 9 07:22:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC6C3A6992 for ; Wed, 9 Mar 2011 07:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vCxfp0NtAur for ; Wed, 9 Mar 2011 07:22:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 253683A6821 for ; Wed, 9 Mar 2011 07:22:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p29FNsfP015355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 16:23:59 +0100 (MET) From: Martin Rex Message-Id: <201103091523.p29FNrc4016546@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 9 Mar 2011 16:23:53 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 9, 11 06:51:50 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] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 15:22:53 -0000 Eric Rescorla wrote: > > On Martin Rex wrote: > > > > The truncation of the finished message hashes to 96-bits is an undue > > hard limit in TLSv1.2, and it becomes more aggravating if you're > > using a hash with an even larger output size than SHA-256 and the > > truncation of the finished messages is not changed to be no less > > than half the output size of the hash algorithm. > > In that case, you'll be glad to know it's not a hard limit: Great, we come around full circle. Does anyone remember the subject of the thread -- a TLS cipher spec that defines a PRF with SHA-384. Yes, I'm aware what TLSv1.2 says. But I'm much more aware of the complete lack of guidance (a pointer to rfc-2104 section 5 would have been sufficient). All I've been asking for, is, that (draft-kanno-tls-camellia-00.txt) should (re-)define the truncation of the finished messages in case that SHA-384 is used for the PRF to at least 192 bits (24 octets), following the recommendation in rfc-2104 section 5 in order to obtain a sensibly balanced crypto of the desired strength -- or alternatively provide a convincing rationale why it is _not_ following that recommendation. Alternatively, if they favour your attitude that actually SHA-1 would have been good enough, and SHA-256 is plenty, they should remove all the -SHA384 ciphersuites from the document. > > > TLSv1.2 was supposed to provide a framework that can deliver TLS > > with a strength >128=bits of security.  But it failed to deliver > > this by (1) not adjusting the truncation of the finished messages > > and (2) not documenting that the truncation of the finished messages > > MUST be done along with the use of stronger ciphers, stronger hashes > > and larger key lengths in order to actually obtain a balanced > > security of the desired higher strength. > > Well, as I've said during this thread, I believe your understanding of what > "security level" means in this context is wrong. I.e., a 128-bit security > level against offline attack is very different than a 2^{-128} chance of > successful guessing exactly once on each connection. However, TLS 1.2 > does in fact have the flexibility you are requesting. TLSv1.2 should have used that flexibility itself for a SHA-256 PRF, and should have provided a pointer to rfc-2104 section 5 for selecting an adequate truncation size for TLS cipher suite specs that use this flexibility. What seems to have happened is that although there are cipher suite specs that redefine the PRF, they fail to address the truncation because TLSv1.2 fails to address the truncation ("bad precedent"). > > > Even when facing real non-compliance, like the botched client_version check > > on the premaster secret in Windows 7 schannel, I'm more interested > > in producing recommendations that avoid interop problems, because > > in the IETF interoperability used to be more important than > > academic purity in design. > > Oddly, I think of this balance argument as not much more than academic purity. With respect to the truncation to 96-bits in TLSv1.2 -- yes, it doesn't seem serious enough to worry. But the finished messages (the only MACs that are actually truncated in TLS by default) have been re-used for authentication purposes outside of TLS in the form of channel bindings. You may have more than one attempt to replay a channel-bound authentication token of an authentication inside TLS _without_ invalidating the TLS session. The HMACs on the TLS data records are not reused anywhere. So there a truncation to no less than half the length of the hash would save network bandwith without impairing security according to rfc-2104 section 5. But TLSv1.2 doesn't do that by default. TLS could have taken more advantage of the normative references that it has been carrying through since TLSv1.0, I believe. -Martin From n.mavrogiannopoulos@gmail.com Wed Mar 9 07:26:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3140B3A689F; Wed, 9 Mar 2011 07:26:48 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM1CRop0ZkaW; Wed, 9 Mar 2011 07:26:47 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 189553A6821; Wed, 9 Mar 2011 07:26:47 -0800 (PST) Received: by qyk7 with SMTP id 7so516278qyk.10 for ; Wed, 09 Mar 2011 07:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CkYy8xQwyjVVbxeY/5VmrgkdE+U2hapNtZJDEf3p6tk=; b=v3oI4DZx6ToK+FKrSgGniN4dgs0xy/D7xtjo2abgfNytmb+AO8x45y4pN9WkNWHqXp wUaLSfyC1JMxGNMAUnY9sRzntVSE4A82SgEG0zt+SqNZ9vd60LwS2c1QRuz5NUVIhbMX iiR1iaVG+nkXmWkKw9/Ks3VFekOYDGWcyRmnY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=OX4G1/fAFFPWEONjVbCYaVQOBxPHIzdXd9ABpXv9pnHG5QjsEzTBuyudykES3QHQMq +OD5nKPQBPxXdogyOIVHUI1R3J/BgfnuBrWrThfqKKidgNfVSrZ8Sbckf6FuqViqvC8D exJf6rMWVRg5ucZ5lq3SB5MUGOqCzC+SFaw+g= MIME-Version: 1.0 Received: by 10.229.114.80 with SMTP id d16mr5328408qcq.18.1299684483274; Wed, 09 Mar 2011 07:28:03 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 07:28:03 -0800 (PST) In-Reply-To: References: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 16:28:03 +0100 X-Google-Sender-Auth: cpwoJSdlfMFfPUWPSyc2P9yQfEI Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:26:48 -0000 On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla wrote: >> I'm not a specialist in MAC algorithms but by checking >> the ECRYPT II[0] report of 2009-2010, I can try making some points. >> A MAC has a security level that depends on the size of the MAC >> and the size of the key. That is a 12-byte MAC has security level of >> MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used. >> As I understand the addition of SHA-384 as PRF was to increase >> the security margin of TLS comparing to the SHA-1 PRF. This >> is not occuring now because a MAC based on algorithm that >> returns 384-bits and truncates it =C2=A0to 96 can offer nothing more >> than an algorithm that outputs 160 bits and are trucated to 96. >> Hence there is no significant difference than SHA-1 or SHA-384 >> in that case, so why define SHA-384 anyway? > If you recall, the reason why TLS 1.2 was done was not primarily because > of concerns about SHA-1's 160-bit output being large enough but because > people started developing analytic attacks on MD5 and SHA-1 that brought > it's security level down below the nominal level. > In other words, there are many applications where 80 bits of security is > fine, but people don't want to use SHA-1 because they don't trust it. Such things should be explicit then. In any case I think there is a mistake here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as PRF, and the AES-128 ciphersuites with SHA-256, thus there was intention to match the security strength of the cipher with the size of the hash. If this wasn't the intention, then it is pretty much misleading, and should be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it is being truncated in 96 bits. The choice for SHA-384 was because ..... > Because the attack model for MACs is not the same as the attack model > for encryption. The encryption is susceptible to offline attack, whereas > with a MAC all you need to do is get the guessing probability sufficientl= y > low because *any* failed forgery causes connection termination. This depends on the threat model you have. There might be cases where the case you describe is no problem for the adversary. regards, Nikos From n.mavrogiannopoulos@gmail.com Wed Mar 9 07:33:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9013A6A1A for ; Wed, 9 Mar 2011 07:33:38 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZZ7scNY9vHJ for ; Wed, 9 Mar 2011 07:33:37 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8B68C3A6A14 for ; Wed, 9 Mar 2011 07:33:37 -0800 (PST) Received: by qwh6 with SMTP id 6so568957qwh.31 for ; Wed, 09 Mar 2011 07:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4bjseTIooMESHJ2r5vN1cCZG4sZZifDnqn0IPw3G2So=; b=MfPH+XyOS27fCTyXs4sXmwjg3EISoAk5XwZcUql5KbIkGt1Nl3jzdVVToxUmD3sF7W bD3fdHZEDVyjIKcqONIf2Jlqlz9S9YLNkqqjx8xPKeYEAr10thy15ggyxWnmWf4Og6FA HFg2+nND9+czBfUE1JpL18hyib23Nh3yYRZfY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=pTcWRRw4D2e7n32fR+RcMB4YbKTXgGbJNxv4FKtqYbaGhFn1cZEuRZE/iNmUyHFRNM 0X1UeS70QE1U6Z62cXLVYh5bU9Cc6Gvf09Q5kFGRoZcEr4o3t5TgyPqcBtZQgJSnbwnK SVJZBaLUK1wL/rZ2RDhzBzEuWW6gnpzthvhRw= MIME-Version: 1.0 Received: by 10.229.79.196 with SMTP id q4mr5315167qck.132.1299684893693; Wed, 09 Mar 2011 07:34:53 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 07:34:53 -0800 (PST) In-Reply-To: <201103091523.p29FNrc4016546@fs4113.wdf.sap.corp> References: <201103091523.p29FNrc4016546@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 16:34:53 +0100 X-Google-Sender-Auth: 99MECh6nVaYkbwL5bOB17t9Gzm0 Message-ID: From: Nikos Mavrogiannopoulos To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:33:38 -0000 On Wed, Mar 9, 2011 at 4:23 PM, Martin Rex wrote: > Yes, I'm aware what TLSv1.2 says. =C2=A0But I'm much more aware of > the complete lack of guidance (a pointer to rfc-2104 section 5 > would have been sufficient). > All I've been asking for, is, that (draft-kanno-tls-camellia-00.txt) > should (re-)define the truncation of the finished messages in case > that SHA-384 is used for the PRF to at least 192 bits (24 octets), > following the recommendation in rfc-2104 section 5 in order to obtain a > sensibly balanced crypto of the desired strength -- or alternatively > provide a convincing rationale why it is _not_ following that > recommendation. Actually I think they based their document on RFC5288 that also defines SHA384 as a PRF with a 96-bit MAC. Thus SHA384 has been used quite wrongly already, and it might be confusing to add other SHA384 ciphersuites with a different property. I'd suggest dropping those or using a different name and a longer MAC size. > TLSv1.2 should have used that flexibility itself for a SHA-256 PRF, > and should have provided a pointer to rfc-2104 section 5 for selecting > an adequate truncation size for TLS cipher suite specs that use this > flexibility. Or maybe avoid truncation completely. I don't see why truncation is necessary. The truncated-HMAC extension for TLS records was implemented by almost no-one, but still we use a truncated MAC for the handshake (which only involves 2 messages). regards, Nikos From ekr@rtfm.com Wed Mar 9 07:39:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB753A68D1 for ; Wed, 9 Mar 2011 07:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqYDV1bzG+pB for ; Wed, 9 Mar 2011 07:39:12 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5F8423A67C1 for ; Wed, 9 Mar 2011 07:39:12 -0800 (PST) Received: by iwl42 with SMTP id 42so797207iwl.31 for ; Wed, 09 Mar 2011 07:40:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.58.135 with SMTP id wk7mr149036icb.433.1299685228486; Wed, 09 Mar 2011 07:40:28 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 07:40:28 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Wed, 9 Mar 2011 07:40:28 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:39:13 -0000 On Wed, Mar 9, 2011 at 7:15 AM, Nikos Mavrogiannopoulos w= rote: > On Tue, Mar 8, 2011 at 3:00 PM, Eric Rescorla wrote: > >>> If there is no answer to that, then a DTLS handshake would always requi= re >>> a fixed amount of time (additional to calculations), e.g. 60 seconds - >>> if we take >>> the maximum time allowed for retransmission - to complete. That is beca= use >>> I see protocol transition from >>> "handshake" -> "application data exchange" >>> only after handshake has been fully completed. Or is it implicit that >>> "draft-bmoeller-tls-falsestart-00" applies to DTLS? (in that case it >>> should be explicit). >> >> I don't think I understand the question. >> As soon as either side has *received* the last message it expects to >> get from the >> other side, it can start sending data. > > Ok I think I got the point, but I don't think this is obvious. > What you are suggesting here is that a handshake such as: > > Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Server > > ClientHello =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--------> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ServerHello > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Certificate* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ServerKeyExchange* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0CertificateRequest* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Serv= erHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0[ChangeCipherSpec] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Fini= shed **lost** > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Appl= ication Data > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0[ChangeCipherSpec] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Fini= shed **lost** > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Appl= ication Data > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Appl= ication Data > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0[ChangeCipherSpec] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0Fini= shed > Application Data =A0 =A0 =A0 =A0 =A0 =A0 <-------> =A0Application Data > > is valid for DTLS. I'm not sure what you mean by "valid". The client can't process the server'= s application data until it receives the finished, but the server can certainly send the finished even if the application data is lost. This happens in TLS too, it's just that TCP hides it from the TLS stack. > Something out of curiocity. Why was the handshake layer retransmission an= d > reassembly was preferred comparing to a retransmission and reassembly > layer at the > record protocol (for records exchanged during the handshake protocol)? Because then we would have had to add a whole reliability protocol for the records even though many of the use cases we were concerned with didn't want to hav= e reliable data. This seemed better. It could be that we were wrong of course= . -Ekr From ekr@rtfm.com Wed Mar 9 07:42:11 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABA33A689F for ; Wed, 9 Mar 2011 07:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2B6ujoW60+Y for ; Wed, 9 Mar 2011 07:42:10 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3B79B3A6866 for ; Wed, 9 Mar 2011 07:42:10 -0800 (PST) Received: by iwl42 with SMTP id 42so800469iwl.31 for ; Wed, 09 Mar 2011 07:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.189.202 with SMTP id df10mr7564722icb.366.1299685406674; Wed, 09 Mar 2011 07:43:26 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 07:43:26 -0800 (PST) In-Reply-To: <201103091523.p29FNrc4016546@fs4113.wdf.sap.corp> References: <201103091523.p29FNrc4016546@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 07:43:26 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:42:11 -0000 On Wed, Mar 9, 2011 at 7:23 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Martin Rex wrote: >> > >> > The truncation of the finished message hashes to 96-bits is an undue >> > hard limit in TLSv1.2, and it becomes more aggravating if you're >> > using a hash with an even larger output size than SHA-256 and the >> > truncation of the finished messages is not changed to be no less >> > than half the output size of the hash algorithm. >> >> In that case, you'll be glad to know it's not a hard limit: > > Great, we come around full circle. =A0Does anyone remember the subject > of the thread -- a TLS cipher spec that defines a PRF with SHA-384. Yes, I do. > Yes, I'm aware what TLSv1.2 says. Then why did you call it a hard limit above? It's not. >=A0But I'm much more aware of > the complete lack of guidance (a pointer to rfc-2104 section 5 > would have been sufficient). As both Hovav and I have explained to you, we don't think that guidance is relevant here. > Alternatively, if they favour your attitude that actually > SHA-1 would have been good enough, and SHA-256 is plenty, > they should remove all the -SHA384 ciphersuites from the > document. Yes, that would be fine with me. >> > TLSv1.2 was supposed to provide a framework that can deliver TLS >> > with a strength >128=3Dbits of security. =A0But it failed to deliver >> > this by (1) not adjusting the truncation of the finished messages >> > and (2) not documenting that the truncation of the finished messages >> > MUST be done along with the use of stronger ciphers, stronger hashes >> > and larger key lengths in order to actually obtain a balanced >> > security of the desired higher strength. >> >> Well, as I've said during this thread, I believe your understanding of w= hat >> "security level" means in this context is wrong. I.e., a 128-bit securit= y >> level against offline attack is very different than a 2^{-128} chance of >> successful guessing exactly once on each connection. However, TLS 1.2 >> does in fact have the flexibility you are requesting. > > TLSv1.2 should have used that flexibility itself for a SHA-256 PRF, > and should have provided a pointer to rfc-2104 section 5 for selecting > an adequate truncation size for TLS cipher suite specs that use this > flexibility. > What seems to have happened is that although there are cipher suite > specs that redefine the PRF, they fail to address the truncation > because TLSv1.2 fails to address the truncation ("bad precedent"). As stated above, I disagree with this claim. However, as it's moot now, I don't think there's a lot of point in discussing it further. -Ekr From ekr@rtfm.com Wed Mar 9 07:43:34 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC173A68C1; Wed, 9 Mar 2011 07:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXJwnOyrKvYM; Wed, 9 Mar 2011 07:43:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 46B463A67C1; Wed, 9 Mar 2011 07:43:33 -0800 (PST) Received: by iyj8 with SMTP id 8so798925iyj.31 for ; Wed, 09 Mar 2011 07:44:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.57.131 with SMTP id wg3mr8327136icb.299.1299685489220; Wed, 09 Mar 2011 07:44:49 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 07:44:49 -0800 (PST) In-Reply-To: References: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 07:44:49 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:43:34 -0000 On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos w= rote: > On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla wrote: > >>> I'm not a specialist in MAC algorithms but by checking >>> the ECRYPT II[0] report of 2009-2010, I can try making some points. >>> A MAC has a security level that depends on the size of the MAC >>> and the size of the key. That is a 12-byte MAC has security level of >>> MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used. >>> As I understand the addition of SHA-384 as PRF was to increase >>> the security margin of TLS comparing to the SHA-1 PRF. This >>> is not occuring now because a MAC based on algorithm that >>> returns 384-bits and truncates it =A0to 96 can offer nothing more >>> than an algorithm that outputs 160 bits and are trucated to 96. >>> Hence there is no significant difference than SHA-1 or SHA-384 >>> in that case, so why define SHA-384 anyway? >> If you recall, the reason why TLS 1.2 was done was not primarily because >> of concerns about SHA-1's 160-bit output being large enough but because >> people started developing analytic attacks on MD5 and SHA-1 that brought >> it's security level down below the nominal level. >> In other words, there are many applications where 80 bits of security is >> fine, but people don't want to use SHA-1 because they don't trust it. > > Such things should be explicit then. In any case I think there is a mista= ke > here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as > PRF, and the AES-128 ciphersuites with SHA-256, thus there was > intention to match the security strength of the cipher with the size > of the hash. > > If this wasn't the intention, then it is pretty much misleading, and shou= ld > be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, = it > is being truncated in 96 bits. The choice for SHA-384 was because ..... I'm not one of the authors of that draft, but I imagine for the usual reason of tiling the space of algorithms (not that I consider it a great reason.) -Ekr From mrex@sap.com Wed Mar 9 08:37:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8CC3A6859 for ; Wed, 9 Mar 2011 08:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg5w66zHKvjS for ; Wed, 9 Mar 2011 08:37:39 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 19D663A67FB for ; Wed, 9 Mar 2011 08:37:38 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p29GcjHT021289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 17:38:45 +0100 (MET) From: Martin Rex Message-Id: <201103091638.p29GciBt020741@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 9 Mar 2011 17:38:44 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 9, 11 07:43:26 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] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 16:37:40 -0000 Eric Rescorla wrote: > > > Yes, I'm aware what TLSv1.2 says. > > Then why did you call it a hard limit above? It's not. How do two independent implementations of rfc-5246 use finished messages truncated to no less than 128 bits with the cipher suites TLS_RSA_WITH_AES_256_CBC_SHA256 { 0x00, 0x3D } TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 { 0x00, 0x6A } TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 { 0x00, 0x6B } If the answer is "they can not", then this is what I consider a "hard limit". > > > But I'm much more aware of > > the complete lack of guidance (a pointer to rfc-2104 section 5 > > would have been sufficient). > > As both Hovav and I have explained to you, > we don't think that guidance is relevant here. I hear you saying "nobody needs more than 640KB^W96-bit security for HMACs". The IPSEC fanciers seem to be disagreeing with you by a margin. >From Hovav I only know what he wrote, not what he thinks: > > Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2 > = 192 bits means you are in the former regime rather than the latter. > That's fine, provided k-bit security is sufficient, as 96-bit security is > here; it just means that having built HMAC using SHA384 was overkill, which > it of course was. The existance and contents of rfc4868 indicates that not everyone in the IETF might be agreeing to your opinion that truncation of HMACs to 96 is sufficient security for everyone and everything. For me, a TLS cipher suite spec that wants to provider stronger security than what is available in the base spec and therefore redefines the PRF with a hash that has a longer output value, the truncation of the verify_data in the finished message _is_ relevant. There is another TLS documents (TLS extensions) that _correctly_ points to [HMAC]/[RFC2104] Section 5 for the details of the HMAC truncation: http://tools.ietf.org/html/rfc6066#section-7 and http://tools.ietf.org/html/rfc4366#section-3.5 say Subsequently during the session, clients and servers MUST use truncated HMACs, calculated as specified in [HMAC]. So it is somewhat unlikely that implementors really miss the truncation size guidance in that referenced section 5 of [HMAC]: http://tools.ietf.org/html/rfc2104#section-5 The section where TLSv1.2 does truncation (on the verify_data): http://tools.ietf.org/html/rfc5246#section-7.4.9 lacks this pointer to rfc-2104 section 5. I consider this a defect of rfc-5246 with the result as seen in the spec named in the subject of this thread. Having just re-read 7.4.9 -- where does draft-kanno-tls-camellia-00 actually comply to this MUST of rfc-5246? Any cipher suite which defines a different PRF MUST also define the Hash to use in the Finished computation. A grep -i -e "finish" -e "verify" does not find a match. -Martin > > > > Alternatively, if they favour your attitude that actually > > SHA-1 would have been good enough, and SHA-256 is plenty, > > they should remove all the -SHA384 ciphersuites from the > > document. > > Yes, that would be fine with me. > > > >> > TLSv1.2 was supposed to provide a framework that can deliver TLS > >> > with a strength >128=bits of security.  But it failed to deliver > >> > this by (1) not adjusting the truncation of the finished messages > >> > and (2) not documenting that the truncation of the finished messages > >> > MUST be done along with the use of stronger ciphers, stronger hashes > >> > and larger key lengths in order to actually obtain a balanced > >> > security of the desired higher strength. > >> > >> Well, as I've said during this thread, I believe your understanding of what > >> "security level" means in this context is wrong. I.e., a 128-bit security > >> level against offline attack is very different than a 2^{-128} chance of > >> successful guessing exactly once on each connection. However, TLS 1.2 > >> does in fact have the flexibility you are requesting. > > > > TLSv1.2 should have used that flexibility itself for a SHA-256 PRF, > > and should have provided a pointer to rfc-2104 section 5 for selecting > > an adequate truncation size for TLS cipher suite specs that use this > > flexibility. > > > What seems to have happened is that although there are cipher suite > > specs that redefine the PRF, they fail to address the truncation > > because TLSv1.2 fails to address the truncation ("bad precedent"). > > As stated above, I disagree with this claim. However, as it's moot > now, I don't think > there's a lot of point in discussing it further. > > -Ekr > > From ekr@rtfm.com Wed Mar 9 08:43:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4E63A687A for ; Wed, 9 Mar 2011 08:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHZH5tMttsBD for ; Wed, 9 Mar 2011 08:43:36 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3379D3A6859 for ; Wed, 9 Mar 2011 08:43:36 -0800 (PST) Received: by iwl42 with SMTP id 42so865770iwl.31 for ; Wed, 09 Mar 2011 08:44:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr8750486icb.31.1299689092534; Wed, 09 Mar 2011 08:44:52 -0800 (PST) Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 08:44:52 -0800 (PST) In-Reply-To: <201103091638.p29GciBt020741@fs4113.wdf.sap.corp> References: <201103091638.p29GciBt020741@fs4113.wdf.sap.corp> Date: Wed, 9 Mar 2011 08:44:52 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:43:37 -0000 This message does not appear to provide anything new, so in the interest of not going around in circles, I'll forego a detailed response. -Ekr On Wed, Mar 9, 2011 at 8:38 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> > Yes, I'm aware what TLSv1.2 says. >> >> Then why did you call it a hard limit above? It's not. > > How do two independent implementations of rfc-5246 use finished > messages truncated to no less than 128 bits with the cipher suites > > =A0 TLS_RSA_WITH_AES_256_CBC_SHA256 =A0 =A0 =A0 { 0x00, 0x3D } > =A0 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 =A0 { 0x00, 0x6A } > =A0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 =A0 { 0x00, 0x6B } > > If the answer is "they can not", then this is what I > consider a "hard limit". > >> >> >=A0But I'm much more aware of >> > the complete lack of guidance (a pointer to rfc-2104 section 5 >> > would have been sufficient). >> >> As both Hovav and I have explained to you, >> we don't think that guidance is relevant here. > > I hear you saying "nobody needs more than 640KB^W96-bit security for HMAC= s". > The IPSEC fanciers seem to be disagreeing with you by a margin. > > From Hovav I only know what he wrote, not what he thinks: > >> >> Any truncation of HMAC-SHA384 -- the PRF at hand -- to fewer than 384/2 >> =3D 192 bits means you are in the former regime rather than the latter. >> =A0That's fine, provided k-bit security is sufficient, as 96-bit securit= y is >> here; it just means that having built HMAC using SHA384 was overkill, wh= ich >> it of course was. > > The existance and contents of rfc4868 indicates that not everyone > in the IETF might be agreeing to your opinion that truncation of > HMACs to 96 is sufficient security for everyone and everything. > > > For me, a TLS cipher suite spec that wants to provider stronger > security than what is available in the base spec and therefore redefines > the PRF with a hash that has a longer output value, the truncation of > the verify_data in the finished message _is_ relevant. > > There is another TLS documents (TLS extensions) that _correctly_ > points to [HMAC]/[RFC2104] Section 5 for the details of the HMAC > truncation: > > =A0http://tools.ietf.org/html/rfc6066#section-7 > and > =A0http://tools.ietf.org/html/rfc4366#section-3.5 > > say > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Subsequently during the > =A0 session, clients and servers MUST use truncated HMACs, calculated as > =A0 specified in [HMAC]. > > > So it is somewhat unlikely that implementors really miss the truncation > size guidance in that referenced section 5 of [HMAC]: > > =A0http://tools.ietf.org/html/rfc2104#section-5 > > > The section where TLSv1.2 does truncation (on the verify_data): > > =A0http://tools.ietf.org/html/rfc5246#section-7.4.9 > > lacks this pointer to rfc-2104 section 5. > > I consider this a defect of rfc-5246 with the result as seen > in the spec named in the subject of this thread. > > > Having just re-read 7.4.9 -- where does draft-kanno-tls-camellia-00 > actually comply to this MUST of rfc-5246? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Any cipher suite which defines a diff= erent PRF MUST > =A0 =A0 =A0also define the Hash to use in the Finished computation. > > > A grep -i -e "finish" -e "verify" does not find a match. > > > > -Martin > > > >> >> >> > Alternatively, if they favour your attitude that actually >> > SHA-1 would have been good enough, and SHA-256 is plenty, >> > they should remove all the -SHA384 ciphersuites from the >> > document. >> >> Yes, that would be fine with me. >> >> >> >> > TLSv1.2 was supposed to provide a framework that can deliver TLS >> >> > with a strength >128=3Dbits of security. =A0But it failed to delive= r >> >> > this by (1) not adjusting the truncation of the finished messages >> >> > and (2) not documenting that the truncation of the finished message= s >> >> > MUST be done along with the use of stronger ciphers, stronger hashe= s >> >> > and larger key lengths in order to actually obtain a balanced >> >> > security of the desired higher strength. >> >> >> >> Well, as I've said during this thread, I believe your understanding o= f what >> >> "security level" means in this context is wrong. I.e., a 128-bit secu= rity >> >> level against offline attack is very different than a 2^{-128} chance= of >> >> successful guessing exactly once on each connection. However, TLS 1.2 >> >> does in fact have the flexibility you are requesting. >> > >> > TLSv1.2 should have used that flexibility itself for a SHA-256 PRF, >> > and should have provided a pointer to rfc-2104 section 5 for selecting >> > an adequate truncation size for TLS cipher suite specs that use this >> > flexibility. >> >> > What seems to have happened is that although there are cipher suite >> > specs that redefine the PRF, they fail to address the truncation >> > because TLSv1.2 fails to address the truncation ("bad precedent"). >> >> As stated above, I disagree with this claim. However, as it's moot >> now, I don't think >> there's a lot of point in discussing it further. >> >> -Ekr >> >> > > From turners@ieca.com Wed Mar 9 11:05:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5A43A68AF for ; Wed, 9 Mar 2011 11:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+A4NLDNcqMs for ; Wed, 9 Mar 2011 11:05:08 -0800 (PST) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by core3.amsl.com (Postfix) with SMTP id 4717E3A6892 for ; Wed, 9 Mar 2011 11:05:08 -0800 (PST) Received: from [98.139.91.63] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 09 Mar 2011 19:06:22 -0000 Received: from [98.139.91.34] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 09 Mar 2011 19:06:22 -0000 Received: from [127.0.0.1] by omp1034.mail.sp2.yahoo.com with NNFMP; 09 Mar 2011 19:06:22 -0000 X-Yahoo-Newman-Id: 315617.8151.bm@omp1034.mail.sp2.yahoo.com Received: (qmail 63960 invoked from network); 9 Mar 2011 19:06:22 -0000 Received: from thunderfish.local (turners@71.191.3.104 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 09 Mar 2011 11:06:21 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: svDelhUVM1k4fSoRJsrOVH5F7JJO_icxvVyeNB6P2M4WdR7 0OOHi4zqSNbBSjfocyl5OF9FDvt01xm7CCyRMjRm39Olg92wHHX3a2hm0r1O 2BbH_SyGAVOsb8pKzs5HSyRluYCgAaulx1yUEzN6.NMsJ2fV678KXFpHxQD2 Afu9TW.5z2IeFZCnofqNF0mQj5sEsg5Nrdbw0iO6CHbn0MfueVA7jI3UztYE wgkYsEXzRRYg9BhKkTdxigqwIiVFp8yKnvr8LghnMIFRsWjG49WxoKXzBlfB epY.Ke7zEtwzkBEI.r8iXcYbHNufArgM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D77CFAB.5020506@ieca.com> Date: Wed, 09 Mar 2011 14:06:19 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tls@ietf.org References: <20100723083243.410E2E0638@rfc-editor.org> <540319A8-AD8A-49F9-B022-9308A65E5E40@acm.org> <4D65454E.2010208@ieca.com> <8AA0DCFD-A70F-429D-B88B-96B649F028EF@iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 09 Mar 2011 11:09:23 -0800 Cc: tim.polk@nist.gov, chris@corriente.net, nelson@bolyard.com, vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (2389) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:05:10 -0000 On 2/24/11 6:20 AM, Bodo Moeller wrote: > On Wed, Feb 23, 2011 at 8:37 PM, Juho Vähä-Herttua > wrote: > > >> Thanks, Juho. Yes, the RFC text is wrong in not assigning enum > values > >> here, and the values that you suggest (1 and 2, with extra value > 255 to > >> clearly state the intended width) are the ones that the > specification > >> would have used. > > > > > There are two other places where enums aren't given values: > > > > enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; > > > > and > > > > enum { implicit, explicit } PublicValueEncoding; > > > > Should these also be changed? > > > > The first "other place" is actually exactly the enum which was > originally reported. The ECBasisType indeed is converted to external > representation as can be seen in RFC 4492 section 5.4. struct > ECParameters below the case explicit_char2. PublicValueEncoding > instead is gotten from ClientCertificateType message and doesn't > have external representation. As said in RFC 4492 section 5.7: > > (This is "explicit" in ECC cipher suites except when the client > uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication > mechanism.) > > The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm) > that aren't given values depend on cipher suite and don't need > external representation. However, without the external > representation of ECBasisType it is impossible for the parser to > know if it should only parse "k" or "k1, k2 and k3" from the struct > and it will fail, hence the errata. > > Hope this helps, and feel free to correct me if necessary. I wasn't > sure who the question was asked since the email was addressed to > Bodo, but thought to clarify anyway. > > > Yes, thanks. > > Just to avoid any confusion, let me clarify the context of my previous > statement that "ECBasisType is never actually encoded on the wire": this > was referring to my knowledge about *existing implementations*; it's > clear from the specification that you need to encode ECBasisType on the > wire if you support explicitly specified characteristic-2 curves for > ECDHE ciphersuites. So hearing no objections I'm going to mark this errata as verified. spt From turners@ieca.com Wed Mar 9 12:54:44 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9255F3A6ABC for ; Wed, 9 Mar 2011 12:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jaP0sWXTHpa for ; Wed, 9 Mar 2011 12:54:43 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by core3.amsl.com (Postfix) with SMTP id A09063A6943 for ; Wed, 9 Mar 2011 12:54:43 -0800 (PST) Received: from [98.139.212.153] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2011 20:55:57 -0000 Received: from [98.139.212.201] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2011 20:55:57 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 09 Mar 2011 20:55:57 -0000 X-Yahoo-Newman-Id: 564970.62713.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 14550 invoked from network); 9 Mar 2011 20:55:57 -0000 Received: from thunderfish.local (turners@71.191.3.104 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 09 Mar 2011 12:55:56 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: sgUq0LUVM1mfEmDpdl6QO9FZqHZwSZJwqM9kBmJ7oOISQ.Y nMyjeoRrFShKuzryehKAYGzkyql0Sihkb1AswzXgZJZg_zIIFUFIcA_SDu1y 0FQ55pA7hi213iIuSNBR4rvuWDtubEipSWPjdDj7YBvouNm9Ub6zNPmCtflB jO6OYMjtJPDAjFm6_9Ke2OLUuBrIxOWPXowN5uYDdegacwVNxCdBta72H25n RkbCqC8QoakTkMooBSIH_XySaPNLgk9pu_g3W5AXFVw8qcZAz88BZmbD7DUP T0gQjaUxtd2vqJI6qyf.kmoTF4axC70U7kAZvgdGzmNwUpIPGGEmnOcyKeIt reN7OsHvUXvTg0vA6U1vGntDpzxScviGinGLIUTTfXk0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D77E95C.5010504@ieca.com> Date: Wed, 09 Mar 2011 15:55:56 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <20110127114502.24680.73782.idtracker@localhost><8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> <4D481926.6090409@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:54:44 -0000 On 2/1/11 3:20 PM, Michael Tüxen wrote: > On Feb 1, 2011, at 3:31 PM, Sean Turner wrote: > >> On 2/1/11 4:23 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Michael Tüxen" >>> To: "Florian Weimer" >>> Cc: >>> Sent: Thursday, January 27, 2011 2:49 PM >>> >>> On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote: >>> >>>>> This document describes the Heartbeat Extension for the Transport >>>>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS) >>>>> protocol. >>>> >>>> I think this paragraph >>>> >>>> | There MUST NOT be more than one HeartbeatRequest message in flight >>>> | at a time. >>>> >>>> should be changed to: >>>> >>>> | Retransmissions MUST use the same payload as the original >>>> | HeartbeatRequest message. >>> The intention of the sentence in the ID is that you can not send >>> multiple HeartbeatRequest out. This could overload the network since >>> DTLS uses transport layers which do not necessary provide a congestion >>> control. That is why you can only have one request in flight. >>> Please note that it is not in flight anymore if the corresponding >>> HeartbeatReply has been received or the retransmission timer fires. >>> >>> Michael >>> >>> My experience of the IESG is that they will insist on a paragraph about >>> Congestion Control (lack of) and mitigation thereof. At the same time, >>> I find it very hard to know what words will satisfy them; my most recent >>> experience was with RFC6012, albeit a more complex scenario. >>> >>> Tom Petch >> >> I suspect that the transport ADs' interest will be piqued the minute they read the words: mtu ;) The best thing to do is to ask for an early review from tsv-dir@ietf.org. I'm willing to send it over if you'd like? > Hi Sean, > > yes, please send it over to them. > > Robin and myself are working on some minor text changes and it would be > nice to address also the comments we get from the tsv-dir in the next > revision. >> >> This is my bad, because I haven't yet figured out what magic incantation needs to go in drafts to appease the transport (and probably internet area) ADs. > Hmm. Regarding path MTU discovery we made references to RFC 4821, which > should make them happy (I hope). > > But let us get their comments and improve the document. > > Best regards > Michael >> >> spt >> No word from tsv-dir. I re-pinged the list moderators and ADs. spt From pgut001@login01.cs.auckland.ac.nz Wed Mar 9 15:49:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9778B3A6B07; Wed, 9 Mar 2011 15:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SiBonqNDEHE; Wed, 9 Mar 2011 15:49:40 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1F68A3A6B04; Wed, 9 Mar 2011 15:49:38 -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=1299714658; x=1331250658; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ekr@rtfm.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[TLS]=20Last=20Call:=20=20(Additionx|Cc:=20ietf@ietf.org,=20mrex@sap.com ,=20tls@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Thu, =2010=20Mar=202011=2012:50:54=20+1300; bh=LmWdzLc6LDH36NPieuKARSlYdRcanOv/UDa0t7djjvQ=; b=qoi1TZhSBYpSpT0JXUbb7Gc00bMVUG0P22Xl1N0VQkm8XKnLPjEgOQWn TJLOaS08uEciVus/WxoQxEGq61yae057S2ePoUWAKcbjTxN+FOaCBXHFN 5kZ5VN3QyN+aHm+usJAYntrNV1CA41jvX2/FwXS++8cCWSbGaTJAQ7hkb E=; X-IronPort-AV: E=Sophos;i="4.62,293,1296990000"; d="scan'208";a="50219949" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Mar 2011 12:50:54 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PxT9a-0005j5-H7; Thu, 10 Mar 2011 12:50:54 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PxT9a-0005IZ-8P; Thu, 10 Mar 2011 12:50:54 +1300 From: Peter Gutmann To: ekr@rtfm.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Thu, 10 Mar 2011 12:50:54 +1300 Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:49:41 -0000 Eric Rescorla writes: >Overflowing by another 32 bits is hardly the same as "there was only room >for" If you've decided that the size is going to be 192 bits and, due to other changes, you have only 96 bits left, I don't see how this is anything other than "there was only room for". You can't get 128 bits into 96 no matter how hard you try. Could we perhaps get past the semantic nitpicking and back to the normal bikeshedding? Or at least take it off-list? Peter. From pgut001@login01.cs.auckland.ac.nz Wed Mar 9 15:59:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E30F3A6AF6 for ; Wed, 9 Mar 2011 15:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHsvY5Bkf7jz for ; Wed, 9 Mar 2011 15:59:52 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1E8823A6A61 for ; Wed, 9 Mar 2011 15:59:51 -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=1299715270; x=1331251270; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mike-list@pobox.com,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20TLS=20v1.2=20performance=20(was =20Re:=20TLSv1.2=20with=20DSA=20client|Cc:=20tls@ietf.org |In-Reply-To:=20<4D71E82A.2010702@pobox.com>|Message-Id: =20|Date: =20Thu,=2010=20Mar=202011=2013:00:59=20+1300; bh=WvEAULModaYdvJy8FE2QjB5OfMkoF76ta4+OZEUzzyk=; b=XFwvzBPWoryCU5dvmPy35YVw/xq+Rgef1GpFp0S3B8IAd3u6SR41LsII Mkue78Ys6NOaxXC5BStD0Q3t/G87aK27AvebzBohglJJvShgr5Ddw2Cbm 6KKzBdgBpkVSPrB+69Z6DxCKCBXVywtZM9ThwiYhbqYBEXhm/G9WxRv7w w=; X-IronPort-AV: E=Sophos;i="4.62,292,1296990000"; d="scan'208";a="50223843" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Mar 2011 13:00:59 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PxTJL-00068j-HQ; Thu, 10 Mar 2011 13:00:59 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PxTJL-00066d-BI; Thu, 10 Mar 2011 13:00:59 +1300 From: Peter Gutmann To: mike-list@pobox.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4D71E82A.2010702@pobox.com> Message-Id: Date: Thu, 10 Mar 2011 13:00:59 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:59:53 -0000 Michael D'Errico writes: >Can you please list the other things you found to be completely nuts? >From an informal survey of known TLS 1.2 implementations (several via off-list exchanges) it now appears that *none* of them actually follow the bizarre cert-algorithm requirement in the spec. I'll follow up with more info on other parts of the spec that need to be ignored as soon as I've had time to grep my code for mental-health-related adjectives in comments :-). (Sorry, been a bit busy recently with other stuff). Peter. From wwwrun@rfc-editor.org Wed Mar 9 19:23:34 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A1A3A68AC; Wed, 9 Mar 2011 19:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+VR7d7YXOfN; Wed, 9 Mar 2011 19:23:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 80D053A67F7; Wed, 9 Mar 2011 19:23:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 02B94E074B; Wed, 9 Mar 2011 19:24:51 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110310032451.02B94E074B@rfc-editor.org> Date: Wed, 9 Mar 2011 19:24:51 -0800 (PST) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 6176 on Prohibiting Secure Sockets Layer (SSL) Version 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:23:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6176 Title: Prohibiting Secure Sockets Layer (SSL) Version 2.0 Author: S. Turner, T. Polk Status: Standards Track Stream: IETF Date: March 2011 Mailbox: turners@ieca.com, tim.polk@nist.gov Pages: 4 Characters: 7642 Updates: RFC2246, RFC4346, RFC5246 I-D Tag: draft-ietf-tls-ssl2-must-not-04.txt URL: http://www.rfc-editor.org/rfc/rfc6176.txt This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK] This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From demoss.matt@gmail.com Thu Mar 10 13:58:07 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229D53A6ABC for ; Thu, 10 Mar 2011 13:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3H9wxmWFDx9 for ; Thu, 10 Mar 2011 13:58:06 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 093373A6A79 for ; Thu, 10 Mar 2011 13:58:05 -0800 (PST) Received: by fxm15 with SMTP id 15so475852fxm.31 for ; Thu, 10 Mar 2011 13:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vYyUoo9rSblt47x4g6qVfQOIKvgMLthlf1VxVmtRnds=; b=W6N0hmuOhBsj8s1XVhTBHl0rZpxtzfnVmftKujm/BmhgqKSBIHYASWRfzften+2Loj Q+xmSnfgjMhEaKFdY5hbmbpXnx9c3NiH71J2elRGaNYtm2R0ZIN7bXjLPZxMwPLPKSgp NBKQi3zDWrbhXsVIivW0ipKc4Z10Irm1V6B3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TmM3JMFJch90yKhWfEEPxumsIRiq/F4TBy2WV3VtFQTI2D0ZR1AL18Oq0d6s7lBeBs 4Yp86U7SrAeVVtt1oJqj2wwCK2X56Ji+RS987yJjR11Lrn4eyUSvl6ol23LJsZ602fun rTZqOTgoTHp8Ei8OsPhw3lAdb+i9LXkidavwI= MIME-Version: 1.0 Received: by 10.223.30.66 with SMTP id t2mr784350fac.16.1299794363576; Thu, 10 Mar 2011 13:59:23 -0800 (PST) Received: by 10.223.127.9 with HTTP; Thu, 10 Mar 2011 13:59:23 -0800 (PST) In-Reply-To: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> References: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> Date: Thu, 10 Mar 2011 16:59:23 -0500 Message-ID: From: Matt DeMoss To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:58:07 -0000 On Fri, Mar 4, 2011 at 6:41 PM, Martin Rex wrote: > > The TLS spec should not mess around with PKI and X.509 issues. > Negotiation of the algorithm used for the "digitally signed" struct > ought to be _completely_ seperate from characteristics of certificates. > > A TLS extension to convey hints about digital signature algorithms > ought to be a fairly black box to TLS, containing a list of > ASN.1 AlgIds, and with the semantic of a "hint to the PKI software > for selecting the most appropriate certificates", i.e. "MAY" not "MUST". > This is interesting to me; as a kind of thought experiment do you think it would ever be appropriate for TLS to negotiate hash algorithms on CRLs or on OCSP responses? It seems unlikely that multiple CRLs will be generated with different hashes and that is only slightly less true for X.509 certs. Does it make more sense for TLS to instead negotiate the version of X.509 (or PKIX profile, or other credential) in use and hope some future version will provide functionality for a smoother transition? I read RFC 5280 to say there can only be one signature per certificate, but it isn't hard to imagine having doubly signed certificates in the future. From geoffk@geoffk.org Thu Mar 10 14:39:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEED93A6A9C for ; Thu, 10 Mar 2011 14:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z82qKihRBnx5 for ; Thu, 10 Mar 2011 14:39:14 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id F35E73A6920 for ; Thu, 10 Mar 2011 14:39:13 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E19DC33D1C8; Thu, 10 Mar 2011 22:40:26 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Matt DeMoss References: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 10 Mar 2011 14:40:26 -0800 In-Reply-To: Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 22:39:15 -0000 Matt DeMoss writes: > On Fri, Mar 4, 2011 at 6:41 PM, Martin Rex wrote: > > > > > > The TLS spec should not mess around with PKI and X.509 issues. > > Negotiation of the algorithm used for the "digitally signed" struct > > ought to be _completely_ seperate from characteristics of certificates. > > > > A TLS extension to convey hints about digital signature algorithms > > ought to be a fairly black box to TLS, containing a list of > > ASN.1 AlgIds, and with the semantic of a "hint to the PKI software > > for selecting the most appropriate certificates", i.e. "MAY" not "MUST". > > > > This is interesting to me; as a kind of thought experiment do you > think it would ever be appropriate for TLS to negotiate hash > algorithms on CRLs or on OCSP responses? It seems unlikely that > multiple CRLs will be generated with different hashes and that is only > slightly less true for X.509 certs. Well, let's look at the environment you'd be doing this in. This extension is primarily useful if the server has multiple certificates available and is trying to decide which to send because there is no algorithm which all clients support. So, some CA has issued two certs for this server, one with SHA-1 and one with SHA256. Presumably these two certs have different serial numbers. That means the OCSP responses will be different anyway. If there are intermediate certificates, they also need to match the hash algorithm, no point sending a SHA-1 certificate signed by an intermediate with a SHA256 hash. In that case, the leaf certificates have to have different CRLs because the signers will be different. It also makes no sense to issue two certificates and then point them both at an OCSP responder or CRL which is signed by only one of the hashes. In any situation where you need to issue two certs, that just won't work. So you need to have different OCSP responders (or just one responder that knows to use different hash algorithms for different certificates) and different CRLs. So, I don't think TLS needs to negotiate this, it's implicit in the certificate negotiation. The server probably won't even notice, it just knows that 'this OCSP response goes with this certificate'. BTW, this is a strong argument for negotiating certificate algorithms separately from the "digitally signed" struct: the server does not need to be able to verify its own certificates, or stapled OCSP response, but it does need to implement the algorithm for the signed TLS structures, so having them be negotiated to be the same causes an unnecessary interoperability barrier (between the server and its CA). > Does it make more sense for TLS to instead negotiate the version of > X.509 (or PKIX profile, or other credential) in use and hope some > future version will provide functionality for a smoother transition? I > read RFC 5280 to say there can only be one signature per certificate, > but it isn't hard to imagine having doubly signed certificates in the > future. I can't imagine a problem to which a solution is a new version of X.509. The deployment timeline would be so long that any problem worth fixing would need to be fixed some other way. From mrex@sap.com Thu Mar 10 15:10:35 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C293A69B6 for ; Thu, 10 Mar 2011 15:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93DCNvFMBYhY for ; Thu, 10 Mar 2011 15:10:34 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 833783A69F1 for ; Thu, 10 Mar 2011 15:10:34 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2ANBofk021752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2011 00:11:50 +0100 (MET) From: Martin Rex Message-Id: <201103102311.p2ANBobr004173@fs4113.wdf.sap.corp> To: demoss.matt@gmail.com (Matt DeMoss) Date: Fri, 11 Mar 2011 00:11:50 +0100 (MET) In-Reply-To: from "Matt DeMoss" at Mar 10, 11 04:59:23 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] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 23:10:35 -0000 Matt DeMoss wrote: > > Martin Rex wrote: > > > > The TLS spec should not mess around with PKI and X.509 issues. > > Negotiation of the algorithm used for the "digitally signed" struct > > ought to be _completely_ seperate from characteristics of certificates. > > > > A TLS extension to convey hints about digital signature algorithms > > ought to be a fairly black box to TLS, containing a list of > > ASN.1 AlgIds, and with the semantic of a "hint to the PKI software > > for selecting the most appropriate certificates", i.e. "MAY" not "MUST". > > This is interesting to me; as a kind of thought experiment do you > think it would ever be appropriate for TLS to negotiate hash > algorithms on CRLs or on OCSP responses? It seems unlikely that > multiple CRLs will be generated with different hashes and that is only > slightly less true for X.509 certs. As a black-box TLS extension where apps or the PKI-stack can exchange hints that the peer could take into account when selecting adequate certs, crls or ocsp-responses would be fine. > > Does it make more sense for TLS to instead negotiate the version of > X.509 (or PKIX profile, or other credential) in use and hope some > future version will provide functionality for a smoother transition? The most simple approach would be through the use of seperate trust anchors for seperate algorithm sets. It would work as is with most of the installed base of TLS software. But there are a few PKI diehards (especially those from the "there can be only one Root" PKIs) that are fiercly fighting against having to add a few trust anchors and an 10% additional administrative overhead for a three-digit number of CAs--they rather want the other 6 billions on the planet to suffer long and hard with any migration. > > I read RFC 5280 to say there can only be one signature per certificate, > but it isn't hard to imagine having doubly signed certificates in the > future. Unlike PKCS7/CMS and PGP keys, which can handle multiple independent signatures, X.509 was created with insufficient thought on the security needs of EndEntities. With X.509, the EndEntities have zero effective control about what CAs attribute to their identities. The DANE/keyassurance working group is trying to provide a solution that this problem can be mitigated for TLS server certificates in the future (a solution outside of X.509). I'm actually more concerned about the reluctance of some vendors to ease a transition. Why do I need to manually request a patch like this: http://support.microsoft.com/kb/968730 (I'm using WinXP 64-bit, which is Windows 2003 under the sheets) Vendors with digital signatures on software (and timestamps on those signatures) should not be using sha1 anymore for any of the signatures in that process, and therefore have a genuine interest in getting SHA256 into all of their platforms and with the very next automatic software update... -Martin From kent@bbn.com Thu Mar 10 15:28:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464053A6A7C; Thu, 10 Mar 2011 15:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCnksd3SLp2j; Thu, 10 Mar 2011 15:28:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 72E263A684F; Thu, 10 Mar 2011 15:28:37 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:53861 helo=[10.84.130.113]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PxpIo-000FlL-S7; Thu, 10 Mar 2011 18:29:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> Date: Thu, 10 Mar 2011 18:28:47 -0500 To: Eric Rescorla From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 23:28:38 -0000 At 5:08 PM -0800 3/8/11, Eric Rescorla wrote: >On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann > wrote: >> >> Martin Rex writes: >> >>>Truncating HMACs and PRFs may have become first popular in the IETF within >>>IPSEC. >> >> It wasn't any "may have become first popular", there was only room >>for 96 bits >> of MAC data in the IP packet, so MD5 was truncated to that size. > >This is an odd claim, since: > >(a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally specified >not HMAC but a keyed MD5 variant >with a 128-bit output. >(b) The document that Martin points to has MACs > 96 bits long. > >Can you please point to where in IP there is a limit that requires a >MAC no greater than 96 bits. > >-Ekr What Peter probably meant to say was that IPsec chose to truncate the HMAC value to 96 bits because that preserved IPv4 and IPv6 byte-alignment for the payload. Also, as others have noted, the hash function used here is part of an HMAC calculation, and any collisions have to be real-time exploitable to be of use to an attacker. Thus 96 buts was viewed as sufficient. Steve From turners@ieca.com Thu Mar 10 15:50:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174673A6A7C for ; Thu, 10 Mar 2011 15:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba1Mylk8CQ8K for ; Thu, 10 Mar 2011 15:50:01 -0800 (PST) Received: from nm6.bullet.mail.ac4.yahoo.com (nm6.bullet.mail.ac4.yahoo.com [98.139.52.203]) by core3.amsl.com (Postfix) with SMTP id DAF1B3A67A3 for ; Thu, 10 Mar 2011 15:50:00 -0800 (PST) Received: from [98.139.52.190] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 10 Mar 2011 23:51:16 -0000 Received: from [98.139.52.145] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 10 Mar 2011 23:50:16 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 10 Mar 2011 23:50:16 -0000 X-Yahoo-Newman-Id: 523731.19340.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 99473 invoked from network); 10 Mar 2011 23:50:16 -0000 Received: from thunderfish.local (turners@71.191.12.218 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 10 Mar 2011 15:50:15 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: myIU7OIVM1mRhvbPkpiODayIPLwS.eqL3OymIYXtFbcYdEn 7K9Pjp7G8z6agzegi59O12ezq7Ley.cokzdHlMgT3c2AJPPwqpQ3BnFyy6nP 7oc8qrR3ZdR1wMImxViY4_peJtJbjYFSepH6k0KDuodG4f8AJP1X7XXJvem7 vSfuRFfBMHnceBvdPzgUJTgoz2GLtU1B5p9Wxc.CKXwP4LCezZYMmN6qVEro ajJIrr7u462igltYFx.0el3MeoxYSdAEYVjXuDlTRhJ_6X4lWJX6CBh9N787 gzR7N.N_0VyUpinsKMEnSLA1vx.1q6LzJ7QIlS.cHpd1_Wwhc.iiHoRzCp0G URtimTIeQTQiX7uMe89TgzQ_eDwohAbDrPeNRCys- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D7963B7.4020000@ieca.com> Date: Thu, 10 Mar 2011 18:50:15 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Matt DeMoss References: <201103042341.p24NfVKj018910@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 23:50:02 -0000 On 3/10/11 4:59 PM, Matt DeMoss wrote: > On Fri, Mar 4, 2011 at 6:41 PM, Martin Rex wrote: > > >> >> The TLS spec should not mess around with PKI and X.509 issues. >> Negotiation of the algorithm used for the "digitally signed" struct >> ought to be _completely_ seperate from characteristics of certificates. >> >> A TLS extension to convey hints about digital signature algorithms >> ought to be a fairly black box to TLS, containing a list of >> ASN.1 AlgIds, and with the semantic of a "hint to the PKI software >> for selecting the most appropriate certificates", i.e. "MAY" not "MUST". >> > > This is interesting to me; as a kind of thought experiment do you > think it would ever be appropriate for TLS to negotiate hash > algorithms on CRLs or on OCSP responses? It seems unlikely that > multiple CRLs will be generated with different hashes and that is only > slightly less true for X.509 certs. > > Does it make more sense for TLS to instead negotiate the version of > X.509 (or PKIX profile, or other credential) in use and hope some > future version will provide functionality for a smoother transition? I > read RFC 5280 to say there can only be one signature per certificate, > but it isn't hard to imagine having doubly signed certificates in the > future. Reinventing X.509 PKI ought to be done in PKIX ;) spt From n.mavrogiannopoulos@gmail.com Thu Mar 10 23:19:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146173A687D; Thu, 10 Mar 2011 23:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6+GDUvhpbbw; Thu, 10 Mar 2011 23:19:45 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 7C9293A680D; Thu, 10 Mar 2011 23:19:44 -0800 (PST) Received: by ewy19 with SMTP id 19so988076ewy.31 for ; Thu, 10 Mar 2011 23:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=lDQIHOdZJUve71K92RPaBmpXuNYgtCkEcn0kMbr7Pc8=; b=Ht08NSDm3szPlNX2Gyi3ZCv/HOlKcARtSJfhXHcetQG2a95NV3ytXM7lBxQ+x1sLhF bSe/5Qh5Y2ZcMP3+RIesrPeZ4aHZl3l9J30Xz+PiWcdaZX51ggZ66rWm6qxoSr8XCvn7 DeswB+rrBDJ9sF3xUZeZspq9FKm9p3DWT/1xA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=v3gb+CivvIaYq0I9gLTsoGyXtp78pbm1RWXVVmYjXOtgSHxzgfQb7nXd6TYm2WdAUB kYapZDTGfMUSplRhgVeYNJGfudynXd860Tj3yqeS8ieFcqqe5YGTpRKeMlK2RCb45yHr pgU1vvfi7SBxZ27t836JGyfLkbNkHY7HVXrmY= Received: by 10.14.11.31 with SMTP id 31mr3277859eew.15.1299828062311; Thu, 10 Mar 2011 23:21:02 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id w59sm3183682eeh.21.2011.03.10.23.20.59 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 23:21:00 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D79CD5B.4030002@gnutls.org> Date: Fri, 11 Mar 2011 08:20:59 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Stephen Kent References: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> In-Reply-To: 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, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 07:19:46 -0000 On 03/11/2011 12:28 AM, Stephen Kent wrote: >>> It wasn't any "may have become first popular", there was only >>> room for 96 bits of MAC data in the IP packet, so MD5 was >>> truncated to that size. >> >> This is an odd claim, since: >> >> (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally >> specified not HMAC but a keyed MD5 variant with a 128-bit output. >> (b) The document that Martin points to has MACs > 96 bits long. >> >> Can you please point to where in IP there is a limit that requires >> a MAC no greater than 96 bits. >> >> -Ekr > > What Peter probably meant to say was that IPsec chose to truncate the > HMAC value to 96 bits because that preserved IPv4 and IPv6 > byte-alignment for the payload. Also, as others have noted, the hash > function used here is part of an HMAC calculation, and any collisions > have to be real-time exploitable to be of use to an attacker. Thus > 96 buts was viewed as sufficient. This sounds pretty awkward decision because HMAC per record is full (e.g. 160-bits on SHA-1), but the MAC on the handshake message "signature" is truncated to 96-bits. Why wasn't the record MAC truncated as well? In any case saving few bytes per handshake is much less of value than saving few bytes per record. Was there any other rationale for truncation? regards, Nikos From ekr@rtfm.com Fri Mar 11 06:48:35 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8D13A6948; Fri, 11 Mar 2011 06:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTKP+LosramX; Fri, 11 Mar 2011 06:48:34 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 001D43A68FE; Fri, 11 Mar 2011 06:48:33 -0800 (PST) Received: by iwl42 with SMTP id 42so3354679iwl.31 for ; Fri, 11 Mar 2011 06:49:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.137 with SMTP id uk9mr12328874icb.31.1299854993187; Fri, 11 Mar 2011 06:49:53 -0800 (PST) Received: by 10.42.234.9 with HTTP; Fri, 11 Mar 2011 06:49:53 -0800 (PST) In-Reply-To: <4D79CD5B.4030002@gnutls.org> References: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> <4D79CD5B.4030002@gnutls.org> Date: Fri, 11 Mar 2011 06:49:53 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, Stephen Kent , tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 14:48:35 -0000 If your question is why did the TLS WG decide to do this back in like 1996 or so? If so, it would require a real archive search to get a definitive answer, but my vague memory is that (a) it was suggested by one of the cryptographers in the group, e.g. Hugo Krawczyk or Ran Canetti and (b) it was motivatated by the desire to limit the amount of information disclosed about the MS (remember that it us= ed to be 36 bits!). I don't recall why 12 bytes rather than 16 bytes or 20 was ch= osen. Best, -Ekr On Thu, Mar 10, 2011 at 11:20 PM, Nikos Mavrogiannopoulos wrote: > On 03/11/2011 12:28 AM, Stephen Kent wrote: > >>>> It wasn't any "may have become first popular", there was only >>>> room for 96 bits of MAC data in the IP packet, so MD5 was >>>> truncated to that size. >>> >>> This is an odd claim, since: >>> >>> (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally >>> specified not HMAC but a keyed MD5 variant with a 128-bit output. >>> (b) The document that Martin points to has MACs > 96 bits long. >>> >>> Can you please point to where in IP there is a limit that requires >>> a MAC no greater than 96 bits. >>> >>> -Ekr >> >> What Peter probably meant to say was that IPsec chose to truncate the >> HMAC value to 96 bits because that preserved IPv4 and IPv6 >> byte-alignment for the payload. =A0Also, as others have noted, the hash >> function used here is part of an HMAC calculation, and any collisions >> have to be real-time exploitable to be of use to an attacker. =A0Thus >> 96 buts was viewed as sufficient. > > This sounds pretty awkward decision because HMAC per record is full > (e.g. 160-bits on SHA-1), but the MAC on the handshake message > "signature" is truncated to 96-bits. Why wasn't the record MAC > truncated as well? In any case saving few bytes per handshake > is much less of value than saving few bytes per record. Was > there any other rationale for truncation? > > regards, > Nikos > From mrex@sap.com Fri Mar 11 08:08:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962BF3A68D1; Fri, 11 Mar 2011 08:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtT9vfOJyM0Z; Fri, 11 Mar 2011 08:08:52 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 284B63A69CC; Fri, 11 Mar 2011 08:08:51 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2BG7YKW019159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2011 17:07:34 +0100 (MET) From: Martin Rex Message-Id: <201103111607.p2BG7YDV001679@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Fri, 11 Mar 2011 17:07:34 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 11, 11 06:49:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, kent@bbn.com, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Mar 2011 16:08:53 -0000 Eric Rescorla wrote: > > If your question is why did the TLS WG decide to do this back in like > 1996 or so? > > If so, it would require a real archive search to get a definitive > answer A very superficial scan of the first ietf-tls 1996 archive I came across turned out an an interesting thread "Additional suggested cleanups for TLS" Index page: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/ started on 16-Dec-1996 by Dan Simon with this message: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html and the whole thread is a very interesting read. e.g. excerpt from Dan Simon's message http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html [...] On the other hand, there's simply no justification for using a weaker construction in the (more crucial) finished message than in the standard data MAC. Since you vehemently opposed anything weaker than HMAC for data MACing, even for the sake of efficiency (right here on this mailing list, in fact, when we were discussing pre-MAC'd data), I assume you'd never support using a weaker function in the finished message--right, Phil? In any event, the function used in SSL 3.0's finished message is flawed, [...] In case that Dan Simon stands to his message from 1996, it seems unlikely to me that he would consider a TLS cipher suite design reasonably balanced that uses HMAC-SHA-384 for data MACs, but keeps truncating "the (more crucial) finished message" to 12 octets. Another interesting excerpt from the first message of Dan Simon which started this discussion thread: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html [...] Standardized key generation using PRFs Hugo Krawczyk recently suggested to the WG on this list that an explicit PRF primitive be introduced into the spec, so that the protocol could be based on an easily replaceable function whose assumed properties would be clearly defined and well understood. [...] As well as standardizing the key derivation process, this change to a uniform PRF-based method would encourage implementers to make the PRF pluggable, allowing more secure or more efficient functions to replace the current one in the future as needed. (In fact, we might consider switching to a better PRF immediately, if we are already breaking backward compatibility by changing HMAC.) Ideally the current cipher suites would either implicitly or explicitly specify the current default PRF, so that additional PRF options could be added, if necessary, simply by adding new cipher suites. So the design of the PRF plugabbility was actually invented 1996, and an integral design element of TLSv1.0 (rfc2246 published in Jan-1999). It was never conceived to be limited to only TLSv1.2, and might explain why it is actually pluggable for third parties in Windows XP schannel (which is TLSv1.0) -- Dan Simons signature on these messages reads "Cryptographer, Microsoft Corp.". > > I don't recall why 12 bytes rather than 16 bytes or 20 was chosen. It is not unusual when a two group of folks (IPSEC and TLS) sourcing from the same pool of engineers and experts (IETF) have to do two very similar decisions (truncating HMAC-SHA-1) within a fairly short time, end up with the same conclusion. http://www.ietf.org/html/rfc2404 Jan-1998 HMAC-SHA-1-96 (for IPSEC) http://www.ietf.org/html/rfc2246 Jan-1999 TLSv1.0 The dates vs. rfc-numbers of these two documents look strange: The dates indicate they were published one year apart, but given their rfc-numbers, one would intuitively expect their dates to be just the other way round. -Martin From ekr@rtfm.com Fri Mar 11 08:13:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7A33A6B1A; Fri, 11 Mar 2011 08:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2XaXNJPpVht; Fri, 11 Mar 2011 08:13:46 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 298093A6A32; Fri, 11 Mar 2011 08:13:45 -0800 (PST) Received: by iwl42 with SMTP id 42so3445109iwl.31 for ; Fri, 11 Mar 2011 08:15:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.74.71 with SMTP id v7mr12348653icj.232.1299860104251; Fri, 11 Mar 2011 08:15:04 -0800 (PST) Received: by 10.42.234.9 with HTTP; Fri, 11 Mar 2011 08:15:04 -0800 (PST) In-Reply-To: <201103111607.p2BG7YDV001679@fs4113.wdf.sap.corp> References: <201103111607.p2BG7YDV001679@fs4113.wdf.sap.corp> Date: Fri, 11 Mar 2011 08:15:04 -0800 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, kent@bbn.com, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 16:13:47 -0000 On Fri, Mar 11, 2011 at 8:07 AM, Martin Rex wrote: >> I don't recall why 12 bytes rather than 16 bytes or 20 was chosen. > > It is not unusual when a two group of folks (IPSEC and TLS) sourcing from > the same pool of engineers and experts (IETF) have to do two very > similar decisions (truncating HMAC-SHA-1) within a fairly short time, > end up with the same conclusion. > > =A0http://www.ietf.org/html/rfc2404 =A0Jan-1998 =A0HMAC-SHA-1-96 (for IPS= EC) > =A0http://www.ietf.org/html/rfc2246 =A0Jan-1999 =A0TLSv1.0 > > > The dates vs. rfc-numbers of these two documents look strange: > The dates indicate they were published one year apart, but given > their rfc-numbers, one would intuitively expect their dates to > be just the other way round. TLS 1.0 was held up in process for a long time due to normative dependency issues vis-a-vis PKIX. -Ekr From n.mavrogiannopoulos@gmail.com Sun Mar 13 10:43:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C2B3A6A00 for ; Sun, 13 Mar 2011 10:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42bEOpKuItYg for ; Sun, 13 Mar 2011 10:43:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 25CEE3A69F8 for ; Sun, 13 Mar 2011 10:43:29 -0700 (PDT) Received: by eye13 with SMTP id 13so1688283eye.31 for ; Sun, 13 Mar 2011 10:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=C5CvKM4u3ncJxpdzqu6Tb3BSnv62jdEtkjYmTxsXtTc=; b=M/4kpDTw88rKeH51D+U13KXacE/GMDedfw+5CjH7tXAGY2qgxhY9JtWiE7/3Y2iL+L GO8k+XEGZ82bQZIQDzg65UE1ffHJIP9ITS75XK97opgqJoH+AH+/vScPGFeDpwk1wIA9 Ajc9YJncgNtmekiWELiUxQ7yLUey7/tJRHTqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=XU6HwBjGLj197Eb0XpLoQOB4/h13ky/nmr4bJ2uaCd3fxu0oGSOucfbDp3eWE393zD GFBkisgE644t6xNWeX/p5Hm0eikjMnF1ZDcqyZ/3LNhSXGc+NltSgvgmB6nQatCabH7g 8830ORNji6DejWOhYvPFY8kZqmKSBSQOuw0dM= Received: by 10.213.34.198 with SMTP id m6mr893049ebd.46.1300038291723; Sun, 13 Mar 2011 10:44:51 -0700 (PDT) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id t50sm5235199eeh.18.2011.03.13.10.44.50 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 10:44:50 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D7D0292.7080700@gnutls.org> Date: Sun, 13 Mar 2011 18:44:50 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:43:31 -0000 Hello, I've been reading the section "Denial of Service Countermeasures" of DTLS and as I understand it the proposed subsystem (client-hello and client-hello-verify-request) is expected to operate before allocating state for the session to discard requests from clients with forged addresses. Some comments: 1. The document says: If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie. What does it mean with regards to the handshake sequence. Does the second HelloVerifyRequest has seq=0 or seq=1? 2. There should be some text on how to determine the sequence numbers for the initial conversation without keeping state. As I understand one follows the peer's sequence numbers as reference? e.g. if I receive ClientHello (record_seq=0, seq=0) ------> <-- HelloVerifyRequest (record_seq=0, seq=0) ClientHello (record_seq=1, seq=1) ------> (wrong cookie) <-- HelloVerifyRequest (record_seq=1, seq=1) [seq copied from clienthello] ClientHello (record_seq=2, seq=2) ------> (wrong cookie) <-- HelloVerifyRequest (record_seq=2, seq=2) [seq copied from clienthello] ClientHello (record_seq=3, seq=3) ------> [server allocates session and continues handshake] 3. The document describes a potential attack of an adversary collecting multiple cookies from several servers. Wouldn't adding a 40-bit or more salt to the cookie eliminate that threat? Given that cookie is pretty long (32-bytes) spending 5 or more bytes for a salt and 16 or 20 bytes for an HMAC would be practical. regards, Nikos From n.mavrogiannopoulos@gmail.com Sun Mar 13 10:54:26 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4F33A68C3 for ; Sun, 13 Mar 2011 10:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLV+ipOuN-gG for ; Sun, 13 Mar 2011 10:54:26 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id AE71F3A6A00 for ; Sun, 13 Mar 2011 10:54:25 -0700 (PDT) Received: by ewy19 with SMTP id 19so1690624ewy.31 for ; Sun, 13 Mar 2011 10:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=//j0EvQyF96GGYShSIpwuczRyRgl06TnHqTZRafPFv0=; b=cCSjVw2tS4Nn8mllrCo81qql8T8T8ube7UoLrBTkJjM9lo3qTTYJt4qqHPYSEFydow XJcA/NAVBsVaaqXMcuM+9wrTt9PlTgAq4WTNL2tWOFt31TdRoxaxfciOciH8NTN8nVRY AU/3XsloXwIRY2RpoKLGXGwS7S6fwLTu9fmyE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=qewRb9HH7lkC4htSlTxWkSs3zgPvZQz+vcjeEqm1tyIKRwha4DnxLYYWEe0VUot9Vi uq9UspaknPdApOHCW/dvPht7eXfOslMClPDUzsTqFg9UNbvNxHFY/a6xf00JirokFSXX 2bRaiLYFqJ5lipGdBBFWdDNaj15z9nKjt6Jt8= Received: by 10.213.34.209 with SMTP id m17mr2533013ebd.3.1300038947416; Sun, 13 Mar 2011 10:55:47 -0700 (PDT) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id x54sm5248391eeh.23.2011.03.13.10.55.45 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 10:55:46 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D7D0521.9030509@gnutls.org> Date: Sun, 13 Mar 2011 18:55:45 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: <4D7D0292.7080700@gnutls.org> In-Reply-To: <4D7D0292.7080700@gnutls.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:54:26 -0000 On 03/13/2011 06:44 PM, Nikos Mavrogiannopoulos wrote: > Hello, I've been reading the section "Denial of Service > Countermeasures" of DTLS and as I understand it the proposed > subsystem (client-hello and client-hello-verify-request) is expected > to operate before allocating state for the session to discard > requests from clients with forged addresses. Moreover I think that the requirement that the version field in Client Hello Verify request message, matches the version field in the Server Hello is pretty awkward. The Client Hello Verify request is being sent by the server without allocating any state. Its quite difficult to mandate that he makes the same decision as if state was allocated. Requiring the version of DTLS 1.0 would be more sensible there... regards, Nikos From yngve@opera.com Mon Mar 14 06:44:11 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A043A6D18 for ; Mon, 14 Mar 2011 06:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7g5GkO72L9x for ; Mon, 14 Mar 2011 06:44:10 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id EF7F73A6D59 for ; Mon, 14 Mar 2011 06:44:09 -0700 (PDT) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p2EDjVJ9015390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Mar 2011 13:45:32 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: <20110314133643.E8E2A3A6D48@core3.amsl.com> To: "tls@ietf.org" Date: Mon, 14 Mar 2011 14:45:35 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <20110314133643.E8E2A3A6D48@core3.amsl.com> User-Agent: Opera Mail/10.63 (Win32) Subject: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:44:12 -0000 Hi, I have refreshed the Multiple Certificate Status extension proposal. I have included my conclusions based on last year's discussion of using OCSP extensions to provide the information. My conclusion is that this approach would probably be more complex than this proposal, unless one accept a much higher bandwidth usage. ------- Forwarded message ------- From: "IETF I-D Submission Tool" To: yngve@opera.com Cc: Subject: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-02 Date: Mon, 14 Mar 2011 14:36:43 +0100 A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-02.txt has been successfully submitted by Yngve Pettersen and posted to the IETF repository. Filename: draft-pettersen-tls-ext-multiple-ocsp Revision: 02 Title: Adding Multiple TLS Certificate Status Extension requests Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document introduces a replacement of the TLS Certificate Status Extension to allow clients to specify and support multiple certificate status methods. Also being introduced is a new OCSP- based method that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF Secretariat. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From seggelmann@fh-muenster.de Mon Mar 14 08:11:34 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B235A3A6DAC for ; Mon, 14 Mar 2011 08:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgCzAQmMsiTr for ; Mon, 14 Mar 2011 08:11:33 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 93C643A6905 for ; Mon, 14 Mar 2011 08:11:33 -0700 (PDT) Received: from [212.201.121.94] (helo=[10.0.1.103]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Pz9S0-0006L9-3E; Mon, 14 Mar 2011 16:12:52 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robin Seggelmann In-Reply-To: <4D7D0292.7080700@gnutls.org> Date: Mon, 14 Mar 2011 16:12:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7D0292.7080700@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1082) X-Df-Sender: mail@robin-seggelmann.de Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , tls@ietf.org Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:11:34 -0000 Hi, On Mar 13, 2011, at 6:44 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I've been reading the section "Denial of Service Countermeasures" > of DTLS and as I understand it the proposed subsystem (client-hello > and client-hello-verify-request) is expected to operate before > allocating state for the session to discard requests from clients with > forged addresses. >=20 > Some comments: > 1. The document says: If a server receives a ClientHello with an = invalid > cookie, it SHOULD treat it the same as a ClientHello with no cookie. >=20 > What does it mean with regards to the handshake sequence. Does the > second HelloVerifyRequest has seq=3D0 or seq=3D1? The second HelloVerifyRequest should have seq=3D0 again, since the = server must not change its state. That's how I implemented it in = OpenSSL. The server does not change any sequence numbers until a cookie = has been verified and the regular handshake continues. > 2. There should be some text on how to determine the sequence > numbers for the initial conversation without keeping state. As I > understand one follows the peer's sequence numbers as reference? >=20 > e.g. if I receive > ClientHello (record_seq=3D0, seq=3D0) ------> >=20 > <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >=20 > ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >=20 > <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied from = clienthello] >=20 > ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >=20 > <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied from = clienthello] >=20 > ClientHello (record_seq=3D3, seq=3D3) ------> >=20 > [server allocates session and continues handshake] That may be helpful, but in my opinion "must not change its state" = includes not changing any sequence numbers. > 3. The document describes a potential attack of an adversary > collecting multiple cookies from several servers. > Wouldn't adding a 40-bit or more salt to the cookie > eliminate that threat? Given that cookie is pretty > long (32-bytes) spending 5 or more bytes for a salt > and 16 or 20 bytes for an HMAC would be practical. RFC 4347 only makes suggestions how the cookie may look like and also = states the problems of the suggested approach which may also apply to = similar strategies. You can easily add a timestamp, random number, = encryption, etc. for increased security in your implementation. OpenSSL = leaves the implementation of cookie generation and verification callback = functions to the user. This could be anything from doing nothing to = generating a fully featured cookie. Best regards Robin From mcgrew@cisco.com Mon Mar 14 08:22:56 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DAB3A6A6D for ; Mon, 14 Mar 2011 08:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvFqL0x-nWgk for ; Mon, 14 Mar 2011 08:22:55 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 53D173A6B32 for ; Mon, 14 Mar 2011 08:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1937; q=dns/txt; s=iport; t=1300116259; x=1301325859; h=cc:message-id:from:to:content-transfer-encoding: mime-version:subject:date:references; bh=cgbokhNK/dmXfTdCuFnI/PxjW3egrrLJjRcNu05bPv4=; b=QoxrT0fS5zGVJ+bVMvgPiDZZoGmSES0yGgJpFKls217R3TN1bAXpEDL+ ETg4KtvVxE1y4iCtMqhkvoXM8sRbH+4Y/Ww4sjeHIkvnqwG1AQBpJAN3x wFfaLbnqEBMpBrbYv/RRNmUKo+INCooAcW2BSUoeM3uG86IuxUIYcQCXn 8=; X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208";a="276185471" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2011 15:24:18 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2EFOHXF021981; Mon, 14 Mar 2011 15:24:17 GMT Message-Id: <6F462E9F-9B00-4FBC-B0F2-CC85109866F0@cisco.com> From: David McGrew To: Eric Rescorla , Joe Salowey Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Mar 2011 08:24:16 -0700 References: <20110314150830.922363A6DCC@core3.amsl.com> X-Mailer: Apple Mail (2.936) Cc: "daniel.bailey@rsa.com Bailey" , tls@ietf.org Subject: [TLS] draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:22:57 -0000 Hi Eric and Joe and TLS WG members, I have submitted an updated version of raft-mcgrew-tls-aes-ccm. There are only minor editorial changes since the initial version, which was presented in Maastricht, so there is no need to present an update in Prague. I would like to as the WG to take on this work as a standards track item. It would need to be coordinated with draft-mcgrew-tls-aes-ccm- ecc, which Matt will be presenting in Prague. Here is a quick rundown on the similarities and differences. Both drafts use AES-CCM for TLS 1.2, and they use it in the same way. They differ only in key management and authentication. draft-mcgrew-tls-aes-ccm defines PSK and RSA ciphersuites. draft-mcgrew-tls-aes-ccm-ecc defines ECC ciphersuites. Both drafts define the same AEAD algorithms; eventually, this copy-by-value should be replaced with a copy-by- reference. Comments welcome. regards, David Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 14, 2011 8:08:30 AM PDT > To: mcgrew@cisco.com > Cc: dbailey@rsa.com > Subject: New Version Notification for draft-mcgrew-tls-aes-ccm-01 > > > A new version of I-D, draft-mcgrew-tls-aes-ccm-01.txt has been > successfully submitted by David McGrew and posted to the IETF > repository. > > Filename: draft-mcgrew-tls-aes-ccm > Revision: 01 > Title: AES-CCM Cipher Suites for TLS > Creation_date: 2011-03-14 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This memo describes the use of the Advanced Encryption Standard (AES) > in the Counter and CBC-MAC Mode (CCM) of operation within Transport > Layer Security (TLS) to provide confidentiality and data origin > authentication. The AES-CCM algorithm is amenable to compact > implementations, making it suitable for constrained environments. > > > > The IETF Secretariat. > > From n.mavrogiannopoulos@gmail.com Mon Mar 14 08:28:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DB43A69AA for ; Mon, 14 Mar 2011 08:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrv9VdS+Dkwb for ; Mon, 14 Mar 2011 08:28:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DD3D23A6929 for ; Mon, 14 Mar 2011 08:28:55 -0700 (PDT) Received: by wwa36 with SMTP id 36so3995820wwa.13 for ; Mon, 14 Mar 2011 08:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=lqoGQgquyVSgcccX2gzp7LMPO4eQHs59fKuoXjPMp4I=; b=bY1tFBQAyyZzILvZeaPdl7wfC3ayVPjR6s+NM6Vz9RgUIPomeypYgdFDZfBb8HfTbz WyoRRdqNzbCvggRQZaDoGHlFEhMJchwJUijqztnbF/8igfyMliDnigaUD55MQEoAuTEo EKiwiMdbl8E6aW3rKHuTvTbTdFxqYdKIlxNFg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=A9nLV9UNrO6UY/xhKKGjBna0c/4tqlOgse6m4XL59uJgJCHdnTsf/NFjr8u6axPYmF 02fxc9Txv6fXOjbupBIaMqqcqn+A7CPV+y16Hdbhm3pKdyOB7GBTajL62QAJPLqlDWma Lu2oqWHSf72Vl87p89PGTFj6RsYiDF1rX6TNI= Received: by 10.227.32.132 with SMTP id c4mr11274842wbd.190.1300116619043; Mon, 14 Mar 2011 08:30:19 -0700 (PDT) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id w25sm6226756wbd.11.2011.03.14.08.30.16 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 08:30:17 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D7E3487.7090805@gnutls.org> Date: Mon, 14 Mar 2011 16:30:15 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Robin Seggelmann References: <4D7D0292.7080700@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?T=FCxen?= , =?ISO-8859-1?Q?Michael_?=, tls@ietf.org Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:28:57 -0000 On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >> Hello, I've been reading the section "Denial of Service >> Countermeasures" of DTLS and as I understand it the proposed >> subsystem (client-hello and client-hello-verify-request) is >> expected to operate before allocating state for the session to >> discard requests from clients with forged addresses. >> >> Some comments: 1. The document says: If a server receives a >> ClientHello with an invalid cookie, it SHOULD treat it the same as >> a ClientHello with no cookie. >> >> What does it mean with regards to the handshake sequence. Does the >> second HelloVerifyRequest has seq=0 or seq=1? > > The second HelloVerifyRequest should have seq=0 again, since the > server must not change its state. That's how I implemented it in > OpenSSL. The server does not change any sequence numbers until a > cookie has been verified and the regular handshake continues. What about the record_seq. Is it also 0? If yes a client would see this record packet as a replay and discard it. If no it seems you have to keep state... >> e.g. if I receive ClientHello (record_seq=0, seq=0) ------> >> >> <-- HelloVerifyRequest (record_seq=0, seq=0) >> >> ClientHello (record_seq=1, seq=1) ------> (wrong cookie) >> >> <-- HelloVerifyRequest (record_seq=1, seq=1) [seq copied from >> clienthello] >> >> ClientHello (record_seq=2, seq=2) ------> (wrong cookie) >> >> <-- HelloVerifyRequest (record_seq=2, seq=2) [seq copied from >> clienthello] >> >> ClientHello (record_seq=3, seq=3) ------> >> >> [server allocates session and continues handshake] > That may be helpful, but in my opinion "must not change its state" > includes not changing any sequence numbers. What is of most concern is the record_seq. A client would just discard packets with the same sequence number. regards, Nikos From seggelmann@fh-muenster.de Mon Mar 14 08:51:44 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FB63A6D6C for ; Mon, 14 Mar 2011 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 717z41FO5wKS for ; Mon, 14 Mar 2011 08:51:43 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 27CE93A6D1C for ; Mon, 14 Mar 2011 08:51:39 -0700 (PDT) Received: from [212.201.121.94] (helo=[10.0.1.103]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PzA4m-0007Jv-EW; Mon, 14 Mar 2011 16:52:56 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robin Seggelmann In-Reply-To: <4D7E3487.7090805@gnutls.org> Date: Mon, 14 Mar 2011 16:52:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1082) X-Df-Sender: mail@robin-seggelmann.de Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , tls@ietf.org Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:51:44 -0000 On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: > On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >=20 >>> Hello, I've been reading the section "Denial of Service >>> Countermeasures" of DTLS and as I understand it the proposed >>> subsystem (client-hello and client-hello-verify-request) is >>> expected to operate before allocating state for the session to >>> discard requests from clients with forged addresses. >>>=20 >>> Some comments: 1. The document says: If a server receives a >>> ClientHello with an invalid cookie, it SHOULD treat it the same as >>> a ClientHello with no cookie. >>>=20 >>> What does it mean with regards to the handshake sequence. Does the=20= >>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>=20 >> The second HelloVerifyRequest should have seq=3D0 again, since the >> server must not change its state. That's how I implemented it in >> OpenSSL. The server does not change any sequence numbers until a >> cookie has been verified and the regular handshake continues. >=20 > What about the record_seq. Is it also 0? If yes a client > would see this record packet as a replay and discard it. If no > it seems you have to keep state... The record_seq is still increased, because it has to be unique. I = wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. Regards, Robin >>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) ------> >>>=20 >>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>=20 >>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>=20 >>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied from >>> clienthello] >>>=20 >>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>=20 >>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied from >>> clienthello] >>>=20 >>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>=20 >>> [server allocates session and continues handshake] >> That may be helpful, but in my opinion "must not change its state" >> includes not changing any sequence numbers. >=20 > What is of most concern is the record_seq. A client would just discard > packets with the same sequence number. >=20 > regards, > Nikos From kent@bbn.com Mon Mar 14 08:57:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C4C3A6929; Mon, 14 Mar 2011 08:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq3PoqVUcv7V; Mon, 14 Mar 2011 08:57:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6A6393A696C; Mon, 14 Mar 2011 08:57:52 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49160) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pz9tj-000MNL-Sa; Mon, 14 Mar 2011 11:41:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D79CD5B.4030002@gnutls.org> References: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> <4D79CD5B.4030002@gnutls.org> Date: Mon, 14 Mar 2011 11:41:19 -0400 To: Nikos Mavrogiannopoulos From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:57:53 -0000 At 8:20 AM +0100 3/11/11, Nikos Mavrogiannopoulos wrote: >... > > What Peter probably meant to say was that IPsec chose to truncate the >> HMAC value to 96 bits because that preserved IPv4 and IPv6 >> byte-alignment for the payload. Also, as others have noted, the hash >> function used here is part of an HMAC calculation, and any collisions >> have to be real-time exploitable to be of use to an attacker. Thus >> 96 buts was viewed as sufficient. > >This sounds pretty awkward decision because HMAC per record is full >(e.g. 160-bits on SHA-1), but the MAC on the handshake message >"signature" is truncated to 96-bits. Why wasn't the record MAC >truncated as well? In any case saving few bytes per handshake >is much less of value than saving few bytes per record. Was >there any other rationale for truncation? I think you lost the context here. I was explaining why IPsec chose to truncate the hash, not TLS. Steve From seggelmann@fh-muenster.de Mon Mar 14 09:19:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FAE3A6DFB for ; Mon, 14 Mar 2011 09:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7kEYZPtoQ8x for ; Mon, 14 Mar 2011 09:19:35 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by core3.amsl.com (Postfix) with ESMTP id 066113A696C for ; Mon, 14 Mar 2011 09:19:29 -0700 (PDT) Received: from [80.187.100.251] (helo=[10.152.126.46]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PzAVh-0004b0-0c; Mon, 14 Mar 2011 17:20:46 +0100 References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> In-Reply-To: <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--310097012 Message-Id: <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> X-Mailer: iPhone Mail (8F190) From: Robin Seggelmann Date: Mon, 14 Mar 2011 17:20:33 +0100 To: "nmav@gnutls.org" X-Df-Sender: 229264 Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:19:36 -0000 --Apple-Mail-1--310097012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14.03.2011, at 16:52, Robin Seggelmann wrote:= >=20 > On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >=20 >> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>=20 >>>> Hello, I've been reading the section "Denial of Service >>>> Countermeasures" of DTLS and as I understand it the proposed >>>> subsystem (client-hello and client-hello-verify-request) is >>>> expected to operate before allocating state for the session to >>>> discard requests from clients with forged addresses. >>>>=20 >>>> Some comments: 1. The document says: If a server receives a >>>> ClientHello with an invalid cookie, it SHOULD treat it the same as >>>> a ClientHello with no cookie. >>>>=20 >>>> What does it mean with regards to the handshake sequence. Does the=20 >>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>=20 >>> The second HelloVerifyRequest should have seq=3D0 again, since the >>> server must not change its state. That's how I implemented it in >>> OpenSSL. The server does not change any sequence numbers until a >>> cookie has been verified and the regular handshake continues. >>=20 >> What about the record_seq. Is it also 0? If yes a client >> would see this record packet as a replay and discard it. If no >> it seems you have to keep state... >=20 > The record_seq is still increased, because it has to be unique. I wouldn't= consider this as a problem because it's just a counter you're increasing. T= here is no resource allocation necessary and there is no benefit for an atta= cker to send many ClientHellos to increase the sequence number. It's only us= ed for HMAC verification and replay check and will be reset to 0 after the C= hangCipherSpec anyway. >=20 > However, I see your point. Maybe the document should state more explicitly= that handshake sequence numbers must not be increased, because they always h= ave to be the same and always have to start with 0, while the record_seq has= to be unique and therefore has to change. I forgot to mention that in OpenSSL I'm using the same record_seq counter fo= r every incoming request until a CH with a valid cookie arrives. This is due= to a workaround to implement an UDP based and thus one-to-many style protoc= ol in OpenSSL's one-to-one architecture, but so I'm not required to allocate= anything. > Regards, > Robin >=20 >>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) ------> >>>>=20 >>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>=20 >>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>>=20 >>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied from >>>> clienthello] >>>>=20 >>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>>=20 >>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied from >>>> clienthello] >>>>=20 >>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>=20 >>>> [server allocates session and continues handshake] >>> That may be helpful, but in my opinion "must not change its state" >>> includes not changing any sequence numbers. >>=20 >> What is of most concern is the record_seq. A client would just discard >> packets with the same sequence number. >>=20 >> regards, >> Nikos >=20 >=20 --Apple-Mail-1--310097012 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On 14.03.2011, at 16:52, Robin S= eggelmann <seggelmann@fh-mue= nster.de> wrote:


On Mar 14, 2011, at 4:30 PM, Nikos Ma= vrogiannopoulos wrote:

= On 03/14/2011 04:12 PM, Robin Seggelmann wrote:

Hello, I've= been reading the section "Denial of Service
Countermeasures" of DTLS and as I understand it th= e proposed
subsyste= m (client-hello and client-hello-verify-request) is
<= /blockquote>
expected to operate before allocating state= for the session to
discard requests from clients with forged addresses.

Some comments: 1. The document says: If a server receives a=
=
ClientHello with a= n invalid cookie, it SHOULD treat it the same as
a ClientHello with no cookie.

=
What does it mean with regards to the handshake sequenc= e. Does the
second= HelloVerifyRequest has seq=3D0 or seq=3D1?
<= /span>
The second HelloVerifyRequest should have seq=3D0 again, s= ince the
server must not change its state. That's how I im= plemented it in
OpenSSL.  The server does not change a= ny sequence numbers until a
cookie has been verified and th= e regular handshake continues.

What about the record_seq. Is it also 0? If yes  a client
=
would see this record packet as= a replay and discard it. If no
it seems you have to keep state...
<= /span>
The record_seq is still increased, because it has to be uniq= ue. I wouldn't consider this as a problem because it's just a counter you're= increasing. There is no resource allocation necessary and there is no benef= it for an attacker to send many ClientHellos to increase the sequence number= . It's only used for HMAC verification and replay check and will be reset to= 0 after the ChangCipherSpec anyway.

Howeve= r, I see your point. Maybe the document should state more explicitly that ha= ndshake sequence numbers must not be increased, because they always have to b= e the same and always have to start with 0, while the record_seq has to be u= nique and therefore has to change.

I forgot to mention that in O= penSSL I'm using the same record_seq counter for every incoming request unti= l a CH with a valid cookie arrives. This is due to a workaround to implement= an UDP based and thus one-to-many style protocol in OpenSSL's one-to-one ar= chitecture, but so I'm not required to allocate anything.

Regards,
Robin

e.g. if I re= ceive ClientHello (record_seq=3D0, seq=3D0)  ------>

<-- HelloVerifyRequest (record_seq=3D0, seq=3D0)<= /span>
<= blockquote type=3D"cite">

ClientHello (record_seq=3D1, seq=3D1)=  ------> (wrong cookie)

<-= - HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied from
clienthello]

=
ClientHello (record_seq=3D2, seq=3D2)  ------> (= wrong cookie)

<-- HelloVerifyReque= st (record_seq=3D2, seq=3D2) [seq copied from
clienthello]
=

ClientHello (record_seq=3D3, seq=3D3)  ------>

=
[server allocates session and continues handshake]
That may be helpful, but in my opinion "must not c= hange its state"
includes not changing any sequence number= s.

What is of most concern i= s the record_seq. A client would just discard
packets with the same sequence number.

regards,
Nikos


= --Apple-Mail-1--310097012-- From mrex@sap.com Mon Mar 14 10:27:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C773A6D6C; Mon, 14 Mar 2011 10:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3oHp6rBKNZk; Mon, 14 Mar 2011 10:27:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 71CD73A6D26; Mon, 14 Mar 2011 10:27:50 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2EHSYrn001515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Mar 2011 18:28:34 +0100 (MET) From: Martin Rex Message-Id: <201103141728.p2EHSXl3019185@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Mar 2011 18:28:33 +0100 (MET) In-Reply-To: <4D79CD5B.4030002@gnutls.org> from "Nikos Mavrogiannopoulos" at Mar 11, 11 08:20:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ietf@ietf.org, kent@bbn.com Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:27:51 -0000 Nikos Mavrogiannopoulos wrote: > > This sounds pretty awkward decision because HMAC per record is full > (e.g. 160-bits on SHA-1), but the MAC on the handshake message > "signature" is truncated to 96-bits. Why wasn't the record MAC > truncated as well? In any case saving few bytes per handshake > is much less of value than saving few bytes per record. Was > there any other rationale for truncation? Are you wondering why the HMAC on the TLS data records is is sent in its full beauty, while the TLS Finished.verify_data is a truncated output of the PRF (which in the abstract definintion uses HMAC as the outermost function, but in the case of TLSv1.0 is actually the XOR of two different HMACs over half the secret). The reason might be about the "secret" input to the HMAC, which in case of the TLS data records is a derived traffic key, while in case of the Finished.verify_data, is the "master secret" of the session. That was, what I assume, the fear, based on the second part of this message from Dan Simon http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html and the second part of this message from Hugo Krawczyk http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html Since the TLSv1.0 finished message was defined based on the output of the TLS PRF (a function with indefinite output length), defining a truncation was inevitable. :) A Finished message of 20 bytes size would have required A(1) for SHA-1 and A(2) for MD5, a 16 bytes size would only have required A(1) from both, but truncated the P_SHA1() output by 32 bits while leaving the P_MD5() output in full. For 12 bytes size, both P_SHA1() and P_MD5() output is truncated (by 64 and 32 bits respectively), while still remaining in the "safe truncation" area of "no less than half the output size of the underlying hash function" (rfc-2104, section-5) for both MD5 and SHA-1. Recall how the TLS PRF is defined in TLSv1.0 (rfc-2246): http://tools.ietf.org/html/rfc2246#page-12 first as a generic TLS PRF: P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ... Where + indicates concatenation. A() is defined as: A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) Then as a specific PRF for use with TLSv1.0 (reused by TLSv1.1) http://tools.ietf.org/html/rfc2246#page-12 S1 and S2 are the two halves of the secret and each is the same length. S1 is taken from the first half of the secret, S2 from the second half. Their length is created by rounding up the length of the overall secret divided by two; thus, if the original secret is an odd number of bytes long, the last byte of S1 will be the same as the first byte of S2. L_S = length in bytes of secret; L_S1 = L_S2 = ceil(L_S / 2); The secret is partitioned into two halves (with the possibility of one shared byte) as described above, S1 taking the first L_S1 bytes and S2 the last L_S2 bytes. The [TLSv1.0] PRF is then defined as the result of mixing the two pseudorandom streams by exclusive-or'ing them together. PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); and how it is used in the TLSv1.0 Finished message: http://tools.ietf.org/html/rfc2246#page-46 struct { opaque verify_data[12]; } Finished; verify_data PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; -Martin From Michael.Tuexen@lurchi.franken.de Mon Mar 14 10:59:58 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44283A6D80 for ; Mon, 14 Mar 2011 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+kv2qTUKR5R for ; Mon, 14 Mar 2011 10:59:58 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id EF0CB3A6A3A for ; Mon, 14 Mar 2011 10:59:55 -0700 (PDT) Received: from [192.168.1.113] (p5481DBED.dip.t-dialin.net [84.129.219.237]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B818B1C0C0BD8; Mon, 14 Mar 2011 19:01:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> Date: Mon, 14 Mar 2011 19:01:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> To: Robin Seggelmann X-Mailer: Apple Mail (2.1082) Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:59:59 -0000 On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >=20 >=20 > On 14.03.2011, at 16:52, Robin Seggelmann = wrote: >=20 >>=20 >> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>=20 >>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>=20 >>>>> Hello, I've been reading the section "Denial of Service >>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>> subsystem (client-hello and client-hello-verify-request) is >>>>> expected to operate before allocating state for the session to >>>>> discard requests from clients with forged addresses. >>>>>=20 >>>>> Some comments: 1. The document says: If a server receives a >>>>> ClientHello with an invalid cookie, it SHOULD treat it the same as >>>>> a ClientHello with no cookie. >>>>>=20 >>>>> What does it mean with regards to the handshake sequence. Does the=20= >>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>=20 >>>> The second HelloVerifyRequest should have seq=3D0 again, since the >>>> server must not change its state. That's how I implemented it in >>>> OpenSSL. The server does not change any sequence numbers until a >>>> cookie has been verified and the regular handshake continues. >>>=20 >>> What about the record_seq. Is it also 0? If yes a client >>> would see this record packet as a replay and discard it. If no >>> it seems you have to keep state... >>=20 >> The record_seq is still increased, because it has to be unique. I = wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. >>=20 >> However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. >=20 > I forgot to mention that in OpenSSL I'm using the same record_seq = counter for every incoming request until a CH with a valid cookie = arrives. This is due to a workaround to implement an UDP based and thus = one-to-many style protocol in OpenSSL's one-to-one architecture, but so = I'm not required to allocate anything. Hi Robin, can you be more specific? Did you implement it such that Nikos message exchange is valid? So do you copy the rec. seq. number from the incoming packet? Do you use the same counter for multiple client until you receive a CH with a valid cookie? Best regards Michael >=20 >> Regards, >> Robin >>=20 >>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) ------> >>>>>=20 >>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>=20 >>>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>>>=20 >>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied from >>>>> clienthello] >>>>>=20 >>>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>>>=20 >>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied from >>>>> clienthello] >>>>>=20 >>>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>>=20 >>>>> [server allocates session and continues handshake] >>>> That may be helpful, but in my opinion "must not change its state" >>>> includes not changing any sequence numbers. >>>=20 >>> What is of most concern is the record_seq. A client would just = discard >>> packets with the same sequence number. >>>=20 >>> regards, >>> Nikos >>=20 >>=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From seggelmann@fh-muenster.de Mon Mar 14 11:15:08 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011893A6E99 for ; Mon, 14 Mar 2011 11:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VScvcx-pyFxF for ; Mon, 14 Mar 2011 11:15:07 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by core3.amsl.com (Postfix) with ESMTP id 196573A6E95 for ; Mon, 14 Mar 2011 11:15:06 -0700 (PDT) Received: from [92.224.175.10] (helo=solemac.solenet.lan) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PzCJX-0003RK-1P; Mon, 14 Mar 2011 19:16:19 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Robin Seggelmann In-Reply-To: Date: Mon, 14 Mar 2011 19:16:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> To: =?iso-8859-1?Q?Michael_T=FCxen?= X-Mailer: Apple Mail (2.1082) X-Df-Sender: fh@robin-seggelmann.de Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:15:08 -0000 On 14.03.2011, at 19:01, Michael T=FCxen wrote: > On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>=20 >>=20 >> On 14.03.2011, at 16:52, Robin Seggelmann = wrote: >>=20 >>>=20 >>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>=20 >>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>=20 >>>>>> Hello, I've been reading the section "Denial of Service >>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>> expected to operate before allocating state for the session to >>>>>> discard requests from clients with forged addresses. >>>>>>=20 >>>>>> Some comments: 1. The document says: If a server receives a >>>>>> ClientHello with an invalid cookie, it SHOULD treat it the same = as >>>>>> a ClientHello with no cookie. >>>>>>=20 >>>>>> What does it mean with regards to the handshake sequence. Does = the=20 >>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>=20 >>>>> The second HelloVerifyRequest should have seq=3D0 again, since the >>>>> server must not change its state. That's how I implemented it in >>>>> OpenSSL. The server does not change any sequence numbers until a >>>>> cookie has been verified and the regular handshake continues. >>>>=20 >>>> What about the record_seq. Is it also 0? If yes a client >>>> would see this record packet as a replay and discard it. If no >>>> it seems you have to keep state... >>>=20 >>> The record_seq is still increased, because it has to be unique. I = wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. >>>=20 >>> However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. >>=20 >> I forgot to mention that in OpenSSL I'm using the same record_seq = counter for every incoming request until a CH with a valid cookie = arrives. This is due to a workaround to implement an UDP based and thus = one-to-many style protocol in OpenSSL's one-to-one architecture, but so = I'm not required to allocate anything. > Hi Robin, >=20 > can you be more specific? Did you implement it such that Nikos > message exchange is valid? So do you copy the rec. seq. number > from the incoming packet? Do you use the same counter for multiple > client until you receive a CH with a valid cookie? I don't copy the record sequence. The server is using one counter for = multiple clients until the CH with a valid cookie. So the first = HelloVerifyRequest has record seq 0, the second 1 and so on. When a = cookie has been verified, the ServerHello will have the next record seq, = while the next HelloVerifyRequest for an other client will have 0 again. This is because I'm using an SSL object (and its rec seq counter) for = listening, which will be assigned to the first client with a valid = cookie to continue the connection, so the next handshake message, that = is the ServerHello, will habe the next record seq. A new SSL object = (with reset counters) is then created to continue listening and = responding to ClientHellos. Best reagards, Robin > Best regards > Michael >>=20 >>> Regards, >>> Robin >>>=20 >>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) ------> >>>>>>=20 >>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>=20 >>>>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>>>>=20 >>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied from >>>>>> clienthello] >>>>>>=20 >>>>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>>>>=20 >>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied from >>>>>> clienthello] >>>>>>=20 >>>>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>>>=20 >>>>>> [server allocates session and continues handshake] >>>>> That may be helpful, but in my opinion "must not change its state" >>>>> includes not changing any sequence numbers. >>>>=20 >>>> What is of most concern is the record_seq. A client would just = discard >>>> packets with the same sequence number. >>>>=20 >>>> regards, >>>> Nikos >>>=20 >>>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 Viele Gr=FC=DFe Robin From Michael.Tuexen@lurchi.franken.de Mon Mar 14 12:12:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3243A6B5A for ; Mon, 14 Mar 2011 12:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txlylrhdXubl for ; Mon, 14 Mar 2011 12:11:59 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id C2EF03A6AA9 for ; Mon, 14 Mar 2011 12:11:58 -0700 (PDT) Received: from [192.168.1.113] (p5481DBED.dip.t-dialin.net [84.129.219.237]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6A7AD1C0B4619; Mon, 14 Mar 2011 20:13:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Mon, 14 Mar 2011 20:13:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> To: Robin Seggelmann X-Mailer: Apple Mail (2.1082) Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:12:00 -0000 On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote: >=20 > On 14.03.2011, at 19:01, Michael T=FCxen wrote: >=20 >> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>>=20 >>>=20 >>> On 14.03.2011, at 16:52, Robin Seggelmann = wrote: >>>=20 >>>>=20 >>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>>=20 >>>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>>=20 >>>>>>> Hello, I've been reading the section "Denial of Service >>>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>>> expected to operate before allocating state for the session to >>>>>>> discard requests from clients with forged addresses. >>>>>>>=20 >>>>>>> Some comments: 1. The document says: If a server receives a >>>>>>> ClientHello with an invalid cookie, it SHOULD treat it the same = as >>>>>>> a ClientHello with no cookie. >>>>>>>=20 >>>>>>> What does it mean with regards to the handshake sequence. Does = the=20 >>>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>>=20 >>>>>> The second HelloVerifyRequest should have seq=3D0 again, since = the >>>>>> server must not change its state. That's how I implemented it in >>>>>> OpenSSL. The server does not change any sequence numbers until a >>>>>> cookie has been verified and the regular handshake continues. >>>>>=20 >>>>> What about the record_seq. Is it also 0? If yes a client >>>>> would see this record packet as a replay and discard it. If no >>>>> it seems you have to keep state... >>>>=20 >>>> The record_seq is still increased, because it has to be unique. I = wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. >>>>=20 >>>> However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. >>>=20 >>> I forgot to mention that in OpenSSL I'm using the same record_seq = counter for every incoming request until a CH with a valid cookie = arrives. This is due to a workaround to implement an UDP based and thus = one-to-many style protocol in OpenSSL's one-to-one architecture, but so = I'm not required to allocate anything. >> Hi Robin, >>=20 >> can you be more specific? Did you implement it such that Nikos >> message exchange is valid? So do you copy the rec. seq. number >> from the incoming packet? Do you use the same counter for multiple >> client until you receive a CH with a valid cookie? >=20 > I don't copy the record sequence. The server is using one counter for = multiple clients until the CH with a valid cookie. So the first = HelloVerifyRequest has record seq 0, the second 1 and so on. When a = cookie has been verified, the ServerHello will have the next record seq, = while the next HelloVerifyRequest for an other client will have 0 again. So does this mean that one client affects the other? Best regards Michael >=20 > This is because I'm using an SSL object (and its rec seq counter) for = listening, which will be assigned to the first client with a valid = cookie to continue the connection, so the next handshake message, that = is the ServerHello, will habe the next record seq. A new SSL object = (with reset counters) is then created to continue listening and = responding to ClientHellos. >=20 > Best reagards, > Robin >=20 >> Best regards >> Michael >>>=20 >>>> Regards, >>>> Robin >>>>=20 >>>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) ------> >>>>>>>=20 >>>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>>=20 >>>>>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>>>>>=20 >>>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied = from >>>>>>> clienthello] >>>>>>>=20 >>>>>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>>>>>=20 >>>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied = from >>>>>>> clienthello] >>>>>>>=20 >>>>>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>>>>=20 >>>>>>> [server allocates session and continues handshake] >>>>>> That may be helpful, but in my opinion "must not change its = state" >>>>>> includes not changing any sequence numbers. >>>>>=20 >>>>> What is of most concern is the record_seq. A client would just = discard >>>>> packets with the same sequence number. >>>>>=20 >>>>> regards, >>>>> Nikos >>>>=20 >>>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 >=20 >=20 > Viele Gr=FC=DFe > Robin >=20 >=20 >=20 >=20 >=20 >=20 From seggelmann@fh-muenster.de Mon Mar 14 12:25:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BC33A6B4E for ; Mon, 14 Mar 2011 12:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmwmIgMVYGDb for ; Mon, 14 Mar 2011 12:25:46 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by core3.amsl.com (Postfix) with ESMTP id 518C13A6979 for ; Mon, 14 Mar 2011 12:25:46 -0700 (PDT) Received: from [92.224.175.10] (helo=solemac.solenet.lan) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PzDPu-0004Z1-SG; Mon, 14 Mar 2011 20:26:59 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Robin Seggelmann In-Reply-To: Date: Mon, 14 Mar 2011 20:26:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> To: =?iso-8859-1?Q?Michael_T=FCxen?= X-Mailer: Apple Mail (2.1082) X-Df-Sender: fh@robin-seggelmann.de Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:25:47 -0000 On 14.03.2011, at 20:13, Michael T=FCxen wrote: > On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote: >>=20 >> On 14.03.2011, at 19:01, Michael T=FCxen wrote: >>=20 >>> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>>>=20 >>>>=20 >>>> On 14.03.2011, at 16:52, Robin Seggelmann = wrote: >>>>=20 >>>>>=20 >>>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>>>=20 >>>>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>>>=20 >>>>>>>> Hello, I've been reading the section "Denial of Service >>>>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>>>> expected to operate before allocating state for the session to >>>>>>>> discard requests from clients with forged addresses. >>>>>>>>=20 >>>>>>>> Some comments: 1. The document says: If a server receives a >>>>>>>> ClientHello with an invalid cookie, it SHOULD treat it the same = as >>>>>>>> a ClientHello with no cookie. >>>>>>>>=20 >>>>>>>> What does it mean with regards to the handshake sequence. Does = the=20 >>>>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>>>=20 >>>>>>> The second HelloVerifyRequest should have seq=3D0 again, since = the >>>>>>> server must not change its state. That's how I implemented it in >>>>>>> OpenSSL. The server does not change any sequence numbers until = a >>>>>>> cookie has been verified and the regular handshake continues. >>>>>>=20 >>>>>> What about the record_seq. Is it also 0? If yes a client >>>>>> would see this record packet as a replay and discard it. If no >>>>>> it seems you have to keep state... >>>>>=20 >>>>> The record_seq is still increased, because it has to be unique. I = wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. >>>>>=20 >>>>> However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. >>>>=20 >>>> I forgot to mention that in OpenSSL I'm using the same record_seq = counter for every incoming request until a CH with a valid cookie = arrives. This is due to a workaround to implement an UDP based and thus = one-to-many style protocol in OpenSSL's one-to-one architecture, but so = I'm not required to allocate anything. >>> Hi Robin, >>>=20 >>> can you be more specific? Did you implement it such that Nikos >>> message exchange is valid? So do you copy the rec. seq. number >>> from the incoming packet? Do you use the same counter for multiple >>> client until you receive a CH with a valid cookie? >>=20 >> I don't copy the record sequence. The server is using one counter for = multiple clients until the CH with a valid cookie. So the first = HelloVerifyRequest has record seq 0, the second 1 and so on. When a = cookie has been verified, the ServerHello will have the next record seq, = while the next HelloVerifyRequest for an other client will have 0 again. > So does this mean that one client affects the other? Only by increasing the record sequence. As an example, a scenario with a = low RTT client (lc), a high RTT (hc) client, the server listening with = SSL object s1 and then s2: hc: ClientHello(rseq:0, hseq: 0) s1: HelloVerifyRequest(rseq:0, hseq:0) lc: ClientHello(rseq:0, hseq: 0) s1: HelloVerifyRequest(rseq:1, hseq:0) lc: ClientHelloCookie(rseq:1, hseq: 1) s1 will be connected to lc, now s2 listens s1: ServerHello(rseq:2, hseq:1) hc: ClientHelloCookie(rseq:1, hseq: 1) s2 will be connected to hc, now s3 listens s1: ServerHello(rseq:0, hseq:1) So the more ClientHellos arrive before one with a valid cookie, the = higher is the record sequence number. That's the only "state" in the = server that changes. Otherwise I would have to maintain the record = sequence per client which would require resource allocation or always = use the same with the retransmission issues Nikos pointed out. Regards, Robin > Best regards > Michael >>=20 >> This is because I'm using an SSL object (and its rec seq counter) for = listening, which will be assigned to the first client with a valid = cookie to continue the connection, so the next handshake message, that = is the ServerHello, will habe the next record seq. A new SSL object = (with reset counters) is then created to continue listening and = responding to ClientHellos. >>=20 >> Best reagards, >> Robin >>=20 >>> Best regards >>> Michael >>>>=20 >>>>> Regards, >>>>> Robin >>>>>=20 >>>>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) = ------> >>>>>>>>=20 >>>>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>>>=20 >>>>>>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>>>>>>=20 >>>>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied = from >>>>>>>> clienthello] >>>>>>>>=20 >>>>>>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>>>>>>=20 >>>>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied = from >>>>>>>> clienthello] >>>>>>>>=20 >>>>>>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>>>>>=20 >>>>>>>> [server allocates session and continues handshake] >>>>>>> That may be helpful, but in my opinion "must not change its = state" >>>>>>> includes not changing any sequence numbers. >>>>>>=20 >>>>>> What is of most concern is the record_seq. A client would just = discard >>>>>> packets with the same sequence number. >>>>>>=20 >>>>>> regards, >>>>>> Nikos >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>=20 >>=20 From Michael.Tuexen@lurchi.franken.de Mon Mar 14 12:41:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4436C3A6E47 for ; Mon, 14 Mar 2011 12:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTRBOCRTya13 for ; Mon, 14 Mar 2011 12:41:12 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 45E7B3A6B1F for ; Mon, 14 Mar 2011 12:41:11 -0700 (PDT) Received: from [192.168.1.113] (p5481DBED.dip.t-dialin.net [84.129.219.237]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0DA671C0B4620; Mon, 14 Mar 2011 20:42:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> Date: Mon, 14 Mar 2011 20:42:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> To: Robin Seggelmann X-Mailer: Apple Mail (2.1082) Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:41:13 -0000 On Mar 14, 2011, at 8:26 PM, Robin Seggelmann wrote: >=20 > On 14.03.2011, at 20:13, Michael T=FCxen wrote: >=20 >> On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote: >>>=20 >>> On 14.03.2011, at 19:01, Michael T=FCxen wrote: >>>=20 >>>> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>>>>=20 >>>>>=20 >>>>> On 14.03.2011, at 16:52, Robin Seggelmann = wrote: >>>>>=20 >>>>>>=20 >>>>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>>>>=20 >>>>>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>>>>=20 >>>>>>>>> Hello, I've been reading the section "Denial of Service >>>>>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>>>>> expected to operate before allocating state for the session to >>>>>>>>> discard requests from clients with forged addresses. >>>>>>>>>=20 >>>>>>>>> Some comments: 1. The document says: If a server receives a >>>>>>>>> ClientHello with an invalid cookie, it SHOULD treat it the = same as >>>>>>>>> a ClientHello with no cookie. >>>>>>>>>=20 >>>>>>>>> What does it mean with regards to the handshake sequence. Does = the=20 >>>>>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>>>>=20 >>>>>>>> The second HelloVerifyRequest should have seq=3D0 again, since = the >>>>>>>> server must not change its state. That's how I implemented it = in >>>>>>>> OpenSSL. The server does not change any sequence numbers until = a >>>>>>>> cookie has been verified and the regular handshake continues. >>>>>>>=20 >>>>>>> What about the record_seq. Is it also 0? If yes a client >>>>>>> would see this record packet as a replay and discard it. If no >>>>>>> it seems you have to keep state... >>>>>>=20 >>>>>> The record_seq is still increased, because it has to be unique. I = wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. >>>>>>=20 >>>>>> However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. >>>>>=20 >>>>> I forgot to mention that in OpenSSL I'm using the same record_seq = counter for every incoming request until a CH with a valid cookie = arrives. This is due to a workaround to implement an UDP based and thus = one-to-many style protocol in OpenSSL's one-to-one architecture, but so = I'm not required to allocate anything. >>>> Hi Robin, >>>>=20 >>>> can you be more specific? Did you implement it such that Nikos >>>> message exchange is valid? So do you copy the rec. seq. number >>>> from the incoming packet? Do you use the same counter for multiple >>>> client until you receive a CH with a valid cookie? >>>=20 >>> I don't copy the record sequence. The server is using one counter = for multiple clients until the CH with a valid cookie. So the first = HelloVerifyRequest has record seq 0, the second 1 and so on. When a = cookie has been verified, the ServerHello will have the next record seq, = while the next HelloVerifyRequest for an other client will have 0 again. >> So does this mean that one client affects the other? >=20 > Only by increasing the record sequence. As an example, a scenario with = a low RTT client (lc), a high RTT (hc) client, the server listening with = SSL object s1 and then s2: >=20 > hc: ClientHello(rseq:0, hseq: 0) > s1: HelloVerifyRequest(rseq:0, hseq:0) > lc: ClientHello(rseq:0, hseq: 0) > s1: HelloVerifyRequest(rseq:1, hseq:0) > lc: ClientHelloCookie(rseq:1, hseq: 1) > s1 will be connected to lc, now s2 listens > s1: ServerHello(rseq:2, hseq:1) > hc: ClientHelloCookie(rseq:1, hseq: 1) > s2 will be connected to hc, now s3 listens > s1: ServerHello(rseq:0, hseq:1) >=20 > So the more ClientHellos arrive before one with a valid cookie, the = higher is the record sequence number. That's the only "state" in the = server that changes. Otherwise I would have to maintain the record = sequence per client which would require resource allocation or always = use the same with the retransmission issues Nikos pointed out. I would prefer if different clients would not affect each other. Why = can't you just reflect the record sequence number? Then there is no need to store it = per client. Best regards Michael >=20 > Regards, > Robin >=20 >> Best regards >> Michael >>>=20 >>> This is because I'm using an SSL object (and its rec seq counter) = for listening, which will be assigned to the first client with a valid = cookie to continue the connection, so the next handshake message, that = is the ServerHello, will habe the next record seq. A new SSL object = (with reset counters) is then created to continue listening and = responding to ClientHellos. >>>=20 >>> Best reagards, >>> Robin >>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>>> Regards, >>>>>> Robin >>>>>>=20 >>>>>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) = ------> >>>>>>>>>=20 >>>>>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>>>>=20 >>>>>>>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong cookie) >>>>>>>>>=20 >>>>>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied = from >>>>>>>>> clienthello] >>>>>>>>>=20 >>>>>>>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong cookie) >>>>>>>>>=20 >>>>>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied = from >>>>>>>>> clienthello] >>>>>>>>>=20 >>>>>>>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>>>>>>=20 >>>>>>>>> [server allocates session and continues handshake] >>>>>>>> That may be helpful, but in my opinion "must not change its = state" >>>>>>>> includes not changing any sequence numbers. >>>>>>>=20 >>>>>>> What is of most concern is the record_seq. A client would just = discard >>>>>>> packets with the same sequence number. >>>>>>>=20 >>>>>>> regards, >>>>>>> Nikos >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>=20 >>>=20 >=20 >=20 From n.mavrogiannopoulos@gmail.com Mon Mar 14 13:29:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17263A6AAA; Mon, 14 Mar 2011 13:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3si8ZY6o9ICz; Mon, 14 Mar 2011 13:29:43 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 81BE93A6A6D; Mon, 14 Mar 2011 13:29:42 -0700 (PDT) Received: by bwz13 with SMTP id 13so5399878bwz.31 for ; Mon, 14 Mar 2011 13:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=c9h3fdP0WknkXBIdhccubo1clf0LqLx3L9NC9xpT5IY=; b=YHW+DitnpYOjvqeCVv/GdHu7XsxU40O2JzBqLG4IQi3+AIgcVqybjzWtYJ8wtcNCDq q15h8hKmrka8Crd8NRwBRLwrXoa+0DKTl+NJRRtTbuGsywb/4NLRkukAb0DwS5V/9pY8 twhdJg9EqFXmeBV4rp0iMDjhiakvZe5jEHEb4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=kFe4DKC7T80HsUYEl/9o9B1mUZeur94/bB4c+X835fFsYLrjYmmFxv0Wb43mABl+Ot cWw/nd5JT2/IkyTew2OZhhsclJh6n14+2TzwhTpJZ23wmybvN9KtasrCuTJ+D8Xfqg2u DbgexAGv2wxv1O+5SBMZPyM2Hg8J9NmjKtps4= Received: by 10.204.174.193 with SMTP id u1mr3083260bkz.26.1300134653077; Mon, 14 Mar 2011 13:30:53 -0700 (PDT) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id v21sm5460546bkt.23.2011.03.14.13.30.50 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 13:30:51 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D7E7AF9.7070409@gnutls.org> Date: Mon, 14 Mar 2011 21:30:49 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: mrex@sap.com References: <201103141728.p2EHSXl3019185@fs4113.wdf.sap.corp> In-Reply-To: <201103141728.p2EHSXl3019185@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, ietf@ietf.org, kent@bbn.com Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:29:46 -0000 On 03/14/2011 06:28 PM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: >> >> This sounds pretty awkward decision because HMAC per record is full >> (e.g. 160-bits on SHA-1), but the MAC on the handshake message >> "signature" is truncated to 96-bits. Why wasn't the record MAC >> truncated as well? In any case saving few bytes per handshake >> is much less of value than saving few bytes per record. Was >> there any other rationale for truncation? > > Are you wondering why the HMAC on the TLS data records is is sent > in its full beauty, while the TLS Finished.verify_data is a > truncated output of the PRF (which in the abstract definintion > uses HMAC as the outermost function, but in the case of TLSv1.0 > is actually the XOR of two different HMACs over half the secret). > The reason might be about the "secret" input to the HMAC, which in > case of the TLS data records is a derived traffic key, while in > case of the Finished.verify_data, is the "master secret" of the session. > > That was, what I assume, the fear, based on the second part of this > message from Dan Simon > http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html > and the second part of this message from Hugo Krawczyk > http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html > Since the TLSv1.0 finished message was defined based on the output > of the TLS PRF (a function with indefinite output length), > defining a truncation was inevitable. :) Indeed. It seems the messages you list summarize that design decision in a nice way. The concerns for the one-wayness of the MAC used lead to that truncation. That way one-wayness is ensured by discarding data at the cost of having a weaker MAC. I don't know if the current construction can be extended for a longer size without implications. regards, Nikos From mrex@sap.com Mon Mar 14 15:48:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C73B3A6BEE; Mon, 14 Mar 2011 15:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oZmcwpEYRPt; Mon, 14 Mar 2011 15:48:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CB0803A6BED; Mon, 14 Mar 2011 15:48:26 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2EMnGQm000883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Mar 2011 23:49:16 +0100 (MET) From: Martin Rex Message-Id: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Mar 2011 23:49:15 +0100 (MET) In-Reply-To: <4D7E7AF9.7070409@gnutls.org> from "Nikos Mavrogiannopoulos" at Mar 14, 11 09:30:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ietf@ietf.org, kent@bbn.com Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:48:28 -0000 Nikos Mavrogiannopoulos wrote: > > On 03/14/2011 06:28 PM, Martin Rex wrote: > > > > That was, what I assume, the fear, based on the second part of this > > message from Dan Simon > > http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html > > and the second part of this message from Hugo Krawczyk > > http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html > > > > Since the TLSv1.0 finished message was defined based on the output > > of the TLS PRF (a function with indefinite output length), > > defining a truncation was inevitable. :) > > Indeed. It seems the messages you list summarize that design decision > in a nice way. The concerns for the one-wayness of the MAC used lead > to that truncation. That way one-wayness is ensured by discarding data > at the cost of having a weaker MAC. I don't know if the current > construction can be extended for a longer size without implications. The concern with the one-wayness of the hashes was about >SSLv3< and how it computed its Finished message: enum { client(0x434C4E54), server(0x53525652) } Sender; struct { opaque md5_hash[16]; opaque sha_hash[20]; } Finished; md5_hash MD5(master_secret + pad2 + MD5(handshake_messages + Sender + master_secret + pad1)); sha_hash SHA(master_secret + pad2 + SHA(handshake_messages + Sender + master_secret + pad1)); handshake_messages All of the data from all handshake messages up to but not including this message. This is only data visible at the handshake layer and does not include record layer headers. Personally, I'm having difficulties to see how exactly it would leak the master_secret if MD5 was found to be fully invertable. The MD5 output is 128 bits = 16 bytes, and the input is *MUCH* larger than 128 bits. The master_secret should is 48 bytes alone. Even if one is successful at inverting MD5, one can not undo the collisions from the Finished computation caused by the compression of a much larger input into a 128 bit output value. Anyhow, I do see the new Finished computation algorithm in TLSv1.0 as a sensible change in the TLS design. -Martin From ekr@rtfm.com Mon Mar 14 16:26:20 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00303A6B8B for ; Mon, 14 Mar 2011 16:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlFNPwYm5ani for ; Mon, 14 Mar 2011 16:26:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2C9143A6B5F for ; Mon, 14 Mar 2011 16:26:17 -0700 (PDT) Received: by iwl42 with SMTP id 42so46305iwl.31 for ; Mon, 14 Mar 2011 16:27:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.75.196 with SMTP id b4mr4450852ick.372.1300145260713; Mon, 14 Mar 2011 16:27:40 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Mon, 14 Mar 2011 16:27:40 -0700 (PDT) In-Reply-To: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> Date: Mon, 14 Mar 2011 16:27:40 -0700 Message-ID: From: Eric Rescorla To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:26:20 -0000 FWIW, I believe the correct answer is that the server should always use sequence number 0 for HelloVerifyRequest, and that clients should not do duplicate suppression during the initial handshake. I agree it's a tiny bit clunky, but IMO it's the best option. -Ekr On Mon, Mar 14, 2011 at 12:42 PM, Michael T=FCxen wrote: > On Mar 14, 2011, at 8:26 PM, Robin Seggelmann wrote: >> >> On 14.03.2011, at 20:13, Michael T=FCxen wrote: >> >>> On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote: >>>> >>>> On 14.03.2011, at 19:01, Michael T=FCxen wrote: >>>> >>>>> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>>>>> >>>>>> >>>>>> On 14.03.2011, at 16:52, Robin Seggelmann wrote: >>>>>> >>>>>>> >>>>>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>>>>> >>>>>>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>>>>> >>>>>>>>>> Hello, I've been reading the section "Denial of Service >>>>>>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>>>>>> expected to operate before allocating state for the session to >>>>>>>>>> discard requests from clients with forged addresses. >>>>>>>>>> >>>>>>>>>> Some comments: 1. The document says: If a server receives a >>>>>>>>>> ClientHello with an invalid cookie, it SHOULD treat it the same = as >>>>>>>>>> a ClientHello with no cookie. >>>>>>>>>> >>>>>>>>>> What does it mean with regards to the handshake sequence. Does t= he >>>>>>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>>>>> >>>>>>>>> The second HelloVerifyRequest should have seq=3D0 again, since th= e >>>>>>>>> server must not change its state. That's how I implemented it in >>>>>>>>> OpenSSL. =A0The server does not change any sequence numbers until= a >>>>>>>>> cookie has been verified and the regular handshake continues. >>>>>>>> >>>>>>>> What about the record_seq. Is it also 0? If yes =A0a client >>>>>>>> would see this record packet as a replay and discard it. If no >>>>>>>> it seems you have to keep state... >>>>>>> >>>>>>> The record_seq is still increased, because it has to be unique. I w= ouldn't consider this as a problem because it's just a counter you're incre= asing. There is no resource allocation necessary and there is no benefit fo= r an attacker to send many ClientHellos to increase the sequence number. It= 's only used for HMAC verification and replay check and will be reset to 0 = after the ChangCipherSpec anyway. >>>>>>> >>>>>>> However, I see your point. Maybe the document should state more exp= licitly that handshake sequence numbers must not be increased, because they= always have to be the same and always have to start with 0, while the reco= rd_seq has to be unique and therefore has to change. >>>>>> >>>>>> I forgot to mention that in OpenSSL I'm using the same record_seq co= unter for every incoming request until a CH with a valid cookie arrives. Th= is is due to a workaround to implement an UDP based and thus one-to-many st= yle protocol in OpenSSL's one-to-one architecture, but so I'm not required = to allocate anything. >>>>> Hi Robin, >>>>> >>>>> can you be more specific? Did you implement it such that Nikos >>>>> message exchange is valid? So do you copy the rec. seq. number >>>>> from the incoming packet? Do you use the same counter for multiple >>>>> client until you receive a CH with a valid cookie? >>>> >>>> I don't copy the record sequence. The server is using one counter for = multiple clients until the CH with a valid cookie. So the first HelloVerify= Request has record seq 0, the second 1 and so on. When a cookie has been ve= rified, the ServerHello will have the next record seq, while the next Hello= VerifyRequest for an other client will have 0 again. >>> So does this mean that one client affects the other? >> >> Only by increasing the record sequence. As an example, a scenario with a= low RTT client (lc), a high RTT (hc) client, the server listening with SSL= object s1 and then s2: >> >> hc: ClientHello(rseq:0, hseq: 0) >> s1: HelloVerifyRequest(rseq:0, hseq:0) >> lc: ClientHello(rseq:0, hseq: 0) >> s1: HelloVerifyRequest(rseq:1, hseq:0) >> lc: ClientHelloCookie(rseq:1, hseq: 1) >> s1 will be connected to lc, now s2 listens >> s1: ServerHello(rseq:2, hseq:1) >> hc: ClientHelloCookie(rseq:1, hseq: 1) >> s2 will be connected to hc, now s3 listens >> s1: ServerHello(rseq:0, hseq:1) >> >> So the more ClientHellos arrive before one with a valid cookie, the high= er is the record sequence number. That's the only "state" in the server tha= t changes. Otherwise I would have to maintain the record sequence per clien= t which would require resource allocation or always use the same with the r= etransmission issues Nikos pointed out. > I would prefer if different clients would not affect each other. Why can'= t you just > reflect the record sequence number? Then there is no need to store it per= client. > > Best regards > Michael >> >> Regards, >> Robin >> >>> Best regards >>> Michael >>>> >>>> This is because I'm using an SSL object (and its rec seq counter) for = listening, which will be assigned to the first client with a valid cookie t= o continue the connection, so the next handshake message, that is the Serve= rHello, will habe the next record seq. A new SSL object (with reset counter= s) is then created to continue listening and responding to ClientHellos. >>>> >>>> Best reagards, >>>> Robin >>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>>> Regards, >>>>>>> Robin >>>>>>> >>>>>>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) =A0-----= -> >>>>>>>>>> >>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>>>>> >>>>>>>>>> ClientHello (record_seq=3D1, seq=3D1) =A0------> (wrong cookie) >>>>>>>>>> >>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied fro= m >>>>>>>>>> clienthello] >>>>>>>>>> >>>>>>>>>> ClientHello (record_seq=3D2, seq=3D2) =A0------> (wrong cookie) >>>>>>>>>> >>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied fro= m >>>>>>>>>> clienthello] >>>>>>>>>> >>>>>>>>>> ClientHello (record_seq=3D3, seq=3D3) =A0------> >>>>>>>>>> >>>>>>>>>> [server allocates session and continues handshake] >>>>>>>>> That may be helpful, but in my opinion "must not change its state= " >>>>>>>>> includes not changing any sequence numbers. >>>>>>>> >>>>>>>> What is of most concern is the record_seq. A client would just dis= card >>>>>>>> packets with the same sequence number. >>>>>>>> >>>>>>>> regards, >>>>>>>> Nikos >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 Michael.Tuexen@lurchi.franken.de Mon Mar 14 16:32:55 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DAC93A6F05 for ; Mon, 14 Mar 2011 16:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEfy4s1EHzkh for ; Mon, 14 Mar 2011 16:32:54 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 2BAD53A6EE3 for ; Mon, 14 Mar 2011 16:32:52 -0700 (PDT) Received: from [192.168.1.113] (p5481DBED.dip.t-dialin.net [84.129.219.237]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EEEA41C0C0BD8; Tue, 15 Mar 2011 00:34:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 15 Mar 2011 00:34:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:32:55 -0000 On Mar 15, 2011, at 12:27 AM, Eric Rescorla wrote: > FWIW, I believe the correct answer is that the server should always = use > sequence number 0 for HelloVerifyRequest, and that clients should not = do > duplicate suppression during the initial handshake. I agree it's a > tiny bit clunky, > but IMO it's the best option. Hmmm. I'm not a big fan of adding special cases. Another possibility would be reflecting them. But whatever we use, it needs to be specified. Best regards Michael >=20 > -Ekr >=20 >=20 > On Mon, Mar 14, 2011 at 12:42 PM, Michael T=FCxen > wrote: >> On Mar 14, 2011, at 8:26 PM, Robin Seggelmann wrote: >>>=20 >>> On 14.03.2011, at 20:13, Michael T=FCxen wrote: >>>=20 >>>> On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote: >>>>>=20 >>>>> On 14.03.2011, at 19:01, Michael T=FCxen wrote: >>>>>=20 >>>>>> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 14.03.2011, at 16:52, Robin Seggelmann = wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>>>>>>=20 >>>>>>>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>>>>>>=20 >>>>>>>>>>> Hello, I've been reading the section "Denial of Service >>>>>>>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>>>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>>>>>>> expected to operate before allocating state for the session = to >>>>>>>>>>> discard requests from clients with forged addresses. >>>>>>>>>>>=20 >>>>>>>>>>> Some comments: 1. The document says: If a server receives a >>>>>>>>>>> ClientHello with an invalid cookie, it SHOULD treat it the = same as >>>>>>>>>>> a ClientHello with no cookie. >>>>>>>>>>>=20 >>>>>>>>>>> What does it mean with regards to the handshake sequence. = Does the >>>>>>>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>>>>>>=20 >>>>>>>>>> The second HelloVerifyRequest should have seq=3D0 again, = since the >>>>>>>>>> server must not change its state. That's how I implemented it = in >>>>>>>>>> OpenSSL. The server does not change any sequence numbers = until a >>>>>>>>>> cookie has been verified and the regular handshake continues. >>>>>>>>>=20 >>>>>>>>> What about the record_seq. Is it also 0? If yes a client >>>>>>>>> would see this record packet as a replay and discard it. If no >>>>>>>>> it seems you have to keep state... >>>>>>>>=20 >>>>>>>> The record_seq is still increased, because it has to be unique. = I wouldn't consider this as a problem because it's just a counter you're = increasing. There is no resource allocation necessary and there is no = benefit for an attacker to send many ClientHellos to increase the = sequence number. It's only used for HMAC verification and replay check = and will be reset to 0 after the ChangCipherSpec anyway. >>>>>>>>=20 >>>>>>>> However, I see your point. Maybe the document should state more = explicitly that handshake sequence numbers must not be increased, = because they always have to be the same and always have to start with 0, = while the record_seq has to be unique and therefore has to change. >>>>>>>=20 >>>>>>> I forgot to mention that in OpenSSL I'm using the same = record_seq counter for every incoming request until a CH with a valid = cookie arrives. This is due to a workaround to implement an UDP based = and thus one-to-many style protocol in OpenSSL's one-to-one = architecture, but so I'm not required to allocate anything. >>>>>> Hi Robin, >>>>>>=20 >>>>>> can you be more specific? Did you implement it such that Nikos >>>>>> message exchange is valid? So do you copy the rec. seq. number >>>>>> from the incoming packet? Do you use the same counter for = multiple >>>>>> client until you receive a CH with a valid cookie? >>>>>=20 >>>>> I don't copy the record sequence. The server is using one counter = for multiple clients until the CH with a valid cookie. So the first = HelloVerifyRequest has record seq 0, the second 1 and so on. When a = cookie has been verified, the ServerHello will have the next record seq, = while the next HelloVerifyRequest for an other client will have 0 again. >>>> So does this mean that one client affects the other? >>>=20 >>> Only by increasing the record sequence. As an example, a scenario = with a low RTT client (lc), a high RTT (hc) client, the server listening = with SSL object s1 and then s2: >>>=20 >>> hc: ClientHello(rseq:0, hseq: 0) >>> s1: HelloVerifyRequest(rseq:0, hseq:0) >>> lc: ClientHello(rseq:0, hseq: 0) >>> s1: HelloVerifyRequest(rseq:1, hseq:0) >>> lc: ClientHelloCookie(rseq:1, hseq: 1) >>> s1 will be connected to lc, now s2 listens >>> s1: ServerHello(rseq:2, hseq:1) >>> hc: ClientHelloCookie(rseq:1, hseq: 1) >>> s2 will be connected to hc, now s3 listens >>> s1: ServerHello(rseq:0, hseq:1) >>>=20 >>> So the more ClientHellos arrive before one with a valid cookie, the = higher is the record sequence number. That's the only "state" in the = server that changes. Otherwise I would have to maintain the record = sequence per client which would require resource allocation or always = use the same with the retransmission issues Nikos pointed out. >> I would prefer if different clients would not affect each other. Why = can't you just >> reflect the record sequence number? Then there is no need to store it = per client. >>=20 >> Best regards >> Michael >>>=20 >>> Regards, >>> Robin >>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> This is because I'm using an SSL object (and its rec seq counter) = for listening, which will be assigned to the first client with a valid = cookie to continue the connection, so the next handshake message, that = is the ServerHello, will habe the next record seq. A new SSL object = (with reset counters) is then created to continue listening and = responding to ClientHellos. >>>>>=20 >>>>> Best reagards, >>>>> Robin >>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Robin >>>>>>>>=20 >>>>>>>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) = ------> >>>>>>>>>>>=20 >>>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>>>>>>=20 >>>>>>>>>>> ClientHello (record_seq=3D1, seq=3D1) ------> (wrong = cookie) >>>>>>>>>>>=20 >>>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied = from >>>>>>>>>>> clienthello] >>>>>>>>>>>=20 >>>>>>>>>>> ClientHello (record_seq=3D2, seq=3D2) ------> (wrong = cookie) >>>>>>>>>>>=20 >>>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied = from >>>>>>>>>>> clienthello] >>>>>>>>>>>=20 >>>>>>>>>>> ClientHello (record_seq=3D3, seq=3D3) ------> >>>>>>>>>>>=20 >>>>>>>>>>> [server allocates session and continues handshake] >>>>>>>>>> That may be helpful, but in my opinion "must not change its = state" >>>>>>>>>> includes not changing any sequence numbers. >>>>>>>>>=20 >>>>>>>>> What is of most concern is the record_seq. A client would just = discard >>>>>>>>> packets with the same sequence number. >>>>>>>>>=20 >>>>>>>>> regards, >>>>>>>>> Nikos >>>>>>>>=20 >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> TLS mailing list >>>>>>> TLS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 From ekr@rtfm.com Mon Mar 14 16:36:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810653A701B for ; Mon, 14 Mar 2011 16:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.784 X-Spam-Level: X-Spam-Status: No, score=-102.784 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1njjd-NYicRe for ; Mon, 14 Mar 2011 16:36:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E6C6D3A7058 for ; Mon, 14 Mar 2011 16:36:10 -0700 (PDT) Received: by iyi12 with SMTP id 12so48186iyi.31 for ; Mon, 14 Mar 2011 16:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.215.19 with SMTP id hc19mr155327icb.238.1300145854991; Mon, 14 Mar 2011 16:37:34 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Mon, 14 Mar 2011 16:37:34 -0700 (PDT) In-Reply-To: <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> Date: Mon, 14 Mar 2011 16:37:34 -0700 Message-ID: From: Eric Rescorla To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:36:14 -0000 I suspect either reflecting or the special case would work. I'm trying to get all the other changes in before the deadline so I'll leave it with =3D0 and the special case and an open issue marker and let's just resolve in Prague. -Ekr On Mon, Mar 14, 2011 at 4:34 PM, Michael T=FCxen wrote: > On Mar 15, 2011, at 12:27 AM, Eric Rescorla wrote: > >> FWIW, I believe the correct answer is that the server should always use >> sequence number 0 for HelloVerifyRequest, and that clients should not do >> duplicate suppression during the initial handshake. I agree it's a >> tiny bit clunky, >> but IMO it's the best option. > Hmmm. I'm not a big fan of adding special cases. Another possibility > would be reflecting them. But whatever we use, it needs to be > specified. > > Best regards > Michael >> >> -Ekr >> >> >> On Mon, Mar 14, 2011 at 12:42 PM, Michael T=FCxen >> wrote: >>> On Mar 14, 2011, at 8:26 PM, Robin Seggelmann wrote: >>>> >>>> On 14.03.2011, at 20:13, Michael T=FCxen wrote: >>>> >>>>> On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote: >>>>>> >>>>>> On 14.03.2011, at 19:01, Michael T=FCxen wrote: >>>>>> >>>>>>> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 14.03.2011, at 16:52, Robin Seggelmann wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote: >>>>>>>>> >>>>>>>>>> On 03/14/2011 04:12 PM, Robin Seggelmann wrote: >>>>>>>>>> >>>>>>>>>>>> Hello, I've been reading the section "Denial of Service >>>>>>>>>>>> Countermeasures" of DTLS and as I understand it the proposed >>>>>>>>>>>> subsystem (client-hello and client-hello-verify-request) is >>>>>>>>>>>> expected to operate before allocating state for the session to >>>>>>>>>>>> discard requests from clients with forged addresses. >>>>>>>>>>>> >>>>>>>>>>>> Some comments: 1. The document says: If a server receives a >>>>>>>>>>>> ClientHello with an invalid cookie, it SHOULD treat it the sam= e as >>>>>>>>>>>> a ClientHello with no cookie. >>>>>>>>>>>> >>>>>>>>>>>> What does it mean with regards to the handshake sequence. Does= the >>>>>>>>>>>> second HelloVerifyRequest has seq=3D0 or seq=3D1? >>>>>>>>>>> >>>>>>>>>>> The second HelloVerifyRequest should have seq=3D0 again, since = the >>>>>>>>>>> server must not change its state. That's how I implemented it i= n >>>>>>>>>>> OpenSSL. =A0The server does not change any sequence numbers unt= il a >>>>>>>>>>> cookie has been verified and the regular handshake continues. >>>>>>>>>> >>>>>>>>>> What about the record_seq. Is it also 0? If yes =A0a client >>>>>>>>>> would see this record packet as a replay and discard it. If no >>>>>>>>>> it seems you have to keep state... >>>>>>>>> >>>>>>>>> The record_seq is still increased, because it has to be unique. I= wouldn't consider this as a problem because it's just a counter you're inc= reasing. There is no resource allocation necessary and there is no benefit = for an attacker to send many ClientHellos to increase the sequence number. = It's only used for HMAC verification and replay check and will be reset to = 0 after the ChangCipherSpec anyway. >>>>>>>>> >>>>>>>>> However, I see your point. Maybe the document should state more e= xplicitly that handshake sequence numbers must not be increased, because th= ey always have to be the same and always have to start with 0, while the re= cord_seq has to be unique and therefore has to change. >>>>>>>> >>>>>>>> I forgot to mention that in OpenSSL I'm using the same record_seq = counter for every incoming request until a CH with a valid cookie arrives. = This is due to a workaround to implement an UDP based and thus one-to-many = style protocol in OpenSSL's one-to-one architecture, but so I'm not require= d to allocate anything. >>>>>>> Hi Robin, >>>>>>> >>>>>>> can you be more specific? Did you implement it such that Nikos >>>>>>> message exchange is valid? So do you copy the rec. seq. number >>>>>>> from the incoming packet? Do you use the same counter for multiple >>>>>>> client until you receive a CH with a valid cookie? >>>>>> >>>>>> I don't copy the record sequence. The server is using one counter fo= r multiple clients until the CH with a valid cookie. So the first HelloVeri= fyRequest has record seq 0, the second 1 and so on. When a cookie has been = verified, the ServerHello will have the next record seq, while the next Hel= loVerifyRequest for an other client will have 0 again. >>>>> So does this mean that one client affects the other? >>>> >>>> Only by increasing the record sequence. As an example, a scenario with= a low RTT client (lc), a high RTT (hc) client, the server listening with S= SL object s1 and then s2: >>>> >>>> hc: ClientHello(rseq:0, hseq: 0) >>>> s1: HelloVerifyRequest(rseq:0, hseq:0) >>>> lc: ClientHello(rseq:0, hseq: 0) >>>> s1: HelloVerifyRequest(rseq:1, hseq:0) >>>> lc: ClientHelloCookie(rseq:1, hseq: 1) >>>> s1 will be connected to lc, now s2 listens >>>> s1: ServerHello(rseq:2, hseq:1) >>>> hc: ClientHelloCookie(rseq:1, hseq: 1) >>>> s2 will be connected to hc, now s3 listens >>>> s1: ServerHello(rseq:0, hseq:1) >>>> >>>> So the more ClientHellos arrive before one with a valid cookie, the hi= gher is the record sequence number. That's the only "state" in the server t= hat changes. Otherwise I would have to maintain the record sequence per cli= ent which would require resource allocation or always use the same with the= retransmission issues Nikos pointed out. >>> I would prefer if different clients would not affect each other. Why ca= n't you just >>> reflect the record sequence number? Then there is no need to store it p= er client. >>> >>> Best regards >>> Michael >>>> >>>> Regards, >>>> Robin >>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>> This is because I'm using an SSL object (and its rec seq counter) fo= r listening, which will be assigned to the first client with a valid cookie= to continue the connection, so the next handshake message, that is the Ser= verHello, will habe the next record seq. A new SSL object (with reset count= ers) is then created to continue listening and responding to ClientHellos. >>>>>> >>>>>> Best reagards, >>>>>> Robin >>>>>> >>>>>>> Best regards >>>>>>> Michael >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Robin >>>>>>>>> >>>>>>>>>>>> e.g. if I receive ClientHello (record_seq=3D0, seq=3D0) =A0---= ---> >>>>>>>>>>>> >>>>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D0, seq=3D0) >>>>>>>>>>>> >>>>>>>>>>>> ClientHello (record_seq=3D1, seq=3D1) =A0------> (wrong cookie= ) >>>>>>>>>>>> >>>>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D1, seq=3D1) [seq copied f= rom >>>>>>>>>>>> clienthello] >>>>>>>>>>>> >>>>>>>>>>>> ClientHello (record_seq=3D2, seq=3D2) =A0------> (wrong cookie= ) >>>>>>>>>>>> >>>>>>>>>>>> <-- HelloVerifyRequest (record_seq=3D2, seq=3D2) [seq copied f= rom >>>>>>>>>>>> clienthello] >>>>>>>>>>>> >>>>>>>>>>>> ClientHello (record_seq=3D3, seq=3D3) =A0------> >>>>>>>>>>>> >>>>>>>>>>>> [server allocates session and continues handshake] >>>>>>>>>>> That may be helpful, but in my opinion "must not change its sta= te" >>>>>>>>>>> includes not changing any sequence numbers. >>>>>>>>>> >>>>>>>>>> What is of most concern is the record_seq. A client would just d= iscard >>>>>>>>>> packets with the same sequence number. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Nikos >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 marsh@extendedsubset.com Mon Mar 14 16:52:09 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84BC3A6E40; Mon, 14 Mar 2011 16:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddH-JGl7r2vN; Mon, 14 Mar 2011 16:52:09 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id ECF993A6B8B; Mon, 14 Mar 2011 16:52:08 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PzHGs-00010F-0Q; Mon, 14 Mar 2011 23:33:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 31AD9606B; Mon, 14 Mar 2011 23:53:14 +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: U2FsdGVkX18M6nvtk7miJj1ZADN2pkcAhYYpWVJpNTI= Message-ID: <4D7EAA67.70702@extendedsubset.com> Date: Mon, 14 Mar 2011 18:53:11 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: mrex@sap.com References: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp> In-Reply-To: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kent@bbn.com, tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:52:09 -0000 On 03/14/2011 05:49 PM, Martin Rex wrote: > > The MD5 output is 128 bits = 16 bytes, and the input is *MUCH* larger > than 128 bits. The master_secret should is 48 bytes alone. Even if one is > successful at inverting MD5, one can not undo the collisions from > the Finished computation caused by the compression of a much larger > input into a 128 bit output value. You could accumulate multiple samples, perhaps even with session resumption where the Finished message is sent by the server without the chance to authenticate the client first. Normally you even don't get to see the Finished.verify_data without breaking the encryption or downgrading to no encryption. But 40-bit encryption and "integrity only" connections were fully supported use cases back in those days. If they had really wanted to leverage the 16 or 20 byte bottleneck of MD5 and SHA-1, they should have padded the master_secret from 384 to 512 bits (the input block size) before putting it into the hash function. - Marsh From Internet-Drafts@ietf.org Mon Mar 14 17:15:04 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7323A6E74; Mon, 14 Mar 2011 17:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJvxOADjHmrs; Mon, 14 Mar 2011 17:15:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65133A6DB5; Mon, 14 Mar 2011 17:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110315001501.29845.6725.idtracker@localhost> Date: Mon, 14 Mar 2011 17:15:01 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-rfc4347-bis-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 00:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Datagram Transport Layer Security version 1.2 Author(s) : E. Rescorla, N. Modadugu Filename : draft-ietf-tls-rfc4347-bis-05.txt Pages : 32 Date : 2011-03-14 This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-rfc4347-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14170539.I-D@ietf.org> --NextPart-- From n.mavrogiannopoulos@gmail.com Tue Mar 15 02:36:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606373A6C19 for ; Tue, 15 Mar 2011 02:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KSLbyEdb1-i for ; Tue, 15 Mar 2011 02:36:54 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 586793A6C0D for ; Tue, 15 Mar 2011 02:36:54 -0700 (PDT) Received: by qyk7 with SMTP id 7so301118qyk.10 for ; Tue, 15 Mar 2011 02:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/L9FXRx+x+BaLADiQtXPS3XmM9aS9qa6g4oOluLNOj4=; b=o7SM5KIJjk7Sue2UDTApWrIBaw8WMtvmiNv527AWS15yX0nz5QGlnpfOZkq+jT9GdL B/7kHAyT5hU8Q4pwqomccYKQC76sdy24j8xlg3t0FUUwebvfCiSbfWjAnO7eQHEi2ysl mXzMl/mOMS0hjrYnvAE5w0nxpV6/vbYcPHzic= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=UruwJPpdCkwKP9CXX+dA6w/7XQX9gOIF/VF39wqoDMa8U29D2V9YWkBgXVDUAxytTG nd93QLNWb49OW2P6R04i/dG0pVLNnqzAhrq7+SgNekn5sfFd48/21HEyo7aWwxb3LOOK u+y6GE7+jTASFRNmK57R6OJco0B7/2gwKZR+A= MIME-Version: 1.0 Received: by 10.229.111.194 with SMTP id t2mr10923227qcp.48.1300181898723; Tue, 15 Mar 2011 02:38:18 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 02:38:18 -0700 (PDT) In-Reply-To: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> Date: Tue, 15 Mar 2011 10:38:18 +0100 X-Google-Sender-Auth: VVYL-ZvvP-pIWX26pgAPJL50Cps Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 09:36:57 -0000 On Tue, Mar 15, 2011 at 12:27 AM, Eric Rescorla wrote: > FWIW, I believe the correct answer is that the server should always use > sequence number 0 for HelloVerifyRequest, and that clients should not do > duplicate suppression during the initial handshake. I agree it's a > tiny bit clunky, > but IMO it's the best option. I can see that using handshake_seq of 0 for HelloVerifyRequest is a good option, but using 0 for record_seq requires a special handling of those records and thus extra complexity. The reflection method has no requirements from the record layer, thus I'd prefer that unless there are implications of course. regards, Nikos From n.mavrogiannopoulos@gmail.com Tue Mar 15 03:01:39 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E453A6C6E for ; Tue, 15 Mar 2011 03:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsyrEEv5wEDO for ; Tue, 15 Mar 2011 03:01:39 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id F11AA3A69E3 for ; Tue, 15 Mar 2011 03:01:38 -0700 (PDT) Received: by qyk7 with SMTP id 7so316617qyk.10 for ; Tue, 15 Mar 2011 03:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SH+NaW7i+XfMFrBuXRG8Ieffdsa+ArdN0hqjCGMIx4U=; b=cUXj1naHBfQwiHD45X4CJOJNcIuUk+C4V/uPVbsFUuIWWAmvnXiEFJ+uKBVtsbPE96 jUtNk+utLAEUKIY1OWCDzKr389ljm1eX2Pk1hoC55ft2hRT9g3412JY3szAyXzCSs0mW gP2jFbQ9QrcKDbCCKaiz1/0uFOdyNxVQ2RVGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=KdvpuJWnYTI9apYOjPfet40c7+uaAE71V0IYbxErBKN0TENksJcOfoua3PCipt+smL mSHdgiDTJqYNVKjZoArDmj4DjN3nBFIO2ZxtbK6FvMKZCsWOItifxWYwTUnPVeRplalS A3O8/hXvTCz4ZAbzLlGEwNBfT/ewSLmQ9UzOA= MIME-Version: 1.0 Received: by 10.229.122.131 with SMTP id l3mr4058067qcr.124.1300183168427; Tue, 15 Mar 2011 02:59:28 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 02:59:28 -0700 (PDT) In-Reply-To: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> Date: Tue, 15 Mar 2011 10:59:28 +0100 X-Google-Sender-Auth: P0f5TRFs_FWdhnAy_nkPOg1P2Pw Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 10:01:39 -0000 On Tue, Mar 15, 2011 at 12:37 AM, Eric Rescorla wrote: > I suspect either reflecting or the special case would work. I'm trying > to get all the other > changes in before the deadline so I'll leave it with =0 and the > special case and an > open issue marker and let's just resolve in Prague. I will not be there but I'd like to make these points: 1. Define precisely the behavior of initial pre-handshake before state is allocated. My opinion is that I don't like special cases such as use 0 always and do not case about re-use because they are more likely to introduce bugs and new attacks. Copying the client's numbers should solve the issue with no special cases and no state. Also I suppose that if handshake_seq=0 is used for HelloVerifyRequest then handshake_seq=1 should be used for ServerHello and this should be clear as well to avoid having another special case. 2. Drop requirement: The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. Upon receipt of the ServerHello, the client MUST verify that the server version values match. This will create incompatibilities when more than 1 DTLS protocols are implemented in a single client or server. It is not really possible for a server to do an emulation of the decisions it would do as if a state existed. What are the reasons for this requirement? regards, Nikos From ekr@rtfm.com Tue Mar 15 04:17:16 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E813A6B07 for ; Tue, 15 Mar 2011 04:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObMes7EIJrzy for ; Tue, 15 Mar 2011 04:17:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 2A3BC3A68BF for ; Tue, 15 Mar 2011 04:17:15 -0700 (PDT) Received: by yxk30 with SMTP id 30so235429yxk.31 for ; Tue, 15 Mar 2011 04:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.96.6 with SMTP id y6mr4512667agl.150.1300187919803; Tue, 15 Mar 2011 04:18:39 -0700 (PDT) Received: by 10.90.79.10 with HTTP; Tue, 15 Mar 2011 04:18:39 -0700 (PDT) In-Reply-To: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> Date: Tue, 15 Mar 2011 04:18:39 -0700 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:17:16 -0000 On Tue, Mar 15, 2011 at 2:59 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Mar 15, 2011 at 12:37 AM, Eric Rescorla wrote: >> I suspect either reflecting or the special case would work. I'm trying >> to get all the other >> changes in before the deadline so I'll leave it with =3D0 and the >> special case and an >> open issue marker and let's just resolve in Prague. > > I will not be there but I'd like to make these points: > 1. Define precisely the behavior of initial pre-handshake before state > is allocated. My opinion is that I don't like special cases such as > use 0 always > and do not case about re-use because they are more likely to introduce > bugs and new attacks. Copying the client's numbers should solve the > issue with no special cases and no state. Also I suppose that if > handshake_seq=3D0 is used for HelloVerifyRequest then handshake_seq=3D1 > should be used for ServerHello and this should be clear as well to > avoid having another special case. Noted. Let's see how that discussion shakes out in the meeting. > 2. Drop requirement: The server MUST use the same > =A0 version number in the HelloVerifyRequest that it would use when > =A0 sending a ServerHello. =A0Upon receipt of the ServerHello, the client > =A0 MUST verify that the server version values match. > This will create incompatibilities when more than 1 DTLS protocols are > implemented > in a single client or server. It is not really possible for a server > to do an emulation of > the decisions it would do as if a state existed. What are the reasons for= this > requirement? I don't understand why this is an issue: the server can remember what the client offered (indeed, he must remember a whole pile of other stuff in ord= er to verify that it hasn't changed) by stuffing a digest into the cookie. -Ekr From jorge@orchilles.com Tue Mar 15 04:30:11 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E52C3A6C7B for ; Tue, 15 Mar 2011 04:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eEPnTFfBi0N for ; Tue, 15 Mar 2011 04:30:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4F8363A6B3A for ; Tue, 15 Mar 2011 04:30:09 -0700 (PDT) Received: by fxm15 with SMTP id 15so491653fxm.31 for ; Tue, 15 Mar 2011 04:31:33 -0700 (PDT) Received: by 10.223.75.196 with SMTP id z4mr1377721faj.83.1300188691842; Tue, 15 Mar 2011 04:31:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id n26sm365273fam.13.2011.03.15.04.31.30 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 04:31:31 -0700 (PDT) Received: by fxm15 with SMTP id 15so491608fxm.31 for ; Tue, 15 Mar 2011 04:31:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.61.18 with SMTP id r18mr1288312fah.140.1300188688497; Tue, 15 Mar 2011 04:31:28 -0700 (PDT) Received: by 10.223.124.10 with HTTP; Tue, 15 Mar 2011 04:31:28 -0700 (PDT) Date: Tue, 15 Mar 2011 08:31:28 -0300 Message-ID: From: "Jorge A. Orchilles" To: tls@ietf.org Content-Type: multipart/alternative; boundary=0015173fef66eb3c8f049e83c4e1 Subject: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:30:11 -0000 --0015173fef66eb3c8f049e83c4e1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all, Marsh Ray has invited me to present my research and report on SSL/TLS Renegotiation Denial of Service on this mailing list. I have posted this on my site and will paste here for your feedback: http://orchilles.com/2011/03/ssl-renegotiation-dos.html *SSL/TLS Renegotiation Denial of Service* An SSL/TLS handshake requires at least 10 times more processing power on th= e server than on the client. The handshake is only performed at the beginning of a secure connection to establish it. When SSL/TLS Renegotiation is enabled on the server, a user is allowed to send a renegotiation request which initiates a new handshake. Since it takes much less resources for a client to perform a handshake, requesting multiple handshakes per second could cause a denial of service on the server side SSL/TLS interface. Therefore, if a malicious user on one host requests multiple renegotiation requests it will exhaust the server=92s resources and not allow any other u= ser to establish a connection. This attack is different than a Distributed Denial of Service (DDOS) as it does not require the volume, or botnet, to exhaust the network connection. Instead it exhausts the server resources from a single host requiring only = a single TCP/IP socket. A single server can perform between 150-300 handshakes per second. While a single client can request up to 1000 handshakes per second. A preventive measure to this issue would be to disable SSL/TLS Renegotiation. The vendor of your specific SSL Implementation should have documentation on disabling this =93feature.=94 Performing rate-limiting on = new incoming TLS connections AND renegotiations would also be a preventive method; most implementations only perform rate-limiting on new connections if at all. A mitigation would be to use an SSL Accelerator, although adding one or two more hosts to your attack would render it useless as well. Current DOS and DDOS detection and mitigation strategies will not work with this attack as the initial handshake is legit and the renegotiation request= s are made directly with the server after the network and application layer controls/filters. There are multiple ways to determine if SSL/TLS Renegotiation is enabled. N= asko Oskov site, Nessus has a plugin for it ,Qualys has a site to test for it , and you can do so manually with OpenSSL (thanks to Ivan Ristic ): - openssl s_client -connect ip:port - HEAD / HTTP/1.0 - R The Hackers Choice semi-silently released a proof of concept tool on February 28, 2011 at DC4420 that performs the described denial of service against servers that allow SSL/TLS Renegotiation. I recommend reading the source code before running it and ensure you have permission to run a denial of service attack against the target. To use the tool, I used BackTrack: - Download: wget http://www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz - Extract: tar -zvxf thc-ssl-1.4.tar.gz - View files and source: cd thc-ssl-dos/src - Edit the source: vim thc-ssl-dos.c - I recommend adding a 1 instead of 0 to the two flags required to run the program. You may also edit the max amount of connections. - Configure: cd .. Then: ./configure - Install: make all install - Run: cd src Then: ./thc-ssl-dos ip port - Options include: -l x where x is the number of connections, the defaul= t is 400. I have calculated this as a High risk issue using CVSS v2: 8.6 (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:P/RL:W/RC:C/CDP:ND/TD:ND/CR:H/IR:H/AR:H) I would like to thank all that provided feedback and peer review for this issue: Ron Gula and Tenable, Steve Dispensa, Nasko Oskov, Marsh Ray, and Kai Engert. Please leave a comment or use the contact form to provide feedback or request denial of service proof of concept testing on your site. Best Regards, Jorge Orchilles Best Regards, Jorge Orchilles --0015173fef66eb3c8f049e83c4e1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all,
Marsh Ray has inv= ited me to present my research and report on SSL/TLS Renegotiation Denial o= f Service on this mailing list. I have posted this on my site and will past= e here for=A0your feedback:

SSL/TLS Renegotiation Denial of Servic= e

An SSL/TLS handshake= requires at least 10 times more processing power on the server than on the= client. The handshake is only performed at the beginning of a secure conne= ction to establish it. When SSL/TLS Renegotiation is enabled on the server,= a user is allowed to send a renegotiation request which initiates a new ha= ndshake. Since it takes much less resources for a client to perform a hands= hake, requesting multiple handshakes per second could cause a denial of ser= vice on the server side SSL/TLS interface. Therefore, if a malicious user o= n one host requests multiple renegotiation requests it will exhaust the ser= ver=92s resources and not allow any other user to establish a connection.

This attack is different than= a Distributed Denial of Service (DDOS) as it does not require the volume, = or botnet, to exhaust the network connection. Instead it exhausts the serve= r resources from a single host requiring only a single TCP/IP socket. =A0A = single server can perform between 150-300 handshakes per second. While a si= ngle client can request up to 1000 handshakes per second.

A preventive measure to this = issue would be to disable SSL/TLS Renegotiation. The vendor of your specifi= c SSL Implementation should have documentation on disabling this =93feature= .=94 Performing=A0rate-limiting on new incoming TLS connections AND renegot= iations would also be a preventive method; most implementations only perfor= m rate-limiting on new connections if at all.=A0A mitigation would be to us= e an SSL Accelerator, although adding one or two more hosts to your attack = would render it useless as well. Current DOS and DDOS detection and mitigat= ion strategies will not work with this attack as the initial handshake is l= egit and the renegotiation requests are made directly with the server after= the network and application layer controls/filters.

There are multiple ways to de= termine if SSL/TLS Renegotiation is enabled.=A0Nasko Oskov=A0site,=A0Nessus has a plugin for it= ,Qualys has a site to test for it,=A0and you can do so manually with OpenSSL (thanks to=A0Ivan Ristic):

  • openssl s_client -connect ip:port
  • R

The Hackers Choice=A0semi-silently released a=A0<= a href=3D"http://www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz" target=3D"= _blank" style=3D"color: rgb(0, 0, 204); ">proof of concept tool=A0on=A0February=A028, 2011 at=A0DC4420=A0tha= t performs the described denial of service against servers that allow SSL/T= LS Renegotiation. I recommend reading the source code before running it and= ensure you have permission to run a denial of service attack against the t= arget. To use the tool, I used BackTrack:

  • Download: wget=A0http://ww= w.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz
  • Extract: tar -zvxf thc-ssl-1.4.tar.gz
  • View files and source: cd thc-ssl-dos/sr= c
  • Edit the source: vim thc-ssl-dos.c<= /li>
  • I recommend adding a 1 instead of 0 to th= e two flags required to run the program. You may also edit the max amount o= f connections.
  • Configure: cd .. Then:= ./configure
  • Install: make all install
  • Run: cd src Then: ./thc-ssl-dos ip port
  • Options include:=A0-l x where x is the number o= f connections, the=A0default is 400.

I have calculated this= as a High risk issue using CVSS v2: 8.6=A0(AV:N/AC:L/Au:N/C:N/I:N/A:C/E:P/= RL:W/RC:C/CDP:ND/TD:ND/CR:H/IR:H/AR:H)

I would like to thank all that= provided feedback and peer review for this issue: Ron Gula and Tenable, St= eve Dispensa,=A0Nasko Oskov, Marsh Ray, and K= ai Engert.

Please leave a comment or use the=A0contact form= =A0to provide feedback or request denial of service proof of con= cept testing on your site.

Best Regards,
Jorge Or= chilles

Best Regards,
Jorge Orchilles=

--0015173fef66eb3c8f049e83c4e1-- From n.mavrogiannopoulos@gmail.com Tue Mar 15 04:35:52 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FB03A6C7B for ; Tue, 15 Mar 2011 04:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2axw92JOidM0 for ; Tue, 15 Mar 2011 04:35:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8BF2B3A6C78 for ; Tue, 15 Mar 2011 04:35:51 -0700 (PDT) Received: by qwg5 with SMTP id 5so410253qwg.31 for ; Tue, 15 Mar 2011 04:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XCtChp8KWnBe9mxfNC6B6pSKa0oscP9+0NRI3D3dDpY=; b=EX7f3LGFrh4GB5FZPx/LSOb65x89q9WC37sfE/OV6QK3J8OFTVWPCHTRffwij0cTdZ BJH0su7kulQY07VHNx+fauFCJsGAdOfkhta24KdnYIHwvNBcUzqLa0CSTBDbaIz6WeAz IO5y+1tm7x7+QpALkuKrNzDaYF45dVVJF7RiU= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=LtX0BZ1jf1OfLuWFrDd++qJjx4K2U3/zuBkDS8rBvZtTnyCahKRDwbhbLYgTYoV9iz y3BRgMeHmiSsdS0g6rly2+W4OLlVL9gVxxp2b1Z53TwDrrv3jOCQ/Fqlee6l+ydQLDvw tO46LdGrj5L1b3kS1Nq8kgZ0o1yDWHmU+E9gk= MIME-Version: 1.0 Received: by 10.224.217.134 with SMTP id hm6mr12441743qab.172.1300189036122; Tue, 15 Mar 2011 04:37:16 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 04:37:16 -0700 (PDT) In-Reply-To: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> Date: Tue, 15 Mar 2011 12:37:16 +0100 X-Google-Sender-Auth: tqFnJpbkT9h93Tcxt0K8Pqb-sKs Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:35:52 -0000 On Tue, Mar 15, 2011 at 12:18 PM, Eric Rescorla wrote: >> 2. Drop requirement: The server MUST use the same >> =C2=A0 version number in the HelloVerifyRequest that it would use when >> =C2=A0 sending a ServerHello. =C2=A0Upon receipt of the ServerHello, the= client >> =C2=A0 MUST verify that the server version values match. >> This will create incompatibilities when more than 1 DTLS protocols are >> implemented >> in a single client or server. It is not really possible for a server >> to do an emulation of >> the decisions it would do as if a state existed. What are the reasons fo= r this >> requirement? > I don't understand why this is an issue: the server can remember what the > client offered (indeed, he must remember a whole pile of other stuff in o= rder > to verify that it hasn't changed) by stuffing a digest into the cookie. My issue is not about server remembering stuff, but the fact that at this p= oint the server has minimum information and has to do actual negotiation of the protocol version. Depending on the implementation chosing the version to negotiate might not be simple. I.e. the application might have configured that DTLS 1.0 and DTL= S 1.2 are allowed, but say for example only ciphersuite 0xfb, 0xbf is enabled= for this client, that has the constraint that it can be used with DTLS 1.0 (probably this is not an issue now in DTLS but this scenario is common in TLS). Thus the server cannot readily negotiate the highest DTLS 1.2, but has to a= lso check ciphersuites for conflicts, meaning that this pre-handshake cannot re= ally be kept as minimal as possible. I think the pre-handshake should be as dumb as possible to serve its role as DoS protection and no more. In typical cases it is expected to be implemented a= s something external to the handshake process, thus would be nice to require as less information and information interpreting as possible. regards, Nikos From n.mavrogiannopoulos@gmail.com Tue Mar 15 04:45:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865133A6D4F for ; Tue, 15 Mar 2011 04:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q92Vk34MhDou for ; Tue, 15 Mar 2011 04:45:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6813E3A6D45 for ; Tue, 15 Mar 2011 04:45:29 -0700 (PDT) Received: by qwg5 with SMTP id 5so417906qwg.31 for ; Tue, 15 Mar 2011 04:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=afLE8kasvlRC8sNLIadnPGBgqRE21EYQLk9KHtlPDNM=; b=LCxFCWvV03dLxpyyKuzDmWIq42Lr9S77h7H1yHwuC1ye9IY5B5SoFN7eeDds3lw5+w AJXi9VHK6JWpkQLuXBZKRqah4AeKIBHDTxCSiaB52uUB4sWTWr0j8Hgj7SvRRWmfW75C C9HOMOxx7yWwMgoYTa3wR9msaGL+UK2Q0HF1c= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=c8UurOE4TosgAyu1VDof366QYVXVSerP1CsxP1MLFdEr9++tnWxNSwXJbpjCaO+22A pRIn5TIArLj94JFQgeKoizBJV6eO42yWpX2GeXRD4VFDVAlGRn4mwPNSBy35LMrJ84Cz KdnZdthOU+/b0RINOCXonxxpA9GNGUCGGoHBs= MIME-Version: 1.0 Received: by 10.229.51.208 with SMTP id e16mr92103qcg.86.1300189574715; Tue, 15 Mar 2011 04:46:14 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 04:46:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2011 12:46:14 +0100 X-Google-Sender-Auth: k_yz7v3Q8EhGKPSZUbhVkrIexbQ Message-ID: From: Nikos Mavrogiannopoulos To: "Jorge A. Orchilles" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:45:30 -0000 On Tue, Mar 15, 2011 at 12:31 PM, Jorge A. Orchilles wrote: > Hello all, > Marsh Ray has invited me to present my research and report on SSL/TLS > Renegotiation Denial of Service on this mailing list. I have posted this = on > my site and will paste here for=C2=A0your feedback: > http://orchilles.com/2011/03/ssl-renegotiation-dos.html > SSL/TLS Renegotiation Denial of Service > An SSL/TLS handshake requires at least 10 times more processing power on = the > server than on the client. The handshake is only performed at the beginni= ng > of a secure connection to establish it. When SSL/TLS Renegotiation is > enabled on the server, a user is allowed to send a renegotiation request > which initiates a new handshake. Since it takes much less resources for a > client to perform a handshake, requesting multiple handshakes per second > could cause a denial of service on the server side SSL/TLS interface. > Therefore, if a malicious user on one host requests multiple renegotiatio= n > requests it will exhaust the server=E2=80=99s resources and not allow any= other user > to establish a connection. Hello, I'm curious, what is the effect of that in typical HTTPS servers? Do servers allow for renegotiation initiated by the client? (apache with mod_gnutls doesn't) regards, Nikos From Michael.Tuexen@lurchi.franken.de Tue Mar 15 04:50:05 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7B93A6C96 for ; Tue, 15 Mar 2011 04:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwQ+TGZ2C35Y for ; Tue, 15 Mar 2011 04:50:04 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 640913A6D4F for ; Tue, 15 Mar 2011 04:50:04 -0700 (PDT) Received: from [192.168.1.113] (p5481B2C9.dip.t-dialin.net [84.129.178.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 522EB1C0B4619; Tue, 15 Mar 2011 12:51:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 15 Mar 2011 12:51:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A80DE49-5D2C-489D-98F3-9F164C482367@lurchi.franken.de> References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:50:06 -0000 On Mar 15, 2011, at 12:18 PM, Eric Rescorla wrote: > On Tue, Mar 15, 2011 at 2:59 AM, Nikos Mavrogiannopoulos > wrote: >> On Tue, Mar 15, 2011 at 12:37 AM, Eric Rescorla wrote: >>> I suspect either reflecting or the special case would work. I'm = trying >>> to get all the other >>> changes in before the deadline so I'll leave it with =3D0 and the >>> special case and an >>> open issue marker and let's just resolve in Prague. >>=20 >> I will not be there but I'd like to make these points: >> 1. Define precisely the behavior of initial pre-handshake before = state >> is allocated. My opinion is that I don't like special cases such as >> use 0 always >> and do not case about re-use because they are more likely to = introduce >> bugs and new attacks. Copying the client's numbers should solve the >> issue with no special cases and no state. Also I suppose that if >> handshake_seq=3D0 is used for HelloVerifyRequest then handshake_seq=3D1= >> should be used for ServerHello and this should be clear as well to >> avoid having another special case. >=20 > Noted. Let's see how that discussion shakes out in the meeting. Hi Eric, I can't attend the IETF meeting and would also prefer the reflection for the same reasons Nikos pointed out. Best regards Michael >=20 >=20 >> 2. Drop requirement: The server MUST use the same >> version number in the HelloVerifyRequest that it would use when >> sending a ServerHello. Upon receipt of the ServerHello, the client >> MUST verify that the server version values match. >> This will create incompatibilities when more than 1 DTLS protocols = are >> implemented >> in a single client or server. It is not really possible for a server >> to do an emulation of >> the decisions it would do as if a state existed. What are the reasons = for this >> requirement? >=20 > I don't understand why this is an issue: the server can remember what = the > client offered (indeed, he must remember a whole pile of other stuff = in order > to verify that it hasn't changed) by stuffing a digest into the = cookie. >=20 > -Ekr >=20 From ekr@rtfm.com Tue Mar 15 04:51:24 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1FD3A6D5F for ; Tue, 15 Mar 2011 04:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEpHDvkhVESy for ; Tue, 15 Mar 2011 04:51:21 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id EB3833A6C96 for ; Tue, 15 Mar 2011 04:51:20 -0700 (PDT) Received: by gxk19 with SMTP id 19so244448gxk.31 for ; Tue, 15 Mar 2011 04:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.62.29 with SMTP id k29mr4571323aga.15.1300189965592; Tue, 15 Mar 2011 04:52:45 -0700 (PDT) Received: by 10.90.79.10 with HTTP; Tue, 15 Mar 2011 04:52:45 -0700 (PDT) In-Reply-To: References: <4D7D0292.7080700@gnutls.org> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> Date: Tue, 15 Mar 2011 04:52:45 -0700 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] implementation of cookies in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:51:24 -0000 On Tue, Mar 15, 2011 at 4:37 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Mar 15, 2011 at 12:18 PM, Eric Rescorla wrote: > >>> 2. Drop requirement: The server MUST use the same >>> =A0 version number in the HelloVerifyRequest that it would use when >>> =A0 sending a ServerHello. =A0Upon receipt of the ServerHello, the clie= nt >>> =A0 MUST verify that the server version values match. >>> This will create incompatibilities when more than 1 DTLS protocols are >>> implemented >>> in a single client or server. It is not really possible for a server >>> to do an emulation of >>> the decisions it would do as if a state existed. What are the reasons f= or this >>> requirement? >> I don't understand why this is an issue: the server can remember what th= e >> client offered (indeed, he must remember a whole pile of other stuff in = order >> to verify that it hasn't changed) by stuffing a digest into the cookie. > > My issue is not about server remembering stuff, but the fact that at this= point > the server has minimum information =A0and has to do actual negotiation of= the > protocol version. > > Depending on the implementation chosing the version to negotiate might no= t > be simple. I.e. the application might have configured that DTLS 1.0 and D= TLS > 1.2 are allowed, but say for example only ciphersuite 0xfb, 0xbf is enabl= ed for > this client, that has the constraint that it can be used with DTLS 1.0 > (probably > this is not an issue now in DTLS but this scenario is common in TLS). > Thus the server cannot readily negotiate the highest DTLS 1.2, but has to= also > check ciphersuites for conflicts, meaning that this pre-handshake cannot = really > be kept as minimal as possible. > > I think the pre-handshake should be as dumb as possible to serve its > role as DoS > protection and no more. In typical cases it is expected to be implemented= as > something external to the handshake process, thus would be nice to requir= e > as less information and information interpreting as possible. Ah, I see your point. I'll have to think a bit about what I think the best approach is here. -Ekr From dispensa@phonefactor.com Tue Mar 15 06:22:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3743A6B5A for ; Tue, 15 Mar 2011 06:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1Pk1WGKZGOe for ; Tue, 15 Mar 2011 06:22:22 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by core3.amsl.com (Postfix) with SMTP id 4F92C3A694E for ; Tue, 15 Mar 2011 06:22:17 -0700 (PDT) Received: from source ([204.13.120.8]) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTX9oXqkcsZ+2t/1iO06SKmpaGIjAWliT@postini.com; Tue, 15 Mar 2011 06:23:43 PDT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 15 Mar 2011 08:23:44 -0500 Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SSL Renegotiation DOS Thread-Index: AcvjBrTq4/89eXyGT/6HvnAD7fpWtgADRfqQ References: From: "Steve Dispensa" To: "Nikos Mavrogiannopoulos" , "Jorge A. Orchilles" Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 13:22:22 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0bHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gTmlrb3MgTWF2 cm9naWFubm9wb3Vsb3MNCj4NCj4gSGVsbG8sDQo+ICBJJ20gY3VyaW91cywgd2hhdCBpcyB0aGUg ZWZmZWN0IG9mIHRoYXQgaW4gdHlwaWNhbCBIVFRQUyBzZXJ2ZXJzPyBEbw0KPiBzZXJ2ZXJzIGFs bG93DQo+IGZvciByZW5lZ290aWF0aW9uIGluaXRpYXRlZCBieSB0aGUgY2xpZW50PyAoYXBhY2hl IHdpdGggbW9kX2dudXRscw0KPiBkb2Vzbid0KQ0KDQpXaGVuIHdlIGxvb2tlZCBhdCBpbXBsZW1l bnRhdGlvbnMgbGFzdCB5ZWFyLCB3ZSBmb3VuZCB0aGF0IElJUyB3YXMgZGVmaW5pdGVseSBub3Qg d2lsbGluZyB0byBkbyBjbGllbnQtaW5pdGlhdGVkIHJlbmVnb3RpYXRpb24sIGJ1dCBhdCB0aGUg dGltZSB0aGVyZSB3ZXJlIGEgZmV3IHRoYXQgd291bGQuIEknbSBzdXJlIGEgbG90IGhhcyBjaGFu Z2VkIHNpbmNlIEkgbGFzdCBsb29rZWQgYXQgaXQuDQoNCiAtU3RldmUNCg== From n.mavrogiannopoulos@gmail.com Tue Mar 15 07:50:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B15B3A6D9F; Tue, 15 Mar 2011 07:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te3kLRru6MwK; Tue, 15 Mar 2011 07:50:49 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C987C3A6D9B; Tue, 15 Mar 2011 07:50:48 -0700 (PDT) Received: by qwg5 with SMTP id 5so598400qwg.31 for ; Tue, 15 Mar 2011 07:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+ZjHtIv8beyrnxirWE3a7kAMGaisRJjEJfkFkUjlRII=; b=njjZlFqYm2Qf/7P34XdlC7oVJnM8rReWJg3ZwCQ1XnhgwbkcTZCFCME/slww/Iz9Vr X8aSet0Kc0iTl2fQzuA4m5qkHG/Ba3uMAQdBVWa0CTjSNUwab1gmFJPVj4RXCRsV89+B 6W+vZft9HnfjKVEk1U7QKzi9/sbX3UWV+KCPE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=BYP1igLh+XWAK/GaYMkZu2wR2/TtNyo4a6W0I+QCO6xNLBUCGQQ517UVMZPCtbd5sr CQGTPkriwEm9LCnFZyQaEFz12HNYvSL/2cMG0kPSN2RAwbeLczO9AbwywF9FK8vAzpDq RES1ECMctD8evzSxrE0IOhoQ0YiLj/oLQClII= MIME-Version: 1.0 Received: by 10.224.217.134 with SMTP id hm6mr12707255qab.172.1300200733303; Tue, 15 Mar 2011 07:52:13 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 07:52:13 -0700 (PDT) In-Reply-To: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp> References: <4D7E7AF9.7070409@gnutls.org> <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp> Date: Tue, 15 Mar 2011 15:52:13 +0100 X-Google-Sender-Auth: HGr0TaTaBKdySR1mz-NRTPbxgZQ Message-ID: From: Nikos Mavrogiannopoulos To: mrex@sap.com, tls@ietf.org, ietf@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bart.preneel@esat.kuleuven.be Subject: Re: [TLS] Last Call: (Additionx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 14:50:51 -0000 Hello, I had some discussion with Bart Preneel[0] on the use of a 96-bit MAC for the Finished messages. His comments were: "My general advice to IETF was to keep half the bits of the internal state of the hash function. For HMAC-MD5 this would be 64 bits, for HMAC-SHA-1 this would be 80 bits and for HMAC-SHA-256 this would be 128 bits. We now have key recovery attacks on HMAC-MD4 and HMAC-MD5; these attacks become somewhat harder if the output is truncated (so I believe that I was right ;-) NO forgery attacks have been found that exploit the truncation. In practice, it is better to output the same MAC length for alignment. 64 bits seemed reasonable in 1996. It turned out that 96 bits gave better alignment properties than 64 bits. I believe that a 64-bit MAC is sufficient for most applications, and a 96-bit MAC is more than enough. I can't see a reason to use a 128-bit MAC= ." That said, he suggested against decoupling data authentication from the security level of the cipher-suites: "If you are paranoid about security (which you are of you use AES-256) you should output half the bits of the internal state, so 128 for SHA-256." My comments on that is that the discussion on MAC truncation should apply both to the handshake MAC and the record MAC. If recovering the master secret was an issue for the handshake MAC, recover of the session MAC key, should also be an issue, especially since chosen-message attacks should be considered possible during application data exchange. To extend it further I think TLS cipher-suites should have a target securit= y level (e.g. 96 bits, 128 bits) and this should include the TLS Finished messages MAC as well. Otherwise we end up with combinations of AES-256 and SHA-384 as MAC truncated to 96-bits for the finished messages but the full 384 bits for the record messages, that IMO does not make much sens= e. regards, Nikos [0]. http://homes.esat.kuleuven.be/~preneel/ On Mon, Mar 14, 2011 at 11:49 PM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: >> >> On 03/14/2011 06:28 PM, Martin Rex wrote: >> > >> > That was, what I assume, the fear, based on the second part of this >> > message from Dan Simon >> > =C2=A0 =C2=A0http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0= 224.html >> > and the second part of this message from Hugo Krawczyk >> > =C2=A0 =C2=A0http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0= 231.html >> > >> > Since the TLSv1.0 finished message was defined based on the output >> > of the TLS PRF (a function with indefinite output length), >> > defining a truncation was inevitable. =C2=A0:) >> >> Indeed. It seems the messages you list summarize that design decision >> in a nice way. The concerns for the one-wayness of the MAC used lead >> to that truncation. That way one-wayness is ensured by discarding data >> at the cost of having a weaker MAC. I don't know if the current >> construction can be extended for a longer size without implications. > > The concern with the one-wayness of the hashes was about >SSLv3< > and how it computed its Finished message: > > =C2=A0 =C2=A0 enum { client(0x434C4E54), server(0x53525652) } Sender; > > =C2=A0 =C2=A0 struct { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque md5_hash[16]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque sha_hash[20]; > =C2=A0 =C2=A0 } Finished; > > =C2=A0 =C2=A0 md5_hash =C2=A0 =C2=A0 =C2=A0 MD5(master_secret + pad2 + > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0MD5(handshake_messages + Sender + > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0master_secret + pad1)); > =C2=A0 =C2=A0 sha_hash =C2=A0 =C2=A0 =C2=A0 =C2=A0SHA(master_secret + pad= 2 + > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 SHA(handshake_messages + Sender + > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 master_secret + pad1)); > > =C2=A0 =C2=A0 handshake_messages =C2=A0 =C2=A0All of the data from all ha= ndshake messages > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 up to but not including this message. =C2=A0This > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 is only data visible at the handshake layer > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 and does not include record layer headers. > > > Personally, I'm having difficulties to see how exactly it would leak the > master_secret if MD5 was found to be fully invertable. > > The MD5 output is 128 bits =3D 16 bytes, and the input is *MUCH* larger > than 128 bits. =C2=A0The master_secret should is 48 bytes alone. =C2=A0Ev= en if one is > successful at inverting MD5, one can not undo the collisions from > the Finished computation caused by the compression of a much larger > input into a 128 bit output value. > > Anyhow, I do see the new Finished computation algorithm in TLSv1.0 as a > sensible change in the TLS design. > > > -Martin > From jorton@redhat.com Tue Mar 15 08:38:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1214A3A6D4B for ; Tue, 15 Mar 2011 08:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBNkaLHoz3Yu for ; Tue, 15 Mar 2011 08:38:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 3DC593A6D1F for ; Tue, 15 Mar 2011 08:38:31 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2FFdl6K010903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2011 11:39:47 -0400 Received: from turnip.manyfish.co.uk (vpn-11-233.rdu.redhat.com [10.11.11.233]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2FFdiuW015707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2011 11:39:45 -0400 Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.72) (envelope-from ) id 1PzWLX-0002fe-B7; Tue, 15 Mar 2011 15:39:43 +0000 Date: Tue, 15 Mar 2011 15:39:43 +0000 From: Joe Orton To: Steve Dispensa Message-ID: <20110315153943.GA10156@redhat.com> Mail-Followup-To: Steve Dispensa , Nikos Mavrogiannopoulos , "Jorge A. Orchilles" , tls@ietf.org References: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> User-Agent: Mutt/1.5.20 (2009-12-10) Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 15:38:32 -0000 On Tue, Mar 15, 2011 at 08:23:44AM -0500, Steve Dispensa wrote: > > I'm curious, what is the effect of that in typical HTTPS servers? > > Do servers allow for renegotiation initiated by the client? (apache > > with mod_gnutls doesn't) > > When we looked at implementations last year, we found that IIS was > definitely not willing to do client-initiated renegotiation, but at > the time there were a few that would. I'm sure a lot has changed since > I last looked at it. As part of the workaround for CVE-2009-3555 added in the 2.2.15 release of Apache httpd, mod_ssl will (or should!) reject any renegotiation initiated by the client. The code still behaves this way, for both clients which support RFC 5746 and those which do not. Older versions of Apache httpd/mod_ssl will allow a client-initiated reneg at any time, as is the default behaviour with OpenSSL-based servers. I recall a complaint that some mobile browser was known to initiate renegs, but I can't find a reference for that; it might have been off-line discussion. I'd be interested to hear any further data on that. Regards, Joe From lists@drh-consultancy.demon.co.uk Tue Mar 15 08:48:04 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377343A6E25 for ; Tue, 15 Mar 2011 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X--r1hfRSwoU for ; Tue, 15 Mar 2011 08:48:02 -0700 (PDT) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id 9ACA23A6E21 for ; Tue, 15 Mar 2011 08:48:02 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:65520 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1PzWUw-0000Rh-De for tls@ietf.org (return-path ); Tue, 15 Mar 2011 15:49:26 +0000 Message-ID: <4D7F8A91.7030109@drh-consultancy.demon.co.uk> Date: Tue, 15 Mar 2011 15:49:37 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tls@ietf.org References: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> <20110315153943.GA10156@redhat.com> In-Reply-To: <20110315153943.GA10156@redhat.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 15:48:04 -0000 On 15/03/2011 15:39, Joe Orton wrote: > > I recall a complaint that some mobile browser was known to initiate > renegs, but I can't find a reference for that; it might have been > off-line discussion. I'd be interested to hear any further data on > that. > It was mentioned in the openssl-dev list a couple of times. The title was "Renegotiation denied wrong?" around Nov 23rd 2009. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From dispensa@phonefactor.com Tue Mar 15 09:02:35 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FC13A6DA1 for ; Tue, 15 Mar 2011 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwWD2RrZ14Ti for ; Tue, 15 Mar 2011 09:02:34 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 871B53A6D66 for ; Tue, 15 Mar 2011 09:02:34 -0700 (PDT) Received: from source ([204.13.120.8]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTX+N628qslkovU807JKzD2RFwc8ytiS9@postini.com; Tue, 15 Mar 2011 09:04:00 PDT 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, 15 Mar 2011 11:03:54 -0500 Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E0612066230A5@pos-exch1.corp.positivenetworks.net> In-Reply-To: <4D7F8A91.7030109@drh-consultancy.demon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SSL Renegotiation DOS Thread-Index: AcvjKJZ3Cu0omKfrRSWqoPfg/trFqgAAQgdQ References: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net><20110315153943.GA10156@redhat.com> <4D7F8A91.7030109@drh-consultancy.demon.co.uk> From: "Steve Dispensa" To: "Dr Stephen Henson" , Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 16:02:35 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Dr > Stephen Henson > On 15/03/2011 15:39, Joe Orton wrote: > > > > I recall a complaint that some mobile browser was known to initiate > > renegs, but I can't find a reference for that; it might have been > > off-line discussion. I'd be interested to hear any further data on > > that. > > >=20 > It was mentioned in the openssl-dev list a couple of times. The title was > "Renegotiation denied wrong?" around Nov 23rd 2009. >=20 > Steve. Seems like tor also used client-initiated renegotiation, if memory serves. Don't know if that's still true. -Steve From mrex@sap.com Tue Mar 15 09:06:20 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D623A690F for ; Tue, 15 Mar 2011 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKm0Vn7+WT+d for ; Tue, 15 Mar 2011 09:06:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E215D3A6DA1 for ; Tue, 15 Mar 2011 09:06:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2FG7g6l010180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2011 17:07:43 +0100 (MET) From: Martin Rex Message-Id: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> To: jorge@orchilles.com (Jorge A. Orchilles) Date: Tue, 15 Mar 2011 17:07:42 +0100 (MET) In-Reply-To: from "Jorge A. Orchilles" at Mar 15, 11 08:31:28 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] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:06:20 -0000 Jorge A. Orchilles wrote: > > Marsh Ray has invited me to present my research and report on SSL/TLS > Renegotiation Denial of Service on this mailing list. I have posted this on > my site and will paste here for your feedback: > http://orchilles.com/2011/03/ssl-renegotiation-dos.html > > *SSL/TLS Renegotiation Denial of Service* > > An SSL/TLS handshake requires at least 10 times more processing power on the > server than on the client. I'm sorry, I completely fail to see what renegotiation has to do with the DoS capability here. The TLS protocol is a cryptographic protocol, and servers that expect to talk to real clients performing the protocol as designed will attempt to perform the cryptographic operations as requested. A DoS-client could simply open new connections to the SSL server and blindly fire away precompiled static SSL handshake messages, forcing the server to do crypto work. You should be able to make most servers perform RSA decrypts on arbitrary data, and a significant number to perform DHE computations. -Martin From ekr@rtfm.com Tue Mar 15 09:19:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A923A6C5B for ; Tue, 15 Mar 2011 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQZzZ+HDqBgK for ; Tue, 15 Mar 2011 09:19:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2A2BA3A6B89 for ; Tue, 15 Mar 2011 09:19:10 -0700 (PDT) Received: by iyi12 with SMTP id 12so863973iyi.31 for ; Tue, 15 Mar 2011 09:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.135.73 with SMTP id if9mr9676079icc.37.1300206035277; Tue, 15 Mar 2011 09:20:35 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Tue, 15 Mar 2011 09:20:35 -0700 (PDT) In-Reply-To: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> Date: Tue, 15 Mar 2011 09:20:35 -0700 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 16:19:13 -0000 On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex wrote: > Jorge A. Orchilles wrote: >> >> Marsh Ray has invited me to present my research and report on SSL/TLS >> Renegotiation Denial of Service on this mailing list. I have posted this= on >> my site and will paste here for your feedback: >> http://orchilles.com/2011/03/ssl-renegotiation-dos.html >> >> *SSL/TLS Renegotiation Denial of Service* >> >> An SSL/TLS handshake requires at least 10 times more processing power on= the >> server than on the client. > > I'm sorry, I completely fail to see what renegotiation has to do > with the DoS capability here. > > The TLS protocol is a cryptographic protocol, and servers that expect > to talk to real clients performing the protocol as designed will attempt > to perform the cryptographic operations as requested. > > A DoS-client could simply open new connections to the SSL server and > blindly fire away precompiled static SSL handshake messages, forcing the > server to do crypto work. =A0You should be able to make most servers > perform RSA decrypts on arbitrary data, and a significant number > to perform DHE computations. I tend to agree with Martin here: I don't see how this is significantly worse than separate connections. Arguably, it's better from the victim's perspective, since common implementations run each SSL/TLS connection in its own control thread (or process) and so the scheduler will try to fairly share between connections to some extent meaning that the single offending connection is bounded in terms of how much it can affect other users. -Ekr From marsh@extendedsubset.com Tue Mar 15 09:35:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3B13A6A7C for ; Tue, 15 Mar 2011 09:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2tFLAkfbuG6 for ; Tue, 15 Mar 2011 09:35:46 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A76D23A6D7D for ; Tue, 15 Mar 2011 09:35:39 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PzWw1-000Jq5-Vr; Tue, 15 Mar 2011 16:17:26 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 653EC6068; Tue, 15 Mar 2011 16:36:58 +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+n6RWUZpllMV4emFbki71wQWvfrXjNKTk= Message-ID: <4D7F95AA.8060007@extendedsubset.com> Date: Tue, 15 Mar 2011 11:36:58 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 16:35:47 -0000 On 03/15/2011 11:20 AM, Eric Rescorla wrote: > On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex wrote: >> >> I'm sorry, I completely fail to see what renegotiation has to do >> with the DoS capability here. >> [...] >> A DoS-client could simply open new connections to the SSL server >> and blindly fire away precompiled static SSL handshake messages, >> forcing the server to do crypto work. You should be able to make >> most servers perform RSA decrypts on arbitrary data, and a >> significant number to perform DHE computations. Yes, but take a step back from the code for a minute. This is a potential problem, and the degree to which this is "not my (TLS's) problem" has to do mainly with how close you are to the web server getting DoSed. > I tend to agree with Martin here: I don't see how this is > significantly worse than separate connections. Presumably, somewhere there is a TCP-based load-balancing DoS prevention system protecting a TLS server that allows client-initiated renegotiation. This system may do a good job of resisting DoSes on the initial handshake but not DoSes on renegotiation handshakes. My suggestion to Jorge would be to find such a product configuration and demonstrate the attack against it (and file a bug with the vendor of course). I don't see this as a real weakness in TLS itself either. Nevertheless, I think might be something in scope here. Are there improvements to DoS resistance which could be made in the scope of the IETF's TLS activity? For those of us wishing to promote the use of TLS/HTTPS in general, is susceptibility to DoS a significant barrier to adoption? Look at it this way: If adding TLS increasing the susceptibility to DoS attacks, could a DoS be used to compel a site operator to turn off encryption? If so, is this not effectively an equivalent to a weakness in TLS itself? > Arguably, it's better > from the victim's perspective, since common implementations run each > SSL/TLS connection in its own control thread (or process) and so the > scheduler will try to fairly share between connections to some extent > meaning that the single offending connection is bounded in terms of > how much it can affect other users. That's an interesting point. - Marsh From mrex@sap.com Tue Mar 15 10:56:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BEDF3A6E21 for ; Tue, 15 Mar 2011 10:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdo8YKfpJ68E for ; Tue, 15 Mar 2011 10:55:58 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 038C43A6971 for ; Tue, 15 Mar 2011 10:55:57 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2FHvJKn020943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2011 18:57:19 +0100 (MET) From: Martin Rex Message-Id: <201103151757.p2FHvIRC014976@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 15 Mar 2011 18:57:18 +0100 (MET) In-Reply-To: <4D7F95AA.8060007@extendedsubset.com> from "Marsh Ray" at Mar 15, 11 11:36:58 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] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:56:00 -0000 Marsh Ray wrote: > > > Presumably, somewhere there is a TCP-based load-balancing DoS prevention > system protecting a TLS server that allows client-initiated > renegotiation. This system may do a good job of resisting DoSes on the > initial handshake but not DoSes on renegotiation handshakes. The issue might be more about the classification of what counts as a DoS attack. Recognizing TLS renegotiations is technically possible for Intrusion dectection systems, since the ChangeCipherSpec handshake message remains visible on on the wire, even for TLS renegotiations. (also, the fact that handshake messages rather than application data is exchanged, remains visible on the wire). The workload impact of full TLS handshakes on the TLS server is far from marginal. Therefore, even non-hostile clients can consume most of a servers resources. Distinguishing DoS from clients with a flaw in their TLS session caching and defective server-side TLS session caching or inappropriate configuration might be tricky for an IDS. Server resources may get drained without any errors showing up on the communication protocol level, simply by performing the cryptographic operations of the protocol over and over again. A TLS server can easily DoS _itself_ with an inadequate, too small or disabled server side TLS session cache (or due to bugs in the session cache management of the implementation). Personally, I consider it a bad idea to run a TLS server on the internet with TLS session caching entirely disabled. Limiting session cache lifetime and session cache size on the TLS server seems sensible, but running entirely without session cache does not look sensible to me (for public Web-Servers on the internet). TLS clients without session caching capabilities also seem to be unnecessarily common. Apache mod_proxy used to be incapable of client side TLS session caching--which causes a serious performance impact on the communication link between reverse proxy and backend if that link is TLS-reencrypted. > > My suggestion to Jorge would be to find such a product configuration and > demonstrate the attack against it (and file a bug with the vendor of > course). > > I don't see this as a real weakness in TLS itself either. Nevertheless, > I think might be something in scope here. Are there improvements to DoS > resistance which could be made in the scope of the IETF's TLS activity? When the topic of "client identity protection" came up on the TLS mailing list, the suggestion was made to solve this by performing a TLS renegotiation. Today (after the TLS renegotiation vulnerability), many servers may have unsolicited renegotiations disabled (and may continue to have it disabled after adopting the rfc5746 solution). Microsoft IIS seems to have never supported unsolicited renegotiations so far -- it was primarily "added value" for TLS implementations that could perform TLS renegotiation "transparently", i.e. without requiring support from the (TLS) application caller to do renegotiation. The results that TLS renegotiation might have on the client identity, as seen by the server application, is sufficiently non-trivial that some discussion on this was added to the security considerations of rfc5746 http://tools.ietf.org/html/rfc5746#section-5 -Martin From dispensa@phonefactor.com Tue Mar 15 12:50:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3CE3A6E68 for ; Tue, 15 Mar 2011 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa-ZO5ugaoVZ for ; Tue, 15 Mar 2011 12:50:50 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id BE8DA3A6A8B for ; Tue, 15 Mar 2011 12:50:49 -0700 (PDT) Received: from source ([204.13.120.8]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTX/Db6VWBeS/DEds7/RjZx/fg3hEKYDV@postini.com; Tue, 15 Mar 2011 12:52:15 PDT 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, 15 Mar 2011 14:52:14 -0500 Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E06120662315D@pos-exch1.corp.positivenetworks.net> In-Reply-To: <4D7F95AA.8060007@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SSL Renegotiation DOS Thread-Index: AcvjL0E1VJB3havYRNGrsB5skwLiYwAGhMrg References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> <4D7F95AA.8060007@extendedsubset.com> From: "Steve Dispensa" To: "Marsh Ray" , "Eric Rescorla" Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:50:50 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Marsh Ray > > Presumably, somewhere there is a TCP-based load-balancing DoS prevention > system protecting a TLS server that allows client-initiated > renegotiation. This system may do a good job of resisting DoSes on the > initial handshake but not DoSes on renegotiation handshakes. Yes; any DoS mitigation work that has been done on initial handshakes should also be done on renegotiations. It wouldn't surprise me if there are implementations out there for which this is not the case. (Not that I have any evidence, but I'm eagerly awaiting the results of Jorge's search.) If nothing else, it'd be good advice for implementers to keep in mind going forward. -Steve From pgut001@login01.cs.auckland.ac.nz Tue Mar 15 23:53:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF453A6808 for ; Tue, 15 Mar 2011 23:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhs-6qdhSOvD for ; Tue, 15 Mar 2011 23:53:32 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 313CC3A680B for ; Tue, 15 Mar 2011 23:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1300258499; x=1331794499; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20SSL=20Renego tiation=20DOS|Cc:=20tls@ietf.org|In-Reply-To:=20<20110315 1607.p2FG7g47008253@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Wed, =2016=20Mar=202011=2019:54:55=20+1300; bh=5JLDcQu41any3DBhyoc+tci9SNl1kXa9muZooyUq/To=; b=k778W9G2FFUaZTumGzpw+0KhsZAt1TAoYRzKSGtLy3xJVHRdKOUNkcgw muxiDc2urcSyNEynMtcbisbPA2ZzZjvTQPRpyGhkA0ZIWk8kHQpN1i0iO tJoVoSK8MORfx33L5Goz6ZmCkaJgHM8BPAU3o+7+49G5DO07qCIEhm/u0 s=; X-IronPort-AV: E=Sophos;i="4.63,193,1299409200"; d="scan'208";a="51451187" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Mar 2011 19:54:55 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PzkdD-0008Pd-Gl; Wed, 16 Mar 2011 19:54:55 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PzkdD-0000jT-4G; Wed, 16 Mar 2011 19:54:55 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 16 Mar 2011 19:54:55 +1300 Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 06:53:33 -0000 Martin Rex writes: >A DoS-client could simply open new connections to the SSL server and blindly >fire away precompiled static SSL handshake messages, forcing the server to do >crypto work. You should be able to make most servers perform RSA decrypts on >arbitrary data, and a significant number to perform DHE computations. Exactly. You can do this with virtually no effort using netcat, I continue to be surprised that we've never seen this deployed in the wild (not wanting to give any hints to Anonymous, but LOIC is 1990s script-kiddie technology compared to the DoSes you could use if you gave it a few minutes thought). What makes it even worse is the Bleichenbacher-attack defense that says you have to complete the handshake, at full crypto cost, even if it's obvious that you're just processing garbage. (Every time this comes up I'm tempted to release some quick tool to exploit the problem, on the basis that if the good guys don't point it out now, the bad guys will take advantage of it later. So far I've resisted the temptation...). Peter. From mrex@sap.com Wed Mar 16 07:01:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D463A695C for ; Wed, 16 Mar 2011 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsxwB5VFei4u for ; Wed, 16 Mar 2011 07:01:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id F31A43A6857 for ; Wed, 16 Mar 2011 07:01:34 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2GE2pcE024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2011 15:02:51 +0100 (MET) From: Martin Rex Message-Id: <201103161402.p2GE2oFm023860@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 16 Mar 2011 15:02:50 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Mar 16, 11 07:54:55 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] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:01:36 -0000 Peter Gutmann wrote: > > Martin Rex writes: > > >A DoS-client could simply open new connections to the SSL server and blindly > >fire away precompiled static SSL handshake messages, forcing the server to do > >crypto work. You should be able to make most servers perform RSA decrypts on > >arbitrary data, and a significant number to perform DHE computations. > > Exactly. You can do this with virtually no effort using netcat, I continue to > be surprised that we've never seen this deployed in the wild (not wanting to > give any hints to Anonymous, but LOIC is 1990s script-kiddie technology > compared to the DoSes you could use if you gave it a few minutes thought). > What makes it even worse is the Bleichenbacher-attack defense that says you > have to complete the handshake, at full crypto cost, even if it's obvious that > you're just processing garbage. If a hostile client is targetting specific servers, it could create a valid PKCS#1 encrypted premaster secret once and then reuse it in all further handshakes -- saving the client the asymmetric crypto work on all additional connections, while still allowing the client to complete the TLS handshake successfully. -Martin From pgut001@login01.cs.auckland.ac.nz Wed Mar 16 07:46:27 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1860F3A6920 for ; Wed, 16 Mar 2011 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdN7fYc97EuF for ; Wed, 16 Mar 2011 07:46:26 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B88923A6911 for ; Wed, 16 Mar 2011 07:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1300286873; x=1331822873; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20SSL=20Renego tiation=20DOS|Cc:=20tls@ietf.org|In-Reply-To:=20<20110316 1402.p2GE2oFm023860@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Thu, =2017=20Mar=202011=2003:47:50=20+1300; bh=uY6Ks8kmmv2g1M6D/pugBlpjjfVEYeQHWJ5M3dVNMZU=; b=DxcMNJB+qsLEcQM62o+kpAhMW/kAnpUby+zMG3mUEyLDbgkuOzI4Qf9q dymRtfqF1U83wo/X+EXIAo8GrIl1PRepJ4YvUj1pcO0SuPH8xrZWwZmSm uOwFHBRX8BGOuoi8Uj+GNMuN59A6/hFY3E74x6fXncGlp9t5i6OjE/4z6 g=; X-IronPort-AV: E=Sophos;i="4.63,194,1299409200"; d="scan'208";a="51484601" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Mar 2011 03:47:50 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Pzs0s-0006Dh-GK; Thu, 17 Mar 2011 03:47:50 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Pzs0s-000105-0f; Thu, 17 Mar 2011 03:47:50 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201103161402.p2GE2oFm023860@fs4113.wdf.sap.corp> Message-Id: Date: Thu, 17 Mar 2011 03:47:50 +1300 Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 14:46:27 -0000 Martin Rex writes: >If a hostile client is targetting specific servers, it could create a valid >PKCS#1 encrypted premaster secret once and then reuse it in all further >handshakes -- saving the client the asymmetric crypto work on all additional >connections, while still allowing the client to complete the TLS handshake >successfully. If you're just interested in a DoS then you don't even need to do that, just shovel in 128 bytes of random noise and wait for the server's crypto engine to collapse under the load. You can't complete the handshake in this case, but that's not the bit that you're targetting. Peter. From jsalowey@cisco.com Wed Mar 16 13:43:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33773A69D6 for ; Wed, 16 Mar 2011 13:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VgThUXFtnDB for ; Wed, 16 Mar 2011 13:43:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A2BC03A69D5 for ; Wed, 16 Mar 2011 13:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1199; q=dns/txt; s=iport; t=1300308313; x=1301517913; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=YLKrQeJdSeyhwwFaAlesviMohDFQ4jYfepCYi81EQyM=; b=ClttIODMF4ZgtorAr5L6NJrxHXayYQN7P6ZRiB0wHK/NrAtpYxnjqcDD l0gWHhigfNa4IrsyxzwIoMxvXHS4dZW4xlk8eB3CGwT9rsmXOD21IpBCZ vEdzUqg1SuuGNlvzpp9CJdXhgdeAQWpH3QaBCyWAklLJvuw30BUYhWC2d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwBAKS+gE2tJXHA/2dsb2JhbACYVz+MdnemDJxMhWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="321091877" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 20:45:13 +0000 Received: from [10.33.251.197] ([10.33.251.197]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2GKjCO0019274 for ; Wed, 16 Mar 2011 20:45:12 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 13:46:39 -0700 Message-Id: <6FEF9040-9435-4443-9E3C-56439CAFA51E@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [TLS] Draft agenda for IETF-80 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 20:43:47 -0000 We've received more requests for agenda slots then we have time for in = the 1 hour meeting. I'm giving priority to existing working group = business and topics that have not been presented at a meeting before. = For topics which are not new I'm asking for a 1-2 slide update that can = be presented in 5 minutes.=20 Agenda IETF-80 - TLS Working Group WEDNESDAY, March 30, 2011 1510-1610 Afternoon Session II Vienna/Madrid ------------- 1. Administrivia (Blue Sheets, note takes, agenda bashing) (5min) 2. DTLS 1.2 issues (15 min) (Eric Rescorla) draft-ietf-tls-rfc4347-bis-05 3. Charter (10min) (Joe Salowey / Sean Turner) 4. Next Protocol Negotiation (15 min) (Adam Langly / Mike Belshe) draft-agl-tls-nextprotoneg-00 5. AES-CCM Ciphers (5 min) (Matt Campagna) draft-mcgrew-tls-aes-ccm-ecc-01 draft-mcgrew-tls-aes-ccm-01 6. EAP and TLS (5 min) (Yoav Nir) draft-nir-tls-eap-10 7. Renegotiation Patch status (5 min) (Yngve N. Pettersen) = http://my.opera.com/securitygroup/blog/2010/11/04/a-few-results-from-the-t= ls-prober 8. Multiple OCSP enhancements (time permitting) (Yngve N. Pettersen) draft-pettersen-tls-ext-multiple-ocsp-02= From jorge@orchilles.com Fri Mar 18 16:03:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE6F3A6A7C for ; Fri, 18 Mar 2011 16:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd-9xutw+du0 for ; Fri, 18 Mar 2011 16:03:12 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2C0EE3A6A6D for ; Fri, 18 Mar 2011 16:03:11 -0700 (PDT) Received: by fxm15 with SMTP id 15so4455559fxm.31 for ; Fri, 18 Mar 2011 16:04:41 -0700 (PDT) Received: by 10.223.110.38 with SMTP id l38mr1890326fap.116.1300489481372; Fri, 18 Mar 2011 16:04:41 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id n26sm1572636fam.13.2011.03.18.16.04.39 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:04:40 -0700 (PDT) Received: by fxm15 with SMTP id 15so4455542fxm.31 for ; Fri, 18 Mar 2011 16:04:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.6.11 with SMTP id 11mr1915701fax.93.1300489479212; Fri, 18 Mar 2011 16:04:39 -0700 (PDT) Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:04:39 -0700 (PDT) In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> References: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> Date: Fri, 18 Mar 2011 20:04:39 -0300 Message-ID: From: "Jorge A. Orchilles" To: Steve Dispensa Content-Type: multipart/alternative; boundary=00151747849e7150a6049ec9cd3d Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:03:13 -0000 --00151747849e7150a6049ec9cd3d Content-Type: text/plain; charset=ISO-8859-1 Thank you for the response. Many implementations allow SSL Renegotiation by default. IIS is one that does not. Best Regards, Jorge Orchilles On Tue, Mar 15, 2011 at 10:23 AM, Steve Dispensa wrote: > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > > Nikos Mavrogiannopoulos > > > > Hello, > > I'm curious, what is the effect of that in typical HTTPS servers? Do > > servers allow > > for renegotiation initiated by the client? (apache with mod_gnutls > > doesn't) > > When we looked at implementations last year, we found that IIS was > definitely not willing to do client-initiated renegotiation, but at the time > there were a few that would. I'm sure a lot has changed since I last looked > at it. > > -Steve > --00151747849e7150a6049ec9cd3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for the response. Many implementations allow SSL Renegotiation by= default. IIS is one that does not.=A0

Best Regards,Jorge Orchilles



On Tue, Mar 15, 2011 at 10:23 AM, Steve = Dispensa <= dispensa@phonefactor.com> wrote:
> -----Original Message-----
> From: tls-bounces@ietf.org= [mailto:tls-bounces@ietf.org] = On Behalf Of
> Nikos Mavrogiannopoulos
>
> Hello,
> =A0I'm curious, what is the effect of that in typical HTTPS server= s? Do
> servers allow
> for renegotiation initiated by the client? (apache with mod_gnutls
> doesn't)

When we looked at implementations last year, we found that IIS was de= finitely not willing to do client-initiated renegotiation, but at the time = there were a few that would. I'm sure a lot has changed since I last lo= oked at it.

=A0-Steve

--00151747849e7150a6049ec9cd3d-- From jorge@orchilles.com Fri Mar 18 16:07:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239463A6A8D for ; Fri, 18 Mar 2011 16:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwotQt66INQW for ; Fri, 18 Mar 2011 16:07:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5E8D73A6A8C for ; Fri, 18 Mar 2011 16:07:20 -0700 (PDT) Received: by bwz13 with SMTP id 13so4106702bwz.31 for ; Fri, 18 Mar 2011 16:08:49 -0700 (PDT) Received: by 10.204.15.75 with SMTP id j11mr1467351bka.20.1300489729208; Fri, 18 Mar 2011 16:08:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id x6sm2505635bkv.0.2011.03.18.16.08.48 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:08:48 -0700 (PDT) Received: by fxm15 with SMTP id 15so4457611fxm.31 for ; Fri, 18 Mar 2011 16:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.44.89 with SMTP id z25mr1453236fae.74.1300489727291; Fri, 18 Mar 2011 16:08:47 -0700 (PDT) Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:08:47 -0700 (PDT) In-Reply-To: References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> Date: Fri, 18 Mar 2011 20:08:47 -0300 Message-ID: From: "Jorge A. Orchilles" To: Eric Rescorla Content-Type: multipart/alternative; boundary=0015174761ce3ab032049ec9dc26 Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:07:22 -0000 --0015174761ce3ab032049ec9dc26 Content-Type: text/plain; charset=ISO-8859-1 It is different that you don't need the volume that you typically need for DDOS. With renogatiation the attacker can request the server to do all the crypto work by requesting multiple handshakes per second. Best Regards, Jorge Orchilles On Tue, Mar 15, 2011 at 1:20 PM, Eric Rescorla wrote: > On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex wrote: > > Jorge A. Orchilles wrote: > >> > >> Marsh Ray has invited me to present my research and report on SSL/TLS > >> Renegotiation Denial of Service on this mailing list. I have posted this > on > >> my site and will paste here for your feedback: > >> http://orchilles.com/2011/03/ssl-renegotiation-dos.html > >> > >> *SSL/TLS Renegotiation Denial of Service* > >> > >> An SSL/TLS handshake requires at least 10 times more processing power on > the > >> server than on the client. > > > > I'm sorry, I completely fail to see what renegotiation has to do > > with the DoS capability here. > > > > The TLS protocol is a cryptographic protocol, and servers that expect > > to talk to real clients performing the protocol as designed will attempt > > to perform the cryptographic operations as requested. > > > > A DoS-client could simply open new connections to the SSL server and > > blindly fire away precompiled static SSL handshake messages, forcing the > > server to do crypto work. You should be able to make most servers > > perform RSA decrypts on arbitrary data, and a significant number > > to perform DHE computations. > > I tend to agree with Martin here: I don't see how this is > significantly worse than separate > connections. Arguably, it's better from the victim's perspective, > since common implementations > run each SSL/TLS connection in its own control thread (or process) and > so the scheduler > will try to fairly share between connections to some extent meaning > that the single offending > connection is bounded in terms of how much it can affect other users. > > -Ekr > --0015174761ce3ab032049ec9dc26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is different that you don't need the volume that you typically need = for DDOS. With renogatiation the attacker can request the server to do all = the crypto work by requesting multiple handshakes per second.

Best Regards,
Jorge Orchilles



On Tue, Mar 15, 2011 at 1:20 PM, Eric Re= scorla <ekr@rtfm.com> wrote:
On Tue, Mar 15, 2011 at 9:07 AM, Martin R= ex <mrex@sap.com> wrote:
> Jorge A. Orchilles wrote:
>>
>> Marsh Ray has invited me to present my research and report on SSL/= TLS
>> Renegotiation Denial of Service on this mailing list. I have poste= d this on
>> my site and will paste here for your feedback:
>> http://orchilles.com/2011/03/ssl-renegotiation-dos.html=
>>
>> *SSL/TLS Renegotiation Denial of Service*
>>
>> An SSL/TLS handshake requires at least 10 times more processing po= wer on the
>> server than on the client.
>
> I'm sorry, I completely fail to see what renegotiation has to do > with the DoS capability here.
>
> The TLS protocol is a cryptographic protocol, and servers that expect<= br> > to talk to real clients performing the protocol as designed will attem= pt
> to perform the cryptographic operations as requested.
>
> A DoS-client could simply open new connections to the SSL server and > blindly fire away precompiled static SSL handshake messages, forcing t= he
> server to do crypto work. =A0You should be able to make most servers > perform RSA decrypts on arbitrary data, and a significant number
> to perform DHE computations.

I tend to agree with Martin here: I don't see how this is significantly worse than separate
connections. Arguably, it's better from the victim's perspective, since common implementations
run each SSL/TLS connection in its own control thread (or process) and
so the scheduler
will try to fairly share between connections to some extent meaning
that the single offending
connection is bounded in terms of how much it can affect other users.

-Ekr

--0015174761ce3ab032049ec9dc26-- From jorge@orchilles.com Fri Mar 18 16:11:17 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FFC3A6A92 for ; Fri, 18 Mar 2011 16:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUFXoxri-tYI for ; Fri, 18 Mar 2011 16:11:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A9AE23A6A8D for ; Fri, 18 Mar 2011 16:11:15 -0700 (PDT) Received: by fxm15 with SMTP id 15so4459363fxm.31 for ; Fri, 18 Mar 2011 16:12:45 -0700 (PDT) Received: by 10.223.127.210 with SMTP id h18mr1923948fas.71.1300489965138; Fri, 18 Mar 2011 16:12:45 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id e17sm660716fak.0.2011.03.18.16.12.44 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:12:44 -0700 (PDT) Received: by fxm15 with SMTP id 15so4459350fxm.31 for ; Fri, 18 Mar 2011 16:12:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.6.73 with SMTP id 9mr1575548fay.131.1300489603851; Fri, 18 Mar 2011 16:06:43 -0700 (PDT) Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:06:43 -0700 (PDT) In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E0612066230A5@pos-exch1.corp.positivenetworks.net> References: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net> <20110315153943.GA10156@redhat.com> <4D7F8A91.7030109@drh-consultancy.demon.co.uk> <0F7F9A82BB0DBB4396A9F8386D0E0612066230A5@pos-exch1.corp.positivenetworks.net> Date: Fri, 18 Mar 2011 20:06:43 -0300 Message-ID: From: "Jorge A. Orchilles" To: Steve Dispensa Content-Type: multipart/alternative; boundary=00151747b380df2747049ec9d4d9 Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:11:17 -0000 --00151747b380df2747049ec9d4d9 Content-Type: text/plain; charset=ISO-8859-1 Looks like Tor fixed that in 0.2.1.21 http://archives.seul.org/or/announce/Dec-2009/msg00000.html Best Regards, Jorge Orchilles On Tue, Mar 15, 2011 at 1:03 PM, Steve Dispensa wrote: > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Dr > > Stephen Henson > > On 15/03/2011 15:39, Joe Orton wrote: > > > > > > I recall a complaint that some mobile browser was known to initiate > > > renegs, but I can't find a reference for that; it might have been > > > off-line discussion. I'd be interested to hear any further data on > > > that. > > > > > > > It was mentioned in the openssl-dev list a couple of times. The title > was > > "Renegotiation denied wrong?" around Nov 23rd 2009. > > > > Steve. > > Seems like tor also used client-initiated renegotiation, if memory > serves. Don't know if that's still true. > > -Steve > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00151747b380df2747049ec9d4d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks like Tor fixed that in 0.2.1.21
http://archives.seul.org/or/announce= /Dec-2009/msg00000.html

Best Regards,
Jorge Orc= hilles



On Tue, Mar 15, 2011 at 1:03 PM, Steve D= ispensa <d= ispensa@phonefactor.com> wrote:
> -----Original Message-----
> From: tls-bounces@ietf.org= [mailto:tls-bounces@ietf.org] = On Behalf Of
Dr
> Stephen Henson
> On 15/03/2011 15:39, Joe Orton wrote:
> >
> > I recall a complaint that some mobile browser was known to initia= te
> > renegs, but I can't find a reference for that; it might have = been
> > off-line discussion. =A0I'd be interested to hear any further= data on
> > that.
> >
>
> It was mentioned in the openssl-dev list a couple of times. The title<= br> was
> "Renegotiation denied wrong?" around Nov 23rd 2009.
>
> Steve.

Seems like tor also used client-initiated renegotiation, if memory serves. Don't know if that's still true.

=A0-Steve

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

--00151747b380df2747049ec9d4d9-- From jorge@orchilles.com Fri Mar 18 16:17:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3BE3A6A92 for ; Fri, 18 Mar 2011 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BzvulMCbZ+S for ; Fri, 18 Mar 2011 16:17:13 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 032323A6A8C for ; Fri, 18 Mar 2011 16:17:12 -0700 (PDT) Received: by fxm15 with SMTP id 15so4462220fxm.31 for ; Fri, 18 Mar 2011 16:18:42 -0700 (PDT) Received: by 10.223.143.12 with SMTP id s12mr507282fau.121.1300490308497; Fri, 18 Mar 2011 16:18:28 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id c11sm1573999fav.26.2011.03.18.16.18.27 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:18:27 -0700 (PDT) Received: by fxm15 with SMTP id 15so4462078fxm.31 for ; Fri, 18 Mar 2011 16:18:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.6.73 with SMTP id 9mr1580376fay.131.1300489965895; Fri, 18 Mar 2011 16:12:45 -0700 (PDT) Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:12:45 -0700 (PDT) In-Reply-To: <201103151757.p2FHvIRC014976@fs4113.wdf.sap.corp> References: <4D7F95AA.8060007@extendedsubset.com> <201103151757.p2FHvIRC014976@fs4113.wdf.sap.corp> Date: Fri, 18 Mar 2011 20:12:45 -0300 Message-ID: From: "Jorge A. Orchilles" To: mrex@sap.com Content-Type: multipart/alternative; boundary=00151747b380737ef5049ec9ea1b Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:17:14 -0000 --00151747b380737ef5049ec9ea1b Content-Type: text/plain; charset=ISO-8859-1 However many servers continue to allow SSL Renegotiation. I am identifying what implementations, suites and web servers allow this and reporting it to the vendor and site. Best Regards, Jorge Orchilles On Tue, Mar 15, 2011 at 2:57 PM, Martin Rex wrote: > Marsh Ray wrote: > > > > > > Presumably, somewhere there is a TCP-based load-balancing DoS prevention > > system protecting a TLS server that allows client-initiated > > renegotiation. This system may do a good job of resisting DoSes on the > > initial handshake but not DoSes on renegotiation handshakes. > > The issue might be more about the classification of what counts as > a DoS attack. Recognizing TLS renegotiations is technically possible for > Intrusion dectection systems, since the ChangeCipherSpec handshake > message remains visible on on the wire, even for TLS renegotiations. > (also, the fact that handshake messages rather than application data > is exchanged, remains visible on the wire). > > The workload impact of full TLS handshakes on the TLS server is > far from marginal. Therefore, even non-hostile clients can consume > most of a servers resources. > > Distinguishing DoS from clients with a flaw in their TLS session caching > and defective server-side TLS session caching or inappropriate > configuration > might be tricky for an IDS. Server resources may get drained without any > errors showing up on the communication protocol level, simply by > performing the cryptographic operations of the protocol over and over > again. > > A TLS server can easily DoS _itself_ with an inadequate, > too small or disabled server side TLS session cache (or due to > bugs in the session cache management of the implementation). > > Personally, I consider it a bad idea to run a TLS server on the > internet with TLS session caching entirely disabled. Limiting > session cache lifetime and session cache size on the TLS server > seems sensible, but running entirely without session cache > does not look sensible to me (for public Web-Servers on the internet). > > TLS clients without session caching capabilities also seem to > be unnecessarily common. Apache mod_proxy used to be incapable > of client side TLS session caching--which causes a serious > performance impact on the communication link between reverse > proxy and backend if that link is TLS-reencrypted. > > > > > My suggestion to Jorge would be to find such a product configuration and > > demonstrate the attack against it (and file a bug with the vendor of > > course). > > > > I don't see this as a real weakness in TLS itself either. Nevertheless, > > I think might be something in scope here. Are there improvements to DoS > > resistance which could be made in the scope of the IETF's TLS activity? > > When the topic of "client identity protection" came up on the TLS > mailing list, the suggestion was made to solve this by performing > a TLS renegotiation. > > Today (after the TLS renegotiation vulnerability), many servers may > have unsolicited renegotiations disabled (and may continue to have > it disabled after adopting the rfc5746 solution). Microsoft IIS > seems to have never supported unsolicited renegotiations so far -- > it was primarily "added value" for TLS implementations that could > perform TLS renegotiation "transparently", i.e. without requiring > support from the (TLS) application caller to do renegotiation. > > The results that TLS renegotiation might have on the client identity, > as seen by the server application, is sufficiently non-trivial that some > discussion on this was added to the security considerations of rfc5746 > > http://tools.ietf.org/html/rfc5746#section-5 > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00151747b380737ef5049ec9ea1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable However many servers continue to allow SSL Renegotiation. I am identifying = what implementations, suites and web servers allow this and reporting it to= the vendor and site.

Best Regards,
Jorge Orchilles=



On Tue, Mar 15, 2011 at 2:57 PM, Martin = Rex <mrex@sap.com&= gt; wrote:
Marsh Ray wrote:
>
>
> Presumably, somewhere there is a TCP-based load-balancing DoS preventi= on
> system protecting a TLS server that allows client-initiated
> renegotiation. This system may do a good job of resisting DoSes on the=
> initial handshake but not DoSes on renegotiation handshakes.

The issue might be more about the classification of what counts as a DoS attack. =A0Recognizing TLS renegotiations is technically possible for=
Intrusion dectection systems, since the ChangeCipherSpec handshake
message remains visible on on the wire, even for TLS renegotiations.
(also, the fact that handshake messages rather than application data
is exchanged, remains visible on the wire).

The workload impact of full TLS handshakes on the TLS server is
far from marginal. =A0Therefore, even non-hostile clients can consume
most of a servers resources.

Distinguishing DoS from clients with a flaw in their TLS session caching and defective server-side TLS session caching or inappropriate configuratio= n
might be tricky for an IDS. =A0Server resources may get drained without any=
errors showing up on the communication protocol level, simply by
performing the cryptographic operations of the protocol over and over again= .

A TLS server can easily DoS _itself_ with an inadequate,
too small or disabled server side TLS session cache (or due to
bugs in the session cache management of the implementation).

Personally, I consider it a bad idea to run a TLS server on the
internet with TLS session caching entirely disabled. =A0Limiting
session cache lifetime and session cache size on the TLS server
seems sensible, but running entirely without session cache
does not look sensible to me (for public Web-Servers on the internet).

TLS clients without session caching capabilities also seem to
be unnecessarily common. =A0Apache mod_proxy used to be incapable
of client side TLS session caching--which causes a serious
performance impact on the communication link between reverse
proxy and backend if that link is TLS-reencrypted.

>
> My suggestion to Jorge would be to find such a product configuration a= nd
> demonstrate the attack against it (and file a bug with the vendor of > course).
>
> I don't see this as a real weakness in TLS itself either. Neverthe= less,
> I think might be something in scope here. Are there improvements to Do= S
> resistance which could be made in the scope of the IETF's TLS acti= vity?

When the topic of "client identity protection" came up on t= he TLS
mailing list, the suggestion was made to solve this by performing
a TLS renegotiation.

Today (after the TLS renegotiation vulnerability), many servers may
have unsolicited renegotiations disabled (and may continue to have
it disabled after adopting the rfc5746 solution). =A0Microsoft IIS
seems to have never supported unsolicited renegotiations so far --
it was primarily "added value" for TLS implementations that could=
perform TLS renegotiation "transparently", i.e. without requiring=
support from the (TLS) application caller to do renegotiation.

The results that TLS renegotiation might have on the client identity,
as seen by the server application, is sufficiently non-trivial that some discussion on this was added to the security considerations of rfc5746

=A0 http://tools.ietf.org/html/rfc5746#section-5


-Martin
__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--00151747b380737ef5049ec9ea1b-- From jorge@orchilles.com Fri Mar 18 16:18:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2AC3A6A8C for ; Fri, 18 Mar 2011 16:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqTd1dfy6HOY for ; Fri, 18 Mar 2011 16:18:32 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7215A3A6A6A for ; Fri, 18 Mar 2011 16:18:31 -0700 (PDT) Received: by bwz13 with SMTP id 13so4111758bwz.31 for ; Fri, 18 Mar 2011 16:20:00 -0700 (PDT) Received: by 10.204.136.1 with SMTP id p1mr1446689bkt.105.1300490400615; Fri, 18 Mar 2011 16:20:00 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id x6sm2510991bkv.0.2011.03.18.16.19.59 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:20:00 -0700 (PDT) Received: by fxm15 with SMTP id 15so4462861fxm.31 for ; Fri, 18 Mar 2011 16:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.6.73 with SMTP id 9mr1581679fay.131.1300490066952; Fri, 18 Mar 2011 16:14:26 -0700 (PDT) Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:14:26 -0700 (PDT) In-Reply-To: References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> Date: Fri, 18 Mar 2011 20:14:26 -0300 Message-ID: From: "Jorge A. Orchilles" To: Peter Gutmann Content-Type: multipart/alternative; boundary=00151747b3807982ff049ec9f0be Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:18:32 -0000 --00151747b3807982ff049ec9f0be Content-Type: text/plain; charset=ISO-8859-1 I have password protected the post on my blog because of this. I have confirmed this is an issue and many sites are vulnerable to DOS. I am reporting to vendor and vulnerable sites. Until then I will keep the post locked. You can email me individually for the password as this mailing list is public and I continue to update the post based on feedback and tests. Best Regards, Jorge Orchilles On Wed, Mar 16, 2011 at 3:54 AM, Peter Gutmann wrote: > Martin Rex writes: > > >A DoS-client could simply open new connections to the SSL server and > blindly > >fire away precompiled static SSL handshake messages, forcing the server to > do > >crypto work. You should be able to make most servers perform RSA decrypts > on > >arbitrary data, and a significant number to perform DHE computations. > > Exactly. You can do this with virtually no effort using netcat, I continue > to > be surprised that we've never seen this deployed in the wild (not wanting > to > give any hints to Anonymous, but LOIC is 1990s script-kiddie technology > compared to the DoSes you could use if you gave it a few minutes thought). > What makes it even worse is the Bleichenbacher-attack defense that says you > have to complete the handshake, at full crypto cost, even if it's obvious > that > you're just processing garbage. > > (Every time this comes up I'm tempted to release some quick tool to exploit > the problem, on the basis that if the good guys don't point it out now, the > bad guys will take advantage of it later. So far I've resisted the > temptation...). > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00151747b3807982ff049ec9f0be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have password protected the post on my blog because of this. I have confi= rmed this is an issue and many sites are vulnerable to DOS. I am reporting = to vendor and vulnerable sites. Until then I will keep the post locked. You= can email me individually for the password as this mailing list is public = and I continue to update the post based on feedback and tests.

Best Regards,
Jorge Orchilles



On Wed, Mar 16, 2011 at 3:54 AM, Peter G= utmann <p= gut001@cs.auckland.ac.nz> wrote:
Martin Rex <mrex@sap.c= om> writes:

>A DoS-client could simply open new connections to the SSL server and bl= indly
>fire away precompiled static SSL handshake messages, forcing the server= to do
>crypto work. =A0You should be able to make most servers perform RSA dec= rypts on
>arbitrary data, and a significant number to perform DHE computations.
Exactly. =A0You can do this with virtually no effort using netcat, I = continue to
be surprised that we've never seen this deployed in the wild (not wanti= ng to
give any hints to Anonymous, but LOIC is 1990s script-kiddie technology
compared to the DoSes you could use if you gave it a few minutes thought).<= br> What makes it even worse is the Bleichenbacher-attack defense that says you=
have to complete the handshake, at full crypto cost, even if it's obvio= us that
you're just processing garbage.

(Every time this comes up I'm tempted to release some quick tool to exp= loit
the problem, on the basis that if the good guys don't point it out now,= the
bad guys will take advantage of it later. =A0So far I've resisted the temptation...).

Peter.
__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--00151747b3807982ff049ec9f0be-- From jorge@orchilles.com Fri Mar 18 16:23:39 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39863A6A8C for ; Fri, 18 Mar 2011 16:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zypO2990JWAw for ; Fri, 18 Mar 2011 16:23:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5A9E33A6A6A for ; Fri, 18 Mar 2011 16:23:33 -0700 (PDT) Received: by fxm15 with SMTP id 15so4465023fxm.31 for ; Fri, 18 Mar 2011 16:25:02 -0700 (PDT) Received: by 10.223.69.131 with SMTP id z3mr399159fai.91.1300489881952; Fri, 18 Mar 2011 16:11:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id 17sm1574073far.19.2011.03.18.16.11.20 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:11:21 -0700 (PDT) Received: by fxm15 with SMTP id 15so4458824fxm.31 for ; Fri, 18 Mar 2011 16:11:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.30.77 with SMTP id t13mr1910851fac.112.1300489880317; Fri, 18 Mar 2011 16:11:20 -0700 (PDT) Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:11:20 -0700 (PDT) In-Reply-To: <4D7F95AA.8060007@extendedsubset.com> References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> <4D7F95AA.8060007@extendedsubset.com> Date: Fri, 18 Mar 2011 20:11:20 -0300 Message-ID: From: "Jorge A. Orchilles" To: Marsh Ray Content-Type: multipart/alternative; boundary=00151744876859ae7b049ec9e550 Cc: tls@ietf.org Subject: Re: [TLS] SSL Renegotiation DOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:23:39 -0000 --00151744876859ae7b049ec9e550 Content-Type: text/plain; charset=ISO-8859-1 I think a solution would be to only allow a certain amount of renegotiations per a given period. Best Regards, Jorge Orchilles On Tue, Mar 15, 2011 at 1:36 PM, Marsh Ray wrote: > On 03/15/2011 11:20 AM, Eric Rescorla wrote: > >> On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex wrote: >> >>> >>> I'm sorry, I completely fail to see what renegotiation has to do >>> with the DoS capability here. >>> [...] >>> >>> A DoS-client could simply open new connections to the SSL server >>> and blindly fire away precompiled static SSL handshake messages, >>> forcing the server to do crypto work. You should be able to make >>> most servers perform RSA decrypts on arbitrary data, and a >>> significant number to perform DHE computations. >>> >> > Yes, but take a step back from the code for a minute. This is a potential > problem, and the degree to which this is "not my (TLS's) problem" has to do > mainly with how close you are to the web server getting DoSed. > > > I tend to agree with Martin here: I don't see how this is >> significantly worse than separate connections. >> > > Presumably, somewhere there is a TCP-based load-balancing DoS prevention > system protecting a TLS server that allows client-initiated renegotiation. > This system may do a good job of resisting DoSes on the initial handshake > but not DoSes on renegotiation handshakes. > > My suggestion to Jorge would be to find such a product configuration and > demonstrate the attack against it (and file a bug with the vendor of > course). > > I don't see this as a real weakness in TLS itself either. Nevertheless, I > think might be something in scope here. Are there improvements to DoS > resistance which could be made in the scope of the IETF's TLS activity? > > For those of us wishing to promote the use of TLS/HTTPS in general, is > susceptibility to DoS a significant barrier to adoption? > > Look at it this way: If adding TLS increasing the susceptibility to DoS > attacks, could a DoS be used to compel a site operator to turn off > encryption? If so, is this not effectively an equivalent to a weakness in > TLS itself? > > > Arguably, it's better >> from the victim's perspective, since common implementations run each >> SSL/TLS connection in its own control thread (or process) and so the >> scheduler will try to fairly share between connections to some extent >> meaning that the single offending connection is bounded in terms of >> how much it can affect other users. >> > > That's an interesting point. > > - Marsh > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00151744876859ae7b049ec9e550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think a solution would be to only allow a certain amount of renegotiation= s per a given period.

Best Regards,
Jorge Orchilles=



On Tue, Mar 15, 2011 at 1:36 PM, Marsh R= ay <marsh@= extendedsubset.com> wrote:
On 03/15/2011 11:20 AM, Eric Rescorla wrote:
On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex<mrex@sap.com> =A0wrote:

I'm sorry, I completely fail to see what renegotiation has to do
with the DoS capability here.
[...]

A DoS-client could simply open new connections to the SSL server
and blindly fire away precompiled static SSL handshake messages,
forcing the server to do crypto work. =A0You should be able to make
most servers perform RSA decrypts on arbitrary data, and a
significant number to perform DHE computations.

Yes, but take a step back from the code for a minute. This is a potential p= roblem, and the degree to which this is "not my (TLS's) problem&qu= ot; has to do mainly with how close you are to the web server getting DoSed= .


I tend to agree with Martin here: I don't see how this is
significantly worse than separate connections.

Presumably, somewhere there is a TCP-based load-balancing DoS prevention sy= stem protecting a TLS server that allows client-initiated renegotiation. Th= is system may do a good job of resisting DoSes on the initial handshake but= not DoSes on renegotiation handshakes.

My suggestion to Jorge would be to find such a product configuration and de= monstrate the attack against it (and file a bug with the vendor of course).=

I don't see this as a real weakness in TLS itself either. Nevertheless,= I think might be something in scope here. Are there improvements to DoS re= sistance which could be made in the scope of the IETF's TLS activity?
For those of us wishing to promote the use of TLS/HTTPS in general, is susc= eptibility to DoS a significant barrier to adoption?

Look at it this way: If adding TLS increasing the susceptibility to DoS att= acks, could a DoS be used to compel a site operator to turn off encryption?= If so, is this not effectively an equivalent to a weakness in TLS itself?<= div class=3D"im">

Arguably, it's better
from the victim's perspective, since common implementations run each SSL/TLS connection in its own control thread (or process) and so the
scheduler will try to fairly share between connections to some extent
meaning that the single offending connection is bounded in terms of
how much it can affect other users.

That's an interesting point.

- Marsh

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

--00151744876859ae7b049ec9e550-- From pasi.sarolahti@iki.fi Tue Mar 22 01:59:54 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8DE3A67EA; Tue, 22 Mar 2011 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKEeDJcl39MR; Tue, 22 Mar 2011 01:59:53 -0700 (PDT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by core3.amsl.com (Postfix) with ESMTP id A93393A67E7; Tue, 22 Mar 2011 01:59:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id C10F81E1C6; Tue, 22 Mar 2011 11:01:24 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7DITdFZEkAoa; Tue, 22 Mar 2011 11:01:20 +0200 (EET) Received: from [192.168.0.15] (cs181059059.pp.htv.fi [82.181.59.59]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id B3BE81E139; Tue, 22 Mar 2011 11:01:20 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Mar 2011 11:01:19 +0200 Message-Id: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi> To: tls@ietf.org, tsv-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 22 Mar 2011 07:46:45 -0700 Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org, tsv-dir@ietf.org Subject: [TLS] tsv-dir review of draft-ietf-tls-dtls-heartbeat-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 08:59:54 -0000 Hi, I've reviewed this document as part of the transport area directorate's = ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the = document's authors for their information and to allow them to address = any issues raised. Please always CC tsv-dir@ietf.org if you reply to or = forward this review. Path MTU discovery: There should be more about how PMTUD is done than the one sentence in = the Intro, probably somewhere near section 4 (about when to send the = padded packets, how to set the DF bit in HeartbeatRequest packets with = padding, probably also mentioning about handling the possibly resulting = ICMP, etc.). You could also refer to the appropriate section in the main = DTLS spec. Reliability & congestion control: Using DTLS' simple timeout scheme seems ok here (but it would be = additional help for the reader to give exact reference, e.g., [RFC 4347, = Section 4.2.4]) With TLS there shouldn't be any congestion control issues, but you might = want to discuss the relationship of this mechanism and TCP's keepalive = messages. Is TCP's mechanism sufficient, and if not, why not? If DTLS is used over a congestion controlled transport protocol, there = shouldn't be any issues for congestion control. Also DTLS/UDP seems ok from congestion control viewpoint, because the = document allows at most one HeartbeatRequest message to be in flight at = a (round-trip) time, and for unacknowledged Heartbeats it mandates the = use of the timeout algorithm that applies exponential backoff. (You = might want to use an extra sentence mentioning that for these reasons = the scheme handles congestion control appropriately) For clarity, the document could say a bit more about when the = HeartbeatRequest is in flight, for example: "There MUST NOT be more than one HeartbeatRequest message in flight = at a time." =3D=3D> "There MUST NOT be more than one HeartbeatRequest message in flight = at a time. HeartbeatRequest message is considered to be in flight until HeartbeatResponse is received, or until the retransmit timer expires" I think an additional guideline about how often to send keepalive = packets would be useful. The intent hardly is to send a heartbeat every = round-trip time, even if that is given as the upper bound, right? = Perhaps something like: * SHOULD only be sent after an idle period (that is at least multiple = RTTs long), AND * MUST NOT be sent if there are pending unacknowledged data in flight. = (If the HeartbeatRequest is the only message type expected to generate = response, this would just restate what was already said above. But if = there are also other packets waiting to be replied, then this might be = useful clarification.) - Pasi From mrex@sap.com Tue Mar 22 17:57:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12BA3A67F4 for ; Tue, 22 Mar 2011 17:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jfdhz05Uv-s for ; Tue, 22 Mar 2011 17:57:31 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4674B3A67BD for ; Tue, 22 Mar 2011 17:57:30 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2N0wvc5015793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2011 01:59:02 +0100 (MET) From: Martin Rex Message-Id: <201103230058.p2N0wuwJ022566@fs4113.wdf.sap.corp> To: shenson@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Wed, 23 Mar 2011 01:58:56 +0100 (MET) In-Reply-To: <4D5A8107.8060402@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Feb 15, 11 01:35:03 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] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 00:57:32 -0000 Dr Stephen Henson wrote: > > Using SHA-2 algorithms isn't possible in TLS 1.1 and earlier with RSA as they > hard code the SHA1+MD5 signature. "not possible in TLS 1.1 and earlier" is an inappropriate determination. The two possibilities to do this in TLSv1.0 and TLSv1.1 are - a specification of an RSA-based TLS cipher suite, intuitively one that already uses SHA-256 for the data MAC, to produce the "digitally signed struct" with SHA-256 instead of MD5+SHA1 - a specification of a TLS extension for the purpose of using SHA-256 instead of MD5+SHA1 for the "digitally signed struct" probably along with a replacement of the "default TLS PRF" which is based on an P_MD5() XOR P_SHA1() in TLSv1.0&v1.1 with a PRF based on P_SHA256() such as in TLSv1.2 -Martin PS: in case anyone is wondering "why not implement TLSv1.2"? - the definition of the signature algorithms extension in rfc-5246 is pretty much fouled up that I wouldn't count to obtain a sensible level of interoperability with it. - the clients uncertainty about the hash that will be allowed/required for the "digitally signed struct" of the ClientVerify handshake message hash - the protocol version intolerance for TLSv1.2 in the installed base seems worse than the TLS extension intolerance, i.e. A TLS record with protocol_version { 0x03, 0x00 } carrying a ClientHello with client_version { 0x03, 0x03 } is not advisable for clients that do not have application-level dirty hacks to close the connection after a failed TLS handshake and restart a new connection with a less "sophisiticated" ClientHello. From n.mavrogiannopoulos@gmail.com Wed Mar 23 03:52:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D950A3A6806; Wed, 23 Mar 2011 03:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZQ0r8sX8idm; Wed, 23 Mar 2011 03:52:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B97583A6800; Wed, 23 Mar 2011 03:52:21 -0700 (PDT) Received: by iyi12 with SMTP id 12so9864775iyi.31 for ; Wed, 23 Mar 2011 03:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hxLfnsoSUeqlydcF4i+I3HV09TOYa1FBsMRS51pJ5YM=; b=SEK8oxWThoxdBNyUw5boIXTVE6sYNXoO4fPBe9+3cQunv0gbmV0nrgJe4tVBXgP/1W tMl7/qA7ujV0WZLMMwrUrvjN2YyX98NlQ7AhvSB3CuJdXHZhn+pGTHO45DY1MLVSq4B9 Nr9dZYLGm0DK/ryZD/x/d8xUgxJ7/jjpxn7jQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Rfb2iLVmSS+nnBfvthfuRDj4rKSCnRfLoSIzErctj1mTW0Ijz66NL8FzhcEGER+wkp cXLbiB2qB0XeYEPb+B6Br/1BM8AhkgVHfVe49nCBiJ53g7Gr+ERojqal5M9+pvidqnE7 ARUZGsnSJTwcqsKwEG0qKlGGtwEnZW+fiU+aw= MIME-Version: 1.0 Received: by 10.42.247.200 with SMTP id md8mr1024174icb.111.1300877635437; Wed, 23 Mar 2011 03:53:55 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.231.42.202 with HTTP; Wed, 23 Mar 2011 03:53:55 -0700 (PDT) In-Reply-To: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi> References: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi> Date: Wed, 23 Mar 2011 11:53:55 +0100 X-Google-Sender-Auth: CAGLGRBIcGWuBWgPfletsCR4fL0 Message-ID: From: Nikos Mavrogiannopoulos To: Pasi Sarolahti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org, tls@ietf.org, tsv-dir@ietf.org Subject: Re: [TLS] tsv-dir review of draft-ietf-tls-dtls-heartbeat-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 10:52:23 -0000 My main comment on this draft is that there is not enough rationale for the added functionality to DTLS. In the introduction it is mentioned: "The only mechanism available at the DTLS layer to figure out if a peer is still alive is performing a costly renegotiation. If the application uses unidirectional traffic there is no other way." However transports like UDP that DTLS lies on, have the same issue. There is no way to check out if peer is alive. Why should DTLS solve that issue, that is typically solved at the application level? [0] regards, Nikos [0]. I saw arguments that it is essencial to protocols like IPFIX, such as draft-mentz-ipfix-dtls-recommendations-02, but IMO they are not really convincing that DTLS is the layer to solve those issues. On Tue, Mar 22, 2011 at 10:01 AM, Pasi Sarolahti wr= ote: > Hi, > > I've reviewed this document as part of the transport area directorate's o= ngoing effort to review key IETF documents. These comments were written pri= marily for the transport area directors, but are copied to the document's a= uthors for their information and to allow them to address any issues raised= . Please always CC tsv-dir@ietf.org if you reply to or forward this review. > > > Path MTU discovery: > > There should be more about how PMTUD is done than the one sentence in the= Intro, probably somewhere near section 4 (about when to send the padded pa= ckets, how to set the DF bit in HeartbeatRequest packets with padding, prob= ably also mentioning about handling the possibly resulting ICMP, etc.). You= could also refer to the appropriate section in the main DTLS spec. > > > Reliability & congestion control: > > Using DTLS' simple timeout scheme seems ok here (but it would be addition= al help for the reader to give exact reference, e.g., [RFC 4347, Section 4.= 2.4]) > > With TLS there shouldn't be any congestion control issues, but you might = want to discuss the relationship of this mechanism and TCP's keepalive mess= ages. Is TCP's mechanism sufficient, and if not, why not? > > If DTLS is used over a congestion controlled transport protocol, there sh= ouldn't be any issues for congestion control. > > Also DTLS/UDP seems ok from congestion control viewpoint, because the doc= ument allows at most one HeartbeatRequest message to be in flight at a (rou= nd-trip) time, and for unacknowledged Heartbeats it mandates the use of the= timeout algorithm that applies exponential backoff. (You might want to use= an extra sentence mentioning that for these reasons the scheme handles con= gestion control appropriately) > > For clarity, the document could say a bit more about when the HeartbeatRe= quest is in flight, for example: > =C2=A0 "There MUST NOT be more than one HeartbeatRequest message in fligh= t at > =C2=A0 a time." > =C2=A0 =3D=3D> > =C2=A0 "There MUST NOT be more than one HeartbeatRequest message in fligh= t at > =C2=A0 a time. HeartbeatRequest message is considered to be in flight unt= il > =C2=A0 HeartbeatResponse is received, or until the retransmit timer expir= es" > > I think an additional guideline about how often to send keepalive packets= would be useful. The intent hardly is to send a heartbeat every round-trip= time, even if that is given as the upper bound, right? Perhaps something l= ike: > > * SHOULD only be sent after an idle period (that is at least multiple RTT= s long), AND > > * MUST NOT be sent if there are pending unacknowledged data in flight. (I= f the HeartbeatRequest is the only message type expected to generate respon= se, this would just restate what was already said above. But if there are a= lso other packets waiting to be replied, then this might be useful clarific= ation.) > > - Pasi > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From wookshin@kddilabs.jp Thu Mar 31 17:48:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EE33A69C9 for ; Thu, 31 Mar 2011 17:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka1bvzD12ydA for ; Thu, 31 Mar 2011 17:48:52 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 070693A6A8F for ; Thu, 31 Mar 2011 17:48:52 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 07D0417481EA; Fri, 1 Apr 2011 09:50:31 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYL5zuPlL8+o; Fri, 1 Apr 2011 09:50:30 +0900 (JST) Received: from ist.sec.kddilabs.jp (ist.sec.kddilabs.jp [IPv6:2001:200:601:d00:2e0:81ff:fe28:b57f]) by mandala.kddilabs.jp (Postfix) with ESMTP id CEB3917481D8; Fri, 1 Apr 2011 09:50:29 +0900 (JST) Received: from ohpato-t61.west-2f.cn.kddilabs.jp by ist.sec.kddilabs.jp (8.14.1/8.12.11) with ESMTP id p310ogVc027505; Fri, 1 Apr 2011 09:50:44 +0900 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: tls@ietf.org Date: Fri, 01 Apr 2011 09:50:29 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Wook Shin" Organization: KDDI Message-ID: User-Agent: Opera Mail/11.01 (Win32) X-Antivirus: avast! (VPS 110331-1, 04/01/2011), Outbound message X-Antivirus-Status: Clean Cc: Yutaka Miyake , Shinsaku Kiyomoto Subject: Re: [TLS] I-D Action:draft-kiyomoto-kcipher2-tls-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 00:48:53 -0000 Hello all, We have submitted the Internet draft that defines cipher suites to support KCipher-2 in TLS. KCipher-2 is a fast and secure stream cipher developed in 2007 and it is now used in commercial applications in Japan. The security and performance of KCipher-2 have been evaluated through the CRYPTREC project which evaluates and monitors the security of e-Government recommended ciphers. KCipher-2 also has been submitted to the ISO standard (ISO 18033) and it's in the final committee draft. Our draft can be found at http://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-tls-00.txt We'd be really happy if the draft can be adopted by the working group. Please leave us your comments and advice. Best regards, Wook Shin Information Security Laboratory, KDDI R&D Laboratories, Inc.