From yaronf.ietf@gmail.com Thu Sep 1 00:01:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5322F21F87D6 for ; Thu, 1 Sep 2011 00:01:43 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqS3QqjOzpxr for ; Thu, 1 Sep 2011 00:01:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF021F87C9 for ; Thu, 1 Sep 2011 00:01:42 -0700 (PDT) Received: by wyg8 with SMTP id 8so1250610wyg.31 for ; Thu, 01 Sep 2011 00:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xM1cIYZXs/101vs4FNcNGjnt0l0wU2KrPz7IJrFeQ2g=; b=LJ8iZm6/IJRTgZQIva8xuSHGuFc6lxRJtAjLUhLXnIzoi1PPX2XXDZ7pz2vKgjfKBl 9fSFCggEY7PkkyIITfa1Kub04gVyaWEX/sFxoJsHZA1AKme7vqiiZhqy5ScEIw3P0NvP XJprOxRUg+fp0FUi6suLRsyRr2qbGHwo2GOMc= Received: by 10.227.28.4 with SMTP id k4mr1239975wbc.21.1314860593879; Thu, 01 Sep 2011 00:03:13 -0700 (PDT) Received: from [10.0.0.6] (93-172-1-150.bb.netvision.net.il [93.172.1.150]) by mx.google.com with ESMTPS id fy13sm250530wbb.5.2011.09.01.00.03.12 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 00:03:13 -0700 (PDT) Message-ID: <4E5F2E2E.2020803@gmail.com> Date: Thu, 01 Sep 2011 10:03:10 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Yoav Nir References: <4E5E8DD9.40604@gmail.com> <395BFC9B-5B8C-431A-A09A-922C1C088422@checkpoint.com> In-Reply-To: <395BFC9B-5B8C-431A-A09A-922C1C088422@checkpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 07:01:43 -0000 DNS is not crossing any protocol layers, but I agree your proposal is simpler. Adding a time-to-live to the alert/announcement (with e.g. max 1 hour) would probably solve the problem. Yaron On 09/01/2011 09:07 AM, Yoav Nir wrote: > On Aug 31, 2011, at 10:39 PM, Yaron Sheffer wrote: > >> Here's a suggestion to avoid the records that announce the proxy. It's >> not ideal, but it may be easier to implement/deploy than an intrusive proxy. >> >> We could use some sort of discovery mechanism to detect the presence of >> the proxy. Then the client queries the proxy for its certificate hash >> (with a well known URL), and you can assume the proxy will in fact be >> there. The discovery process itself is *not* security-sensitive, and we >> can use caching. >> >> Two options are PAC (http://en.wikipedia.org/wiki/Proxy_auto-config and >> http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) and DNS >> SRV records. The former is commonly deployed in enterprises, the latter >> is much simpler to standardize and implement, and architecturally cleaner. >> > All these involve a potentially lengthy discovery process, and more inter-layer communications than I'd like. > > The common use case for a middlebox is for when I'm "inside" the company perimeter. In the place where I work, there's WLAN reception on all floors, but none in the stairwell. Going upstairs with a smartphone involves roaming from the WLAN to the 3G network and back to the WLAN. As far as the middlebox is concerned, you're going from "inside" to "outside" and back "inside". > > There is an obvious way for discovery: the client sends hashes of the middlebox certificates in the extension. If the middlebox hash is missing, the middlebox will interfere by sending an alert with its hash and a URL for getting its certificate. The harder question is how to discover that the proxy is gone (or rather, off-path). It's not quite as important, because sending encrypted keys to a non-existant middlebox should not cause a lot of damage, but we don't want to keep accumulating middleboxes. > From n.mavrogiannopoulos@gmail.com Thu Sep 1 04:49:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1921F8BF9 for ; Thu, 1 Sep 2011 04:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3MBk2GpLbSO for ; Thu, 1 Sep 2011 04:49:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0321F8BEF for ; Thu, 1 Sep 2011 04:49:40 -0700 (PDT) Received: by wyg8 with SMTP id 8so1456442wyg.31 for ; Thu, 01 Sep 2011 04:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6hCnb7MIKN8jTnKpdVQjVidjih8hz07Bd/38diXK28s=; b=dVXk5OV6cbEat//3gpDl3iaGnKb9k6oR3mLNwvW8/wkea1kWCHRqgcVf6XNXsO1dFh AadI60P9LSXERXwqNMDa+omGUUTyh9amX1Z50EmRalEWExHzqgz28TRoJItdRXjk6yzY KEvO2gfbCR8vOR8XqhQr8QXkIhpkmFZJpAg3M= Received: by 10.216.176.17 with SMTP id a17mr80874wem.72.1314877869260; Thu, 01 Sep 2011 04:51:09 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id p18sm449181wbh.4.2011.09.01.04.51.07 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 04:51:08 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E5F71AC.5090900@gnutls.org> Date: Thu, 01 Sep 2011 13:51:08 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 11:49:42 -0000 On 08/22/2011 07:53 PM, Dirk Balfanz wrote: > Dear TLS-WG, > > I few weeks ago I presented a proposal for an "origin-bound certificates" > TLS extension at IETF 81. It's much easier to understand what this extension > is trying to accomplish when presented in a broader context of web > authentication (which I tried to give in Quebec), so I put together a little > web site that is supposed to do just that for those who couldn't be at the > IETF meeting: http://browserauth.net (This took me a little while, hence the > delay in sending out the I-D). [...] > All feedback is welcome, of course, but if you can't think of anything to > comment on, I have a couple particular questions: I like the proposal. As far as I understand you try to fix the usability problem of using multiple certificates for different sites. This is similar to an SSH-style authentication for users. As a side-effect pseudonymity can be achieved. Some minor comments. * In http://www.browserauth.net/tls-client-authentication you mention the inability to log-out as one reason that TLS client authentication fails. However this is not addressed by OBC if I understand correctly. (to be honest I think that the inability to log-out is just a UI problem. TLS authentication does not need to imply log-in. You might have buttons login and logout that will log the user in and out even if TLS with authentication was used) * Why you require a critical X.509 extension for that? (I also don't like the IA5String... why not UTF8?) * After having read the proposal the name OBC was clear to me. However before reading it, the name didn't give any clue (to me) of the proposal. > - in Section 2.1.1 we currently stipulate that the client include the origin > of the origin-bound cert as part of the OBC X.509 extension. When we > implemented this, we didn't really know what to do with that data on the > server side. If the client also uses TLS-SNI, then we could imagine > comparing the SNI and OBC origins in some manner on the server side, but > there isn't really a vehicle to signal an error back to the client saying > "your SNI and OBC origins don't match". Similarly, we could perhaps at some > higher layer compare the HTTP "Host" header with the OBC origin, but then > again - what do you do when they don't match? I'd send a TLS alert or do nothing. What does this check add? > Respond with a 400 at the HTTP > layer? An alternative to the current language in the I-D would be to simply > mark the cert as origin-bound, but without putting the origin itself into > the cert. Any thoughts? I don't like having the origin in the certificate as a critical extension. regards, Nikos From Michael.Tuexen@lurchi.franken.de Thu Sep 1 13:02:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737A21F9775 for ; Thu, 1 Sep 2011 13:02:26 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6Izx3IN0GG5 for ; Thu, 1 Sep 2011 13:02:25 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 5497821F9761 for ; Thu, 1 Sep 2011 13:02:25 -0700 (PDT) Received: from [192.168.1.195] (p508FDF41.dip.t-dialin.net [80.143.223.65]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 11F891C0C0BD9; Thu, 1 Sep 2011 22:03:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Thu, 1 Sep 2011 22:03:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dtls-heartbeat@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 20:02:26 -0000 On Sep 1, 2011, at 2:51 AM, Eric Rescorla wrote: Hi Eric, thanks a lot for the comments. See my comments in-line. Accepted changes will be included in rev 03, which I will submit when the WG LC is closed. Best regards Michael > S 1.1. > "and their adoptions" -> "and their adaptations" Done. >=20 > "as described" -> described Done. >=20 >=20 > S 3. > "Like the ChangeCipherSpec message,.... can arrive at any time" > I guess a CSS can in principle arrive at any time, but it's not = permitted at > any time. You couldn't send it as the first message of a connection, > for instance. I'm not sure there is a specific statement to this = effect > in 5246, but it seems implicit in S 7.3. I think we can just say: A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. >=20 > "MUST stop the retransmission timer" -> "MUST stop the DTLS = retransmission > timer" perhaps? Done. >=20 > "HeartbeatRequest messages from older epochs must be discarded" > I would clarify that this is DTLS only since TLS has no epochs. Changed to: In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be discarded. >=20 >=20 > S 4. > You should probably clarify why the padding length is what it is. OK. It reads now: The padding is additional arbitrary content which MUST be ignored by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS. The length of the type field = is 1 byte and the length of the payload_length is 2. Therefore, the padding_length is TLSPlaintext.length - payload_length - 3 for TLS and DTLSPlaintext.length - payload_length - 3 for DTLS. >=20 >=20 > S 5.1 > We'll need to update the 4347 citation to DTLS 1.2 Done. >=20 > 5.2. > "allows this check" -> "allows a check" perhaps? Done. >=20 > "multiple round trip times" > You should probably recommend some multiple. I can't provide a concrete number. The text is based on a suggestion of = the transport area directorate. The tradeoff is clear: The sooner you send a HB, the sooner you will = figure out that the peer is gone. However, the more traffic you are sending. =46rom a congestion control point of view, you can send a HB per RTT. = But this is covered by the requirement that you can only have one HB in flight. >=20 > S 6. > Specification required is a pretty low bar for a field this small... = Perhaos > Expert Review would be better. Changed. >=20 >=20 > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From ekr@rtfm.com Thu Sep 1 13:25:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BD221F9771 for ; Thu, 1 Sep 2011 13:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRrzx9tVQCYS for ; Thu, 1 Sep 2011 13:25:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE84621F9773 for ; Thu, 1 Sep 2011 13:25:34 -0700 (PDT) Received: by wyg8 with SMTP id 8so1910275wyg.31 for ; Thu, 01 Sep 2011 13:27:08 -0700 (PDT) Received: by 10.227.10.206 with SMTP id q14mr279322wbq.33.1314908828260; Thu, 01 Sep 2011 13:27:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.3.5 with HTTP; Thu, 1 Sep 2011 13:26:48 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 1 Sep 2011 13:26:48 -0700 Message-ID: To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-dtls-heartbeat@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 20:25:35 -0000 Works for me. I believe this document is ready for advancement. -Ekr [As an individual] On Thu, Sep 1, 2011 at 1:03 PM, Michael T=FCxen wrote: > On Sep 1, 2011, at 2:51 AM, Eric Rescorla wrote: > > Hi Eric, > > thanks a lot for the comments. See my comments in-line. > Accepted changes will be included in rev 03, which I will > submit when the WG LC is closed. > > Best regards > Michael >> S 1.1. >> "and their adoptions" -> "and their adaptations" > Done. >> >> "as described" -> described > Done. >> >> >> S 3. >> "Like the ChangeCipherSpec message,.... can arrive at any time" >> I guess a CSS can in principle arrive at any time, but it's not permitte= d at >> any time. You couldn't send it as the first message of a connection, >> for instance. I'm not sure there is a specific statement to this effect >> in 5246, but it seems implicit in S 7.3. > I think we can just say: > A HeartbeatRequest message can arrive almost at any time during the > lifetime of a connection. >> >> "MUST stop the retransmission timer" -> "MUST stop the DTLS retransmissi= on >> timer" perhaps? > Done. >> >> "HeartbeatRequest messages from older epochs must be discarded" >> I would clarify that this is DTLS only since TLS has no epochs. > Changed to: > In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be > discarded. >> >> >> S 4. >> You should probably clarify why the padding length is what it is. > OK. It reads now: > The padding is additional arbitrary content which MUST be ignored > by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length > for TLS and DTLSPlaintext.length for DTLS. The length of the type field i= s 1 > byte and the length of the payload_length is 2. Therefore, the > padding_length is TLSPlaintext.length - payload_length - 3 for TLS and > DTLSPlaintext.length - payload_length - 3 for DTLS. >> >> >> S 5.1 >> We'll need to update the 4347 citation to DTLS 1.2 > Done. >> >> 5.2. >> "allows this check" -> "allows a check" perhaps? > Done. >> >> "multiple round trip times" >> You should probably recommend some multiple. > I can't provide a concrete number. The text is based on a suggestion of t= he transport > area directorate. > > The tradeoff is clear: The sooner you send a HB, the sooner you will figu= re out > that the peer is gone. However, the more traffic you are sending. > > From a congestion control point of view, you can send a HB per RTT. But t= his is covered > by the requirement that you can only have one HB in flight. >> >> S 6. >> Specification required is a pretty low bar for a field this small... Per= haos >> Expert Review would be better. > Changed. >> >> >> -Ekr >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From Michael.Tuexen@lurchi.franken.de Thu Sep 1 13:46:40 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68CD21F8E02 for ; Thu, 1 Sep 2011 13:46:40 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HnVtG70iE7B for ; Thu, 1 Sep 2011 13:46:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 72FCE21F8DE7 for ; Thu, 1 Sep 2011 13:46:27 -0700 (PDT) Received: from [192.168.1.195] (p508FDF41.dip.t-dialin.net [80.143.223.65]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 956F81C0C0BD9; Thu, 1 Sep 2011 22:48:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Thu, 1 Sep 2011 22:47:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dtls-heartbeat@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 20:46:40 -0000 On Sep 1, 2011, at 10:26 PM, Eric Rescorla wrote: > Works for me. >=20 > I believe this document is ready for advancement. Thanks for the quick feedback. Best regards Michael >=20 > -Ekr >=20 > [As an individual] >=20 > On Thu, Sep 1, 2011 at 1:03 PM, Michael T=FCxen > wrote: >> On Sep 1, 2011, at 2:51 AM, Eric Rescorla wrote: >>=20 >> Hi Eric, >>=20 >> thanks a lot for the comments. See my comments in-line. >> Accepted changes will be included in rev 03, which I will >> submit when the WG LC is closed. >>=20 >> Best regards >> Michael >>> S 1.1. >>> "and their adoptions" -> "and their adaptations" >> Done. >>>=20 >>> "as described" -> described >> Done. >>>=20 >>>=20 >>> S 3. >>> "Like the ChangeCipherSpec message,.... can arrive at any time" >>> I guess a CSS can in principle arrive at any time, but it's not = permitted at >>> any time. You couldn't send it as the first message of a connection, >>> for instance. I'm not sure there is a specific statement to this = effect >>> in 5246, but it seems implicit in S 7.3. >> I think we can just say: >> A HeartbeatRequest message can arrive almost at any time during the >> lifetime of a connection. >>>=20 >>> "MUST stop the retransmission timer" -> "MUST stop the DTLS = retransmission >>> timer" perhaps? >> Done. >>>=20 >>> "HeartbeatRequest messages from older epochs must be discarded" >>> I would clarify that this is DTLS only since TLS has no epochs. >> Changed to: >> In case of DTLS, HeartbeatRequest messages from older epochs SHOULD = be >> discarded. >>>=20 >>>=20 >>> S 4. >>> You should probably clarify why the padding length is what it is. >> OK. It reads now: >> The padding is additional arbitrary content which MUST be ignored >> by the receiver. The length of a HeartbeatMessage is = TLSPlaintext.length >> for TLS and DTLSPlaintext.length for DTLS. The length of the type = field is 1 >> byte and the length of the payload_length is 2. Therefore, the >> padding_length is TLSPlaintext.length - payload_length - 3 for TLS = and >> DTLSPlaintext.length - payload_length - 3 for DTLS. >>>=20 >>>=20 >>> S 5.1 >>> We'll need to update the 4347 citation to DTLS 1.2 >> Done. >>>=20 >>> 5.2. >>> "allows this check" -> "allows a check" perhaps? >> Done. >>>=20 >>> "multiple round trip times" >>> You should probably recommend some multiple. >> I can't provide a concrete number. The text is based on a suggestion = of the transport >> area directorate. >>=20 >> The tradeoff is clear: The sooner you send a HB, the sooner you will = figure out >> that the peer is gone. However, the more traffic you are sending. >>=20 >> =46rom a congestion control point of view, you can send a HB per RTT. = But this is covered >> by the requirement that you can only have one HB in flight. >>>=20 >>> S 6. >>> Specification required is a pretty low bar for a field this small... = Perhaos >>> Expert Review would be better. >> Changed. >>>=20 >>>=20 >>> -Ekr >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>=20 >>=20 >=20 From balfanz@google.com Fri Sep 2 10:20:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5025C21F8BA7 for ; Fri, 2 Sep 2011 10:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.143 X-Spam-Level: X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DafrSqrsBUKN for ; Fri, 2 Sep 2011 10:20:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id D13B621F8C18 for ; Fri, 2 Sep 2011 10:20:08 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p82HLaRP009997 for ; Fri, 2 Sep 2011 10:21:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314984100; bh=uXw4U2gER5ekVbFWVhJz+oKYAb8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qf7kVM5ima8IiuI78hOqfQ18ENrd8PKpuFpnoINyuzkAx5XWSTLDpFGcIwFb8hatF TpAklM6uLuUHJjhM7aIHA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=If3C5FcEaiO9qJP6hdMj97nrGSJ1G2dXoNaDtp9xn3NEEvQA/m1hmZWvHn33GWQIR n6qPdOLzIY685/FUzTe4g== Received: from ywb5 (ywb5.prod.google.com [10.192.2.5]) by hpaq14.eem.corp.google.com with ESMTP id p82HKmQt003724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Sep 2011 10:21:35 -0700 Received: by ywb5 with SMTP id 5so3049539ywb.12 for ; Fri, 02 Sep 2011 10:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rAh/xR609jUSgzWAedcYoWvMqwbbWRojOTApgSaGi4=; b=XLFV5sNVp8424l6x82b9JYDRvIeN4umsXTIMHETWe/Wpa01Wy06xsqoATfFq75GWNd ru28EZwlQbi+8Wxj5KRA== Received: by 10.90.164.17 with SMTP id m17mr1050342age.152.1314984094953; Fri, 02 Sep 2011 10:21:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.164.17 with SMTP id m17mr1050332age.152.1314984094414; Fri, 02 Sep 2011 10:21:34 -0700 (PDT) Received: by 10.90.56.4 with HTTP; Fri, 2 Sep 2011 10:21:34 -0700 (PDT) In-Reply-To: <4E5F71AC.5090900@gnutls.org> References: <4E5F71AC.5090900@gnutls.org> Date: Fri, 2 Sep 2011 10:21:34 -0700 Message-ID: From: Dirk Balfanz To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=0016362846b4d5367f04abf8978c X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 17:20:10 -0000 --0016362846b4d5367f04abf8978c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 1, 2011 at 4:51 AM, Nikos Mavrogiannopoulos wrote: > On 08/22/2011 07:53 PM, Dirk Balfanz wrote: > >> Dear TLS-WG, >> >> I few weeks ago I presented a proposal for an "origin-bound certificates" >> TLS extension at IETF 81. It's much easier to understand what this >> extension >> is trying to accomplish when presented in a broader context of web >> authentication (which I tried to give in Quebec), so I put together a >> little >> web site that is supposed to do just that for those who couldn't be at the >> IETF meeting: http://browserauth.net (This took me a little while, hence >> the >> delay in sending out the I-D). >> > [...] > > All feedback is welcome, of course, but if you can't think of anything to >> comment on, I have a couple particular questions: >> > > I like the proposal. As far as I understand you try to fix the usability > problem of using multiple certificates for different sites. This is similar > to an SSH-style authentication for users. As a side-effect pseudonymity can > be achieved. Some minor comments. > > * In http://www.browserauth.net/**tls-client-authenticationyou mention the inability to log-out as one reason that TLS client > authentication fails. However this is not addressed by OBC if I understand > correctly. (to be honest I think that the inability to log-out is just a UI > problem. TLS authentication does not need to imply log-in. You might have > buttons login and logout that will log the user in and out even if TLS with > authentication was used) > The site where I wrote the documentation - browserauth.net - is an example for this. There is a sign-in link at the bottom of each page. Are you saying that with TLS Client Auth, the server would require a certificate from the client, and the user would have to decide upfront whether or not to supply a certificate. Then, when the user gives no certificate or a "wrong" certificate, there would be no sign-in link on the site (but it would still render), but when the "right" certificate is given by the user, then the server would give the user a sign-in link on the page? At that point, the sign-in link isn't really about signing in. It's more a "you already know who I am, please give me some edit controls on this page"-link. Also, note that the user had to decide whether or not to provide a certificate before they saw the page. With TLS-OBC, you have the normal cookie model. The first time you go to the site, you have no cookies. It's up to the server to decide whether or not it can give you a meaningful UI in that case (browserauth.net decides that it can). Then, when it's time to reveal to the server who you are, you click on the sign-in link, and eventually end up with a cookie that you send to the server, which will allow it to identify you, and draw a "logged-in" state UI. I totally agree that this a UI issue - a pretty subtle one. But I think that TLS Client Auth will dictate a different UI from what we're used to today, whereas TLS-OBC with cookies will allow us to stick to the same UIs we have today. > > * Why you require a critical X.509 extension for that? (I also don't like > the IA5String... why not UTF8?) > The critical extension is there so that these certificates can't be used out of context. For example, we require the server to check that the extension is there, or else reject the certificate. We should fix the IA5String. I forget why we picked that - I think it was something like Adam Barth's web origin spec not defining a UTF8 serialization of web origins when we wrote our draft or something like that. I agree it should allow unicode. A separate question is whether that string (the origin) should be in the cert to begin with. I take it that your inclination would be to not include it, which is what I'm also considering now. Dirk. > > * After having read the proposal the name OBC was clear to me. However > before reading it, the name didn't give any clue (to me) of the proposal. > > > - in Section 2.1.1 we currently stipulate that the client include the >> origin >> of the origin-bound cert as part of the OBC X.509 extension. When we >> implemented this, we didn't really know what to do with that data on the >> server side. If the client also uses TLS-SNI, then we could imagine >> comparing the SNI and OBC origins in some manner on the server side, but >> there isn't really a vehicle to signal an error back to the client saying >> "your SNI and OBC origins don't match". Similarly, we could perhaps at >> some >> higher layer compare the HTTP "Host" header with the OBC origin, but then >> again - what do you do when they don't match? >> > > I'd send a TLS alert or do nothing. What does this check add? > > > Respond with a 400 at the HTTP >> layer? An alternative to the current language in the I-D would be to >> simply >> mark the cert as origin-bound, but without putting the origin itself into >> the cert. Any thoughts? >> > > I don't like having the origin in the certificate as a critical extension. > > regards, > Nikos > ______________________________**_________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/**listinfo/tls > --0016362846b4d5367f04abf8978c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 1, 2011 at 4:51 AM, Nikos Ma= vrogiannopoulos <nmav@gnutls.org> wrote:
On 08/22/2011 07:53 PM, Dirk Balfanz wrote:
Dear TLS-WG,

I few weeks ago I presented a proposal for an "origin-bound certificat= es"
TLS extension at IETF 81. It's much easier to understand what this exte= nsion
is trying to accomplish when presented in a broader context of web
authentication (which I tried to give in Quebec), so I put together a littl= e
web site that is supposed to do just that for those who couldn't be at = the
IETF meeting: http://b= rowserauth.net (This took me a little while, hence the
delay in sending out the I-D).
[...]

All feedback is welcome, of course, but if you can't think of anything = to
comment on, I have a couple particular questions:

I like the proposal. As far as I understand you try to fix the usability pr= oblem of using multiple certificates for different sites. This is similar t= o an SSH-style authentication for users. As a side-effect pseudonymity can = be achieved. Some minor comments.

* In http://www.browserauth.net/tls-client-authentication you mention the inability to log-out as one reason that TLS client authen= tication fails. However this is not addressed by OBC if I understand correc= tly. (to be honest I think that the inability to log-out is just a UI probl= em. TLS authentication does not need to imply log-in. You might have button= s login and logout that will log the user in and out even if TLS with authe= ntication was used)

The site where I wrote the documentation -= browserauth.net -= is an example for this. There is a sign-in link at the bottom of each page= . Are you saying that with TLS Client Auth, the server would require a cert= ificate from the client, and the user would have to decide upfront whether = or not to supply a certificate. Then, when the user gives no certificate or= a "wrong" certificate, there would be no sign-in link on the sit= e (but it would still render), but when the "right" certificate i= s given by the user, then the server would give the user a sign-in link on = the page? At that point, the sign-in link isn't really about signing in= . It's more a "you already know who I am, please give me some edit= controls on this page"-link. Also, note that the user had to decide w= hether or not to provide a certificate before they saw the page.=A0

With TLS-OBC, you have the normal cookie model. The fir= st time you go to the site, you have no cookies. It's up to the server = to decide whether or not it can give you a meaningful UI in that case (browserauth.net decide= s that it can). Then, when it's time to reveal to the server who you ar= e, you click on the sign-in link, and eventually end up with a cookie that = you send to the server, which will allow it to identify you, and draw a &qu= ot;logged-in" state UI.

I totally agree that this a UI issue - a pretty subtle = one. But I think that TLS Client Auth will dictate a different UI from what= we're used to today, whereas TLS-OBC with cookies will allow us to sti= ck to the same UIs we have today.
=A0

* Why you require a critical X.509 extension for that? (I also don't li= ke the IA5String... why not UTF8?)

The = critical extension is there so that these certificates can't be used ou= t of context. For example, we require the server to check that the extensio= n is there, or else reject the certificate. We should fix the IA5String. I = forget why we picked that - I think it was something like Adam Barth's = web origin spec not defining a UTF8 serialization of web origins when we wr= ote our draft or something like that. I agree it should allow unicode.

A separate question is whether that string (the origin)= should be in the cert to begin with. I take it that your inclination would= be to not include it, which is what I'm also considering now.

Dirk.

=A0

* After having read the proposal the name OBC was clear to me. However befo= re reading it, the name didn't give any clue (to me) of the proposal.

- in Section 2.1.1 we currently stipulate that the client include the origi= n
of the origin-bound cert as part of the OBC X.509 extension. When we
implemented this, we didn't really know what to do with that data on th= e
server side. If the client also uses TLS-SNI, then we could imagine
comparing the SNI and OBC origins in some manner on the server side, but there isn't really a vehicle to signal an error back to the client sayi= ng
"your SNI and OBC origins don't match". Similarly, we could p= erhaps at some
higher layer compare the HTTP "Host" header with the OBC origin, = but then
again - what do you do when they don't match?

I'd send a TLS alert or do nothing. What does this check add?


Respond with a 400 at the HTTP
layer? An alternative to the current language in the I-D would be to simply=
mark the cert as origin-bound, but without putting the origin itself into the cert. Any thoughts?

I don't like having the origin in the certificate as a critical extensi= on.

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

--0016362846b4d5367f04abf8978c-- From n.mavrogiannopoulos@gmail.com Sun Sep 4 05:41:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663621F8581 for ; Sun, 4 Sep 2011 05:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrW7iFUWLO8S for ; Sun, 4 Sep 2011 05:41:31 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC0E021F8538 for ; Sun, 4 Sep 2011 05:41:30 -0700 (PDT) Received: by wwf5 with SMTP id 5so2805148wwf.13 for ; Sun, 04 Sep 2011 05:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8o4P5CMfPrjO5qx3ff7vsc+7OQYlay7JSik3j9ieSTM=; b=aOQrBXJxVYJAapZ7jvrYrpEnA+ttcY0xPCAN3UtsWPKRbx6izxk3tbAzXVwU6FyOgl 5IbmdM8JvQFql7tmmZ58qOlm3QPJmKpyHqv9KUDdQSGRX+cvcmVW36zWX75LrBdapkyx S85Hjlftm2rf4k5o1j8e2GlL+aI8l/2N5mHR8= Received: by 10.227.10.67 with SMTP id o3mr2856692wbo.26.1315140191401; Sun, 04 Sep 2011 05:43:11 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id fo14sm4784567wbb.19.2011.09.04.05.43.09 (version=SSLv3 cipher=OTHER); Sun, 04 Sep 2011 05:43:10 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E637262.3040007@gnutls.org> Date: Sun, 04 Sep 2011 14:43:14 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12 MIME-Version: 1.0 To: Dirk Balfanz References: <4E5F71AC.5090900@gnutls.org> 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-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 12:41:32 -0000 On 09/02/2011 07:21 PM, Dirk Balfanz wrote: >> * In http://www.browserauth.net/**tls-client-authenticationyou mention the inability to log-out as one reason that TLS client >> authentication fails. However this is not addressed by OBC if I understand >> correctly. (to be honest I think that the inability to log-out is just a UI >> problem. TLS authentication does not need to imply log-in. You might have >> buttons login and logout that will log the user in and out even if TLS with >> authentication was used) > The site where I wrote the documentation - browserauth.net - is an example > for this. There is a sign-in link at the bottom of each page. Are you saying > that with TLS Client Auth, the server would require a certificate from the > client, and the user would have to decide upfront whether or not to supply a > certificate. Then, when the user gives no certificate or a "wrong" > certificate, there would be no sign-in link on the site (but it would still > render), but when the "right" certificate is given by the user, then the > server would give the user a sign-in link on the page? At that point, the > sign-in link isn't really about signing in. It's more a "you already know > who I am, please give me some edit controls on this page"-link. Also, note > that the user had to decide whether or not to provide a certificate before > they saw the page. > With TLS-OBC, you have the normal cookie model. The first time you go to the > site, you have no cookies. It's up to the server to decide whether or not it > can give you a meaningful UI in that case (browserauth.net decides that it > can). Then, when it's time to reveal to the server who you are, you click on > the sign-in link, and eventually end up with a cookie that you send to the > server, which will allow it to identify you, and draw a "logged-in" state > UI. > I totally agree that this a UI issue - a pretty subtle one. But I think that > TLS Client Auth will dictate a different UI from what we're used to today, > whereas TLS-OBC with cookies will allow us to stick to the same UIs we have > today. Indeed, but you still use client certificate authentication. The difference is that there is no trusted party certifying the client's name and the 1-1 mapping to certificates with sites. > The critical extension is there so that these certificates can't be used out > of context. For example, we require the server to check that the extension > is there, or else reject the certificate. [...] > A separate question is whether that string (the origin) should be in the > cert to begin with. I take it that your inclination would be to not include > it, which is what I'm also considering now. I find your point above quite interesting (preventing (re)use in different contexts). It might be worth keeping it. regards, Nikos From anders.rundgren@telia.com Sun Sep 4 09:41:11 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAD521F861A for ; Sun, 4 Sep 2011 09:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJaz18C2+5sH for ; Sun, 4 Sep 2011 09:41:10 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7030721F8520 for ; Sun, 4 Sep 2011 09:41:10 -0700 (PDT) Received: from [192.168.0.203] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F010D5E5E; Sun, 4 Sep 2011 18:42:50 +0200 Message-ID: <4E63AA87.5070602@telia.com> Date: Sun, 04 Sep 2011 18:42:47 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Dirk Balfanz References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 16:41:11 -0000 I have probably not understood the TLS-OBC proposal but one part spurred my interest and that was that apparently (?) an application eventually ends-up with a session cookie rather than the horrible (at least from a web context seen... ), TLS session scheme. If this assumption is correct, I think it would be a pity "patching" the HTTPS protocol without being able to also use the above with traditional client-certificates. In fact, I think this proposal will go pretty much nowhere unless it does. If I OTOH have go the session-stuff wrong, please just ignore my ignorant comments. FWIW, I have developed an app-level CCA (Client-Certificate Authentication) mechanism derived from the numerous proprietary solutions out there. http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/webauth.xsd If you come up with a generic solution, I will gladly retire it! Traditional TLS-CCA sucks, and logout is by no means "a subtle UI problem"; it goes to the core. Anders From n.mavrogiannopoulos@gmail.com Sun Sep 4 10:30:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D7921F8661 for ; Sun, 4 Sep 2011 10:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgs5rfuOFzkO for ; Sun, 4 Sep 2011 10:30:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9877221F856A for ; Sun, 4 Sep 2011 10:30:29 -0700 (PDT) Received: by wyg8 with SMTP id 8so3816771wyg.31 for ; Sun, 04 Sep 2011 10:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ohT1bTcPnBZFv5RLpoFIiSdWoMGOnZs1LUJtygcNsgw=; b=xeEhaqqT0YZV7LgULvOddoRUUHkDJXORvHUMGt7+8P3hiEouDZf2HHcJpqNcRChptL 4r8YpDBuECVyojC9Kq9OVNuZ48OqefzVsULwK8Nh7GiJDXW1Qo54cDeB7kE+eg8sDRyN zKk72C4FryDbVB05mnVX1uM8hkWOmZZEC+a7c= Received: by 10.227.162.201 with SMTP id w9mr3007800wbx.28.1315157531036; Sun, 04 Sep 2011 10:32:11 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id n12sm5521352wbp.7.2011.09.04.10.32.09 (version=SSLv3 cipher=OTHER); Sun, 04 Sep 2011 10:32:10 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E63B624.4090509@gnutls.org> Date: Sun, 04 Sep 2011 19:32:20 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12 MIME-Version: 1.0 To: tls@ietf.org References: <4E63AA87.5070602@telia.com> In-Reply-To: <4E63AA87.5070602@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 17:30:30 -0000 On 09/04/2011 06:42 PM, Anders Rundgren wrote: > If I OTOH have go the session-stuff wrong, please just ignore my > ignorant comments. FWIW, I have developed an app-level CCA > (Client-Certificate Authentication) mechanism derived from the > numerous proprietary solutions out there. > http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/webauth.xsd > >If you come up with a generic solution, I will gladly retire it! > Traditional TLS-CCA sucks, and logout is by no means "a subtle UI > problem"; it goes to the core. The problem is layer mixing. I believe you understand that TLS authentication is about authentication of the TLS session and not the HTTP session which is on a layer above. If you naively use the TLS authentication for HTTP authentication you have the issues current applications face. TLS-OBC as I understand it, ties better the HTTP and TLS certificate authentication to prevent the issues currently seen. The advantage is that it re-uses the existing mechanisms. I cannot read your approach in the xml file, but I understand that you moved authentication to the application layer. This is an alternative approach. regards, Nikos From anders.rundgren@telia.com Sun Sep 4 12:30:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670A521F85F1 for ; Sun, 4 Sep 2011 12:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvboREPfa-7U for ; Sun, 4 Sep 2011 12:30:02 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 98A7021F85C0 for ; Sun, 4 Sep 2011 12:30:02 -0700 (PDT) Received: from [192.168.0.203] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E526612004D64EA; Sun, 4 Sep 2011 21:31:21 +0200 Message-ID: <4E63D206.7020207@telia.com> Date: Sun, 04 Sep 2011 21:31:18 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4E63AA87.5070602@telia.com> <4E63B624.4090509@gnutls.org> In-Reply-To: <4E63B624.4090509@gnutls.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 19:30:03 -0000 Nikos, Maybe I was a bit unclear. I'm not suggesting mine or the gazillion of similar solutions as an alternative to TLS-OBC since they address entirely different markets. However, I'm asking if an enhanced TLS-OBC could replace them by increasing the scope of the proposal. I'm not enough of a expert in TLS too see if it is possible or a good idea, I just want to point out that there is a great need for a better HTTPS CCA. Otherwise the mentioned solutions would not exist. In fact, I believe there may be more users of app-level HTTPS CCA than there users of "genuine" HTTPS CCA. Regards, Anders . On 2011-09-04 19:32, Nikos Mavrogiannopoulos wrote: > On 09/04/2011 06:42 PM, Anders Rundgren wrote: > >> If I OTOH have go the session-stuff wrong, please just ignore my >> ignorant comments. FWIW, I have developed an app-level CCA >> (Client-Certificate Authentication) mechanism derived from the >> numerous proprietary solutions out there. >> http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/webauth.xsd >> >> If you come up with a generic solution, I will gladly retire it! >> Traditional TLS-CCA sucks, and logout is by no means "a subtle UI >> problem"; it goes to the core. > > The problem is layer mixing. I believe you understand that TLS > authentication is about authentication of the TLS session and not the > HTTP session which is on a layer above. If you naively use the TLS > authentication for HTTP authentication you have the issues current > applications face. TLS-OBC as I understand it, ties better the HTTP and > TLS certificate authentication to prevent the issues currently seen. The > advantage is that it re-uses the existing mechanisms. > > I cannot read your approach in the xml file, but I understand that you > moved authentication to the application layer. This is an alternative > approach. > > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From gswaru@rediffmail.com Sun Sep 4 21:23:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4821F877B for ; Sun, 4 Sep 2011 21:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.385 X-Spam-Level: **** X-Spam-Status: No, score=4.385 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_80=2, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl9Ynvz6yQCA for ; Sun, 4 Sep 2011 21:23:34 -0700 (PDT) Received: from rediffmail.com (f4mail-235-128.rediffmail.com [202.137.235.128]) by ietfa.amsl.com (Postfix) with SMTP id D664021F8760 for ; Sun, 4 Sep 2011 21:23:33 -0700 (PDT) Received: (qmail 32581 invoked by uid 510); 5 Sep 2011 04:25:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=UymliGClxpVAY0WmC28eoDeeqkdS5rbkgJnmAT25jH5BOZDuo0RRiqbpRL5qf0lFxgF10H5LooZhf8SmVKwgCpD031FhNMGaq2clPsK+w78RNij9Ee2eq/qT1+f2QN7NpUQBLe+CgVbOabAhL0kO5KihVYbY7Nmoj5GSdpzSKx0= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150204.4E644F2A.0037,ss=1,re=0.000,fgs=0 Date: 5 Sep 2011 04:25:13 -0000 Message-ID: <20110905042513.32561.qmail@f4mail-235-128.rediffmail.com> MIME-Version: 1.0 To: "tls@ietf.org" , "Adam Langley " Received: from unknown 115.252.157.156 by rediffmail.com via HTTP; 05 Sep 2011 04:25:11 -0000 Sender: gswaru@rediffmail.com From: gswaru@rediffmail.com Content-Type: multipart/alternative; boundary="=_4c1c30d38231572bfa7fd0edd28a7344" Subject: [TLS] =?utf-8?q?TLS_Next_Proto_Negotiation?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gswaru@rediffmail.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, 05 Sep 2011 04:23:35 -0000 --=_4c1c30d38231572bfa7fd0edd28a7344 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, Thanks Adam, for confirming that we need to use the Next Protocol handshake message in plain for FINISH computation. Now that this message is 32 byte padded, do we need to use the padbytes also for finish calcualtion or use only the message until padbytes only. Thanks and Regards, Swarupa.G --=_4c1c30d38231572bfa7fd0edd28a7344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
Hi,
Thanks Adam, for confirming that we need to use the Next Protocol hand= shake message in plain for FINISH computation. Now that this message is 32 = byte padded, do we need to use the padbytes also for finish calcualtion or = use only the message until padbytes only.
Thanks and Regards,
Swarupa.G


Treat yourself at a restauran= t, spa, resort and much more with Redi= ff Deal ho jaye! --=_4c1c30d38231572bfa7fd0edd28a7344-- From agl@google.com Mon Sep 5 07:10:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52321F8B89 for ; Mon, 5 Sep 2011 07:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8ag4zpQEDUo for ; Mon, 5 Sep 2011 07:10:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B67F221F8B86 for ; Mon, 5 Sep 2011 07:10:23 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p85EBudx000559 for ; Mon, 5 Sep 2011 07:11:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315231917; bh=yZSFy4rCb3iwUgZcXxnw5vC2aRI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xqGjvUfo1UzJp44DYO9kTtTNeT84lmv7N7BR6LTQU62XVXgCzmQ5VrurIgl0Vi/8g pCryLKM928yWGRQCT2UaQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=Lo3q//Yxho2hRzl5Nze0Gh1l8fSTH4MGggMdshlXmqmtEaIMvnGrb1PRcrGrztPKa Jikwl9vO+2lBADED2++7A== Received: from iacb35 (iacb35.prod.google.com [10.12.104.35]) by hpaq13.eem.corp.google.com with ESMTP id p85EBsDq005769 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Sep 2011 07:11:55 -0700 Received: by iacb35 with SMTP id b35so7680963iac.36 for ; Mon, 05 Sep 2011 07:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=m9Dw9a3BCJkwLM6m+4z8U+UyaocJMWR5lBltanWFchQ=; b=wGI5Fro5xMU7Tcdx2nZkFs2XHubjMKppRbBL6g2vjQWSLz0FzWzJWYKGEAgDCbmlEY 6NVCFayIt97MNRK82KWg== Received: by 10.231.65.72 with SMTP id h8mr7936157ibi.47.1315231909130; Mon, 05 Sep 2011 07:11:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.65.72 with SMTP id h8mr7936052ibi.47.1315231905495; Mon, 05 Sep 2011 07:11:45 -0700 (PDT) Received: by 10.231.19.137 with HTTP; Mon, 5 Sep 2011 07:11:45 -0700 (PDT) In-Reply-To: <20110905042513.32561.qmail@f4mail-235-128.rediffmail.com> References: <20110905042513.32561.qmail@f4mail-235-128.rediffmail.com> Date: Mon, 5 Sep 2011 10:11:45 -0400 Message-ID: From: Adam Langley To: gswaru@rediffmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Next Proto Negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 14:10:25 -0000 On Mon, Sep 5, 2011 at 12:25 AM, wrote: > Thanks Adam, for confirming that we need to use the Next Protocol handsha= ke message in plain for FINISH computation. Now that this message is 32 byt= e padded, do we need to use the padbytes also for finish calcualtion or use= only the message until padbytes only. The pad bytes are included. Cheers AGL From mrex@sap.com Tue Sep 6 13:03:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661221F8E2F for ; Tue, 6 Sep 2011 13:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.719 X-Spam-Level: X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQqirSVwaRJ1 for ; Tue, 6 Sep 2011 13:03:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB88121F8E06 for ; Tue, 6 Sep 2011 13:03:14 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p86K4xs9028281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 22:04:59 +0200 (MEST) From: Martin Rex Message-Id: <201109062004.p86K4wM9020670@fs4113.wdf.sap.corp> To: chris@randomnonce.org (Chris Richardson) Date: Tue, 6 Sep 2011 22:04:58 +0200 (MEST) In-Reply-To: from "Chris Richardson" at Aug 23, 11 07:25:26 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-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 20:03:20 -0000 Chris Richardson wrote: > > Should that be a MUST, or at least a SHOULD? If OBC has been > negotiated, why would a CA-signed cert be used? The original design behind TLS client certs is exactly the idea of per-server client certs. Each Service operator would run a CA and issue certificates to clients, and the TLS client would be able to automatically select an appropriate client cert based on CA listed in the certification_authorities list sent by the TLS server. Btw. in SSLv3 and TLSv1.0 the protocol does _NOT_ allow to send a Certificate Request handshake message with an empty certification_authorities element, although there are numerous defective SSL&TLS server implementations out there that ignore that protocol requirement, so TLS clients usually do not break on such broken server behaviour. Our TLS client will unconditionally send back an "SSL no certificate alert" (for SSLv3) or and empty Certificate handshake message (TLSv1.0) when receiving an invalid CertificateRequest handshake message with an empty certificate_authorities list. Some extremely broken TLS server implementations (I've heard complaints about a big network components vendor) even go as far as completely lacking a possibility to configure CA certificates for the certificate_authorities field of the CertificateRequest handshake message, which essentially means that they do support TLS client certificates _at_all_ (in a fashion compliant to the TLS protocol spec). -Martin From pgladstone@cisco.com Wed Sep 7 05:28:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5824821F8C33 for ; Wed, 7 Sep 2011 05:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dMPWCym5ZNl for ; Wed, 7 Sep 2011 05:28:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BBECB21F8C09 for ; Wed, 7 Sep 2011 05:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=8694; q=dns/txt; s=iport; t=1315398609; x=1316608209; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=HIzwVu/9e2ZtG++DWCJ27xjym/8CCRMTuzNhoPmHR4k=; b=LsRRT03km3SfXAz/TKx5Nb7UzBF6BFgkYNHRQe79KZ+w3oQv2Hz9Cm+6 ScN9C4xpuVs6Go/a//PyjkeWTOcm+i4Df9ymoDs60ZTp60sVQbHeMh3R3 feX5VRivd5im+Pf911EwygexWIBd0+5OrnG0gwsclCPSxd48cUWBiKA7O 8=; X-Files: smime.p7s : 4899 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgHAC1jZ06tJV2d/2dsb2JhbABAA4RVlFOOQniBRgEBAQEDEgEQVQ8CCxgJFgsCAgIHAwIBAgEJPBADBgIBAR6gagGMN5IYAoNdgXuBEQSOJ4ULhRKMHw X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="p7s'?scan'208";a="19747754" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Sep 2011 12:30:09 +0000 Received: from [161.44.106.139] (dhcp-161-44-106-139.cisco.com [161.44.106.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p87CU8I6001884 for ; Wed, 7 Sep 2011 12:30:08 GMT Message-ID: <4E6763CF.7070802@cisco.com> Date: Wed, 07 Sep 2011 08:30:07 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org References: <4E57FC4B.3080809@gmail.com> <4E5805EC.6000904@fifthhorseman.net> In-Reply-To: <4E5805EC.6000904@fifthhorseman.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030704030505030209050103" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 12:28:20 -0000 This is a cryptographically signed message in MIME format. --------------ms030704030505030209050103 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 8/26/2011 4:45 PM, Daniel Kahn Gillmor wrote: > Since HTTP redirects can only be done in an HTTP header, the middlebox > would need to buffer all HTTP content before relaying it to the User > Agent, in case "bad" material was found at the end. > > I don't think either of these use cases are valuable, certainly not > valuable enough to warrant allowing middleboxes to violate the integrit= y > guarantees of TLS. > > The problem with not allowing modification of the data stream is that=20 the middlebox only has one choice left -- to abort the connection. This=20 provides a less than satisfactory experience to the end user -- and some = file transfer managers will simply retry the connection (as they think=20 that the connection was accidentally aborted). There is another reason to release the authentication keys -- and that=20 is to prove to the middlebox that the correct encryption key was=20 released. Otherwise, the client can release a bogus encryption key, and=20 the middlebox has no way of determining what is being transferred. [Of=20 course, the client would release the correct key initially to cover the=20 HTTP request, and would then rekey the connection with the server and=20 release an incorrect key for the response body. ] Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------ms030704030505030209050103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaAD AgECAhBluzNhw6CDObOmDguxgJDVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwNjAwMDAwMFoXDTEyMDkwNTIzNTk1 OVowJTEjMCEGCSqGSIb3DQEJARYUcGdsYWRzdG9uZUBjaXNjby5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8ShP963c4uAJcGoHC2JCwJKJth79tIXQ2aVrtbK1tN5vi eX+0nKzylBxgLOfpyPuYxGuya1GNLXPXCnIp8sYpy6AlaQw2laBBODjl13Yjgnv/jlpVmE4d AwhRqWdcCH0WkrKniZiFEr72GUfhemnFNXILC5D82IiDOjqQ4guzO+ll/OoyYNBwx7ux4WAH hebTSrXcciAq/TqZnc8HlimFC6kS53kQdNd/MsYWNKVSj/60WxaHqFAjeRDopmZ4IDR2GvgX W7N4UIzXIcpJW8DC/KktfMxo/DXhi64RY3mLE0cxepA/D0T94uVwKXHneE9Q+GNhcNBIE4hT NrcsSlNbAgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAd BgNVHQ4EFgQUEB9ztHyHGmanfNM9BLyVUI828nEwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQE AwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRwZ2xhZHN0 b25lQGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAASu4Jrf2J6VFo8sJU04WDaW5P3wa jd5RSUWyhAgC/Doog4YlFvfQInnsMiEh069+czqynhigU8ahGOwzRCvZC044sPWU53wtz0Wp jzz9I/2ekKDceJr+Neu1tcIrH2eqrjwE0Mn+pbsUw1eUn7G7bq1B8gT6TAEx3mrrxXCr2mkQ VABiT1L1rkkcGpvV5ls040AU5Oe9bPPgtlWh7qjcaXBeOsYu5EAqRtbP+w7LeVfs0W0vXG1O h9O3X2FCHqZrQTh5gj3by4p0bssKCMKk/pELMzi5uHfB2OZhG4gLxTqwkVVXXcfCt2s/Womp 4TeiuQm/aozNUjlJQSfDYKaaETGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDVMAkGBSsOAwIaBQCgggI4 MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDkwNzEyMzAw N1owIwYJKoZIhvcNAQkEMRYEFNEHezmeNMbsYUAV6sDAvRpIJGepMF8GCSqGSIb3DQEJDzFS MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDV MIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZbszYcOggzmzpg4LsYCQ1TANBgkqhkiG9w0BAQEFAASCAQBKWuGO0DRY ZtOdADYfx70N/4cNF2z7BU05aDXgs8yq7gsfFHPkc2WZ1XXr+oEHqd9AfeF7kWuovSv9Taik QS1NOmJzEpHTlnnOYlAIojD+Al2r5zwqFMuPccCRKQGr9xrYNV+0zU96lDJpFR5Ll6ucu1op 3AZy48BNL5OtHJ7zrVg/Mo05HvLpu6zeHENAC3eRGshlI6sgmm5LUME7RtYuYzsHxmsrK5kM Tpf1l4lxXjLPcg+g6HI3iV7PKpnVAvrXigJcUuvh9xDBANr0W49J+w8zTVHahGjd40C0Q904 RPGkvAc7xd+MQREdufVCZ2GPBj3auwQN9TM42hQy4EI8AAAAAAAA --------------ms030704030505030209050103-- From mrex@sap.com Wed Sep 7 08:40:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA3721F8C6A for ; Wed, 7 Sep 2011 08:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.72 X-Spam-Level: X-Spam-Status: No, score=-9.72 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMCbA6CYl-A6 for ; Wed, 7 Sep 2011 08:40:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBCC21F8C3A for ; Wed, 7 Sep 2011 08:40:20 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p87Fg6im017085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 17:42:06 +0200 (MEST) From: Martin Rex Message-Id: <201109071542.p87Fg51m028141@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 7 Sep 2011 17:42:05 +0200 (MEST) In-Reply-To: <201107290006.p6T06BD0012180@fs4113.wdf.sap.corp> from "Martin Rex" at Jul 29, 11 02:06:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:40:22 -0000 Sorry for the hardly-usable URL back then ($$-download of the computer magazine article). I didn't have the magazine with me when I wrote that EMail. The magazine article "iOpener" is a exploration of how easy it is to access data on an Apple iPhone or iPad1, once you get your hands on it, with publicly available information and tools. It is based on this research and tools: Jean-Baptiste Bédrune, Jean Sigwald: iPhone data protection in depth http://conference.hackinthebox.org/hitbsecconf2011ams/materials/D2T2%20-%20Jean-Baptiste%20Be%cc%81drune%20&%20Jean%20Sigwald%20-%20iPhone%20Data%20Protection%20in%20Depth.pdf that was presented on the hack-in-the-box 2011 conference Tools: http://code.google.com/p/iphone-dataprotection/ http://code.google.com/p/networkpx/downloads/list -Martin Martin Rex wrote: > > > > > This attitude was OK before we entered the "Google- and Apple-age". > > It's an entirely different ball-game now! > > Smart phones are already attractive targets for theft even with no > additional digital gems added by the end user. Significantly > further increasing the attractiveness of that target for both, > digital theft through malware and physical theft of the smartphone, > does not seem overly sensible to me. > > From what I read in the german computer magazine, > http://www.heise.de/artikel-archiv/ct/2011/15/154_kiosk > > all existing iPhones and iPad1s seem to have the vulnerability > in the Boot-Rom (i.e. Hardware, no possibility to fix by software update) > that might enable thieves to bypass many if not all of the assumed > "protections" and retrieve your private data. > > > -Martin > From nico@cryptonector.com Wed Sep 7 14:53:36 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9D921F8C5F for ; Wed, 7 Sep 2011 14:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxyVqBWnUayv for ; Wed, 7 Sep 2011 14:53:36 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 341F021F8C57 for ; Wed, 7 Sep 2011 14:53:36 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 5C077678071 for ; Wed, 7 Sep 2011 14:55:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=MRcOz0uUleUrNZHEeo0TbiYg3OFlfXchnDxmAKGyPSM0 iVDwwFpXOAlTKXaOPsdaxLziuM1fZgGoDdUPRkiLB/qq9VDVt8QFjeHHwUxnaMES /ABigFTsqsyR/W11B+6BVpBv4G01SYjekEgf4sXovwZlTfpN6aRQwX6WGicfXxg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=mteorucE9vZGzlf8egMl7S/K760=; b=EzEQ2oCbRL0 XT43K07cd0rIKVsmoN4ETxC7Sz5Ul80MBmXb25MV25G2cPCoy3CgBeLyac/mTnPN yAIhpjkJfKxTezoGRjHLZTnoeJ61CB2X2DnyysV/BAtdNsM4GHtguV9zS1RxtfX6 H81JzHYobC87fLOpb9ipJ2awYglq1fgw= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 0531C678083 for ; Wed, 7 Sep 2011 14:55:01 -0700 (PDT) Received: by vxi29 with SMTP id 29so119671vxi.31 for ; Wed, 07 Sep 2011 14:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.229 with SMTP id bz5mr1595206vdb.77.1315432497522; Wed, 07 Sep 2011 14:54:57 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 7 Sep 2011 14:54:57 -0700 (PDT) In-Reply-To: <4E52ACCC.20303@telia.com> References: <4E52ACCC.20303@telia.com> Date: Wed, 7 Sep 2011 16:54:57 -0500 Message-ID: From: Nico Williams To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 21:53:36 -0000 On Mon, Aug 22, 2011 at 2:23 PM, Anders Rundgren wrote: > I'm a little hesitant (from a deployment point-of-view) about mucking > around in the TLS layer. =C2=A0Wouldn't it be possible to achieve this > anyway web-only functionality with more "webbish" methods? =C2=A0Not as > clean but it would probably be easier rolling out. I'm certainly a fan of webbish methods, as you put it. For an example of this see http://tools.ietf.org/html/draft-williams-rest-gss-00 Nico -- From nico@cryptonector.com Wed Sep 7 15:15:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990EB21F8DFD for ; Wed, 7 Sep 2011 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkyy21brhhmH for ; Wed, 7 Sep 2011 15:15:46 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0021F8DD2 for ; Wed, 7 Sep 2011 15:15:45 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id AF21D2C806D for ; Wed, 7 Sep 2011 15:17:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=IEcu+iOTEzA2NwzAROiC2 r/ezs8yUD8VQebalZ0/PvctAWfQ0BCOUPFZZOcA1WmPuA3QNbhCqMfWEfRlrvRu2 lCcRoTGIpf0Pae/RdcF+Co+mB0k0ZLujx+ifQDD0kbr/ewbWvwn+KWol0mY1ANKW ObM7lXKhFshPHNCvIhJoM4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+ixgoTRBwwSES4Bs0EMl 5XUp8Q8=; b=YuCQ7ycwxaShjjyPcsfz4VDTZFFX65RCDi1AABCpGVr7aNgPZH6e dgFFzlz2Gepn3t5Jjtr6DCOKH37CldZxzIxOPP4SWXRORuWp2QHqXmfCscn6cSeJ RdXeOvqXujAp4+Zwo1wZJ0469IWZPd1OL6EOWMoPT/6EX4MpHQgdDYA= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 813972C806C for ; Wed, 7 Sep 2011 15:17:30 -0700 (PDT) Received: by vxi29 with SMTP id 29so137042vxi.31 for ; Wed, 07 Sep 2011 15:17:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.116.2 with SMTP id k2mr2101426vcq.74.1315433849948; Wed, 07 Sep 2011 15:17:29 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 7 Sep 2011 15:17:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 17:17:29 -0500 Message-ID: From: Nico Williams To: Dirk Balfanz Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 22:15:46 -0000 I think the cookie hardening aspect of this is the key feature of your proposal. Alternatively you'd need a certificate enrollment facility by which to associate one of these certs with a user account. Either way, other user authentication mechanisms are still required (always at login time w/o cert enrollment, or just at initial cert enrollment time, but with a more complete key rollover mechanism required to avoid having to authenticate again at key rollover time. I'd also note that in all TLS user cert schemes TLS session resumption (without server-side state) becomes even more important for performance. I believe logout is always a difficult problem. Specifically: proving to one's peer that state has been torn down is difficult. But it is more difficult when logout requires layer crossing. In this case, because cookies would still be used for web session identification, you'd avoid the difficulties of implementing logout in other TLS user cert applications. This is good. The main benefit of binding cookies to user certs rather than server certs is that cookie leakage is made much less harmful: leaked cookies would be useful for nothing more than traffic analysis provided that cookies bear no sensitive information in cleartext. This is a very good thing. Looking at usability, my main concern is that we still need to address user authentication issues, and/or user cert enrollment and key rollover. I'm not a fan of TLS user certs for user authentication: we'll end up building SACRED-like protocols to deal with the need to use certs from multiple devices, and so on. But the HTTP cookie protection aspect of TLS-OBC is quite enticing. Nico -- From nico@cryptonector.com Wed Sep 7 15:17:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D0621F8DF8 for ; Wed, 7 Sep 2011 15:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.761 X-Spam-Level: X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPF69R5C-neX for ; Wed, 7 Sep 2011 15:17:39 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4C421F8DF7 for ; Wed, 7 Sep 2011 15:17:39 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 8B1CA1F0081 for ; Wed, 7 Sep 2011 15:19:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 556481F0078 for ; Wed, 7 Sep 2011 15:19:29 -0700 (PDT) Received: by vxi29 with SMTP id 29so138581vxi.31 for ; Wed, 07 Sep 2011 15:19:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.36 with SMTP id ef4mr507440vdb.211.1315433968750; Wed, 07 Sep 2011 15:19:28 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 7 Sep 2011 15:19:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 17:19:28 -0500 Message-ID: From: Nico Williams To: Dirk Balfanz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 22:17:39 -0000 On Wed, Sep 7, 2011 at 5:17 PM, Nico Williams wrote= : > The main benefit of binding cookies to user certs rather than server > certs is that cookie leakage is made much less harmful: leaked cookies > would be useful for nothing more than traffic analysis provided that > cookies bear no sensitive information in cleartext. =C2=A0This is a very > good thing. I should add that binding in some server (site, really) identification information is also important, as a hedge against the risk that a client might reuse one of these self-signed certs with other servers! Nico -- From nico@cryptonector.com Thu Sep 8 12:46:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A4D21F8744 for ; Thu, 8 Sep 2011 12:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWyd+zs7ZkdE for ; Thu, 8 Sep 2011 12:46:37 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 157F021F873A for ; Thu, 8 Sep 2011 12:46:36 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1B5D4202038 for ; Thu, 8 Sep 2011 12:48:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s= cryptonector.com; b=jiP8BG/UWEQHBPmAzM+gC2mEi/fpBlw1xKUD+B4HiUZ8 mSPdEs5UlMW8eG3GClnu/9xCwBBiJxVpFIbIWUKj+RsN/8m0+oy+GYJF4GdO0rqh HDoNhwHdXTCEXtOmwdDmTg74HSm+ogrZyuG3B5lFiQfxrNByBhfCJHrgGsTtkAs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=CbJbp7EV2XWF6CIDjgejMWp0Q8c=; b=hf4DftFaywg vkv03J4SQ0af6rB8HFFa5LGqkjXHGeFX3sbbWZehmS9hAFIqDoi60qirAKt1Eu79 iE/nXwd4joiwif+Er2jZ0M4HDSXBx82ys8caCPXp7yttDaeJsezimdrCyvKoKLp9 uT3tqYMzoPJi8MEzJFp97jGTyNY6n8Aw= Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id C4EDF20203C for ; Thu, 8 Sep 2011 12:47:49 -0700 (PDT) Received: by pzk33 with SMTP id 33so5552644pzk.18 for ; Thu, 08 Sep 2011 12:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.0.34 with SMTP id 2mr1670872pbb.399.1315511269302; Thu, 08 Sep 2011 12:47:49 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 12:47:49 -0700 (PDT) Date: Thu, 8 Sep 2011 14:47:49 -0500 Message-ID: From: Nico Williams To: Dirk Balfanz Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: [TLS] TLS-OBC and channel-bound cookies as a new TLS CB type (Re: TLS-OBC proposal) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 19:46:37 -0000 One way to think about what you're proposing is this: you're proposing a new TLS session identification and resumption facility and a new channel binding type whose CB data that are unique for each session but the same for all connections in that session. The session ID here would be the client's ephemeral (private key thrown away between sessions) self-signed cert. Session resumption here would come in two forms: proper TLS session resumption, and new TLS sessions using an existing OBC. For the latter case there'd be neither server-side state nor state cookies -- clever! A digest of an OBC would be the CB data for the new CB type. I find your idea very clever. The only downside is that we'd need two additional PK operations for all full handshakes. Note that we could instead use a new TLS CB type named, say, tls-session-unique, defined as follows: the CB data will be as for tls-unique for a TLS session's full handshake. This would avoid the need to negotiate the use/non-use of OBC, and it'd avoid the need to add a pair of PK operations. But it'd also make the system more dependent on TLS session resumption. I suspect that given a choice of "more PK ops" vs "session resumption becomes more important" then people will prefer the former. Note too that what you propose fits RFC 5056 just fine. We could and should register a new CB type for OBC if OBC progresses. Nico -- From balfanz@google.com Thu Sep 8 14:20:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A7721F8B1B for ; Thu, 8 Sep 2011 14:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.768 X-Spam-Level: X-Spam-Status: No, score=-105.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnV07s3ktunX for ; Thu, 8 Sep 2011 14:20:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 37F0721F8B23 for ; Thu, 8 Sep 2011 14:20:48 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p88LMcQe007414 for ; Thu, 8 Sep 2011 14:22:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315516958; bh=24uJhSy8B4d2+B5e4OPEO04B/4Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=O1shf/6FZfCTNHMm04DRLbYtxeEoSwKvsaX69acC0nGALryo16YU2stDZYjpijZwc bFdxt4DdElfSYel540RCA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=EalUqUQ2MKvjCzvVjFBbr4OXTwPXYC4thcNc8NSq2Ohc51Zc0F2CPtOi85fS7Lvz5 rWpKqe8h9a18c08TwplSQ== Received: from qwb7 (qwb7.prod.google.com [10.241.193.71]) by hpaq5.eem.corp.google.com with ESMTP id p88LJbTc022001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 8 Sep 2011 14:22:36 -0700 Received: by qwb7 with SMTP id 7so581599qwb.33 for ; Thu, 08 Sep 2011 14:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3CXh2nqphvjal5uIIG45I+61zRlEhXAt3sYWiGksWnc=; b=oTBH0+gaozAOHWIuVLX4oKUc4GwHIcR0GKRxOgacRhBEWHuLoGn1wnEFDkKBTbjOu6 vJ895zcYfeRdYNHm8UhQ== Received: by 10.229.231.149 with SMTP id jq21mr938799qcb.243.1315516954441; Thu, 08 Sep 2011 14:22:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.149 with SMTP id jq21mr938794qcb.243.1315516954094; Thu, 08 Sep 2011 14:22:34 -0700 (PDT) Received: by 10.229.56.8 with HTTP; Thu, 8 Sep 2011 14:22:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Sep 2011 14:22:34 -0700 Message-ID: From: Dirk Balfanz To: Nico Williams Content-Type: multipart/alternative; boundary=0016e64ea93ebeaddc04ac74a8e0 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC and channel-bound cookies as a new TLS CB type (Re: TLS-OBC proposal) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 21:20:49 -0000 --0016e64ea93ebeaddc04ac74a8e0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 8, 2011 at 12:47 PM, Nico Williams wrote: > One way to think about what you're proposing is this: you're proposing > a new TLS session identification and resumption facility and a new > channel binding type whose CB data that are unique for each session > but the same for all connections in that session. > > The session ID here would be the client's ephemeral (private key > thrown away between sessions) self-signed cert. > > Session resumption here would come in two forms: proper TLS session > resumption, and new TLS sessions using an existing OBC. For the > latter case there'd be neither server-side state nor state cookies -- > clever! > > A digest of an OBC would be the CB data for the new CB type. > Yes, exactly! I try to say as much here: http://www.browserauth.net/channel-bound-cookies (look for my mention of RFC 5929). > > I find your idea very clever. > > The only downside is that we'd need two additional PK operations for > all full handshakes. > Well, if you define "session" as something that survives full new handshakes, I guess. I would still call it a new "session", but the same "channel", but at this time we're mincing words... > > Note that we could instead use a new TLS CB type named, say, > tls-session-unique, defined as follows: the CB data will be as for > tls-unique for a TLS session's full handshake. This would avoid the > need to negotiate the use/non-use of OBC, and it'd avoid the need to > add a pair of PK operations. But it'd also make the system more > dependent on TLS session resumption. I suspect that given a choice of > "more PK ops" vs "session resumption becomes more important" then > people will prefer the former. > > Note too that what you propose fits RFC 5056 just fine. Yes, I noticed that, too. Dirk. > We could and > should register a new CB type for OBC if OBC progresses. > > Nico > -- > --0016e64ea93ebeaddc04ac74a8e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 8, 2011 at 12:47 PM, Nico Wi= lliams <nico@= cryptonector.com> wrote:
One way to think about what you're proposing is this: you're propos= ing
a new TLS session identification and resumption facility and a new
channel binding type whose CB data that are unique for each session
but the same for all connections in that session.

The session ID here would be the client's ephemeral (private key
thrown away between sessions) self-signed cert.

Session resumption here would come in two forms: proper TLS session
resumption, and new TLS sessions using an existing OBC. =A0For the
latter case there'd be neither server-side state nor state cookies -- clever!

A digest of an OBC would be the CB data for the new CB type.

Yes, exactly! I try to say as much here:=A0http://www.browserauth.n= et/channel-bound-cookies=A0(look for my mention of RFC 5929).
=A0

I find your idea very clever.

The only downside is that we'd need two additional PK operations for all full handshakes.

Well, if you defin= e "session" as something that survives full new handshakes, I gue= ss. I would still call it a new "session", but the same "cha= nnel", but at this time we're mincing words...
=A0

Note that we could instead use a new TLS CB type named, say,
tls-session-unique, defined as follows: the CB data will be as for
tls-unique for a TLS session's full handshake. =A0This would avoid the<= br> need to negotiate the use/non-use of OBC, and it'd avoid the need to add a pair of PK operations. =A0But it'd also make the system more
dependent on TLS session resumption. =A0I suspect that given a choice of "more PK ops" vs "session resumption becomes more important&= quot; then
people will prefer the former.

Note too that what you propose fits RFC 5056 just fine.
Yes, I noticed that, too.

Dirk.
=
=A0
=A0We could and
should register a new CB type for OBC if OBC progresses.

Nico
--

--0016e64ea93ebeaddc04ac74a8e0-- From nico@cryptonector.com Thu Sep 8 14:30:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7E21F8B3F for ; Thu, 8 Sep 2011 14:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xfwRDvbr4MB for ; Thu, 8 Sep 2011 14:30:56 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 72B1C21F8ACC for ; Thu, 8 Sep 2011 14:30:56 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 46FFA428076 for ; Thu, 8 Sep 2011 14:32:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=BveKpvsBVypmQDYQgpENW/k6h9Dz6o6jlZTZxKJFPS+e mYPW4yhEOgFLNJrORPJS2lqaTQi4yDKm+LdhM9U9ZXCktkNvkhsXFqzIplgMzTI1 lJpeT0GT5W3pGQUrhItor82ReKe2zyuq/iUmkK3Vu8yMIAgTSodXYCzIovC8MWA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=t8VkfQNXCpwAUZjO0jAcKyySRNY=; b=BliLq6/OrLi C1PX/46KEgFZu5N4WKEPnuijNx3u6o3DVg0rm8C67nNGqdOGxOuwIlqmGEyTsS4r jOLZZvkxWZxFGmbTR1yBwgsEitOm7t5GdKDa+znbtZozD/R1QHeqCDqDmE6+iPGg jyCN0Ta5o3MLYea2b9SSk9akcCgesS74= Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id E43D742806E for ; Thu, 8 Sep 2011 14:32:47 -0700 (PDT) Received: by gxk9 with SMTP id 9so430814gxk.40 for ; Thu, 08 Sep 2011 14:32:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.64.202 with SMTP id q10mr1838657pbs.131.1315517566796; Thu, 08 Sep 2011 14:32:46 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 14:32:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Sep 2011 16:32:46 -0500 Message-ID: From: Nico Williams To: Dirk Balfanz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC and channel-bound cookies as a new TLS CB type (Re: TLS-OBC proposal) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 21:30:57 -0000 On Thu, Sep 8, 2011 at 4:22 PM, Dirk Balfanz wrote: > On Thu, Sep 8, 2011 at 12:47 PM, Nico Williams > wrote: >> A digest of an OBC would be the CB data for the new CB type. > > Yes, exactly! I try to say as much > here:=C2=A0http://www.browserauth.net/channel-bound-cookies=C2=A0(look fo= r my mention > of RFC 5929). I did see it :) Thanks! >> The only downside is that we'd need two additional PK operations for >> all full handshakes. > > Well, if you define "session" as something that survives full new > handshakes, I guess. I would still call it a new "session", but the same > "channel", but at this time we're mincing words... Well, yes, "sessions" here would last no longer than the OBC. If the client generates a new OBC, old sessions are dead. Now, here I'm not referring to TLS sessions proper, but a new concept of session that is much more within the control of the client. So, it's not so much that we're mincing words but that we need to be real careful with terminology. This being a mail thread and not an I-D I got careless with terminology for the sake of brevity :) >> Note too that what you propose fits RFC 5056 just fine. > > Yes, I noticed that, too. Great. Is there any way to avoid the need for negotiation of OBC? I'm guessing that for some TLS server stacks the use of random self-signed client certs would result in failure, thus negotiation is necessary. Is that right? Nico -- From nico@cryptonector.com Thu Sep 8 14:56:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D821F8B23 for ; Thu, 8 Sep 2011 14:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO44rA5+wAC8 for ; Thu, 8 Sep 2011 14:56:48 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4621F8B1B for ; Thu, 8 Sep 2011 14:56:48 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 253A4768057 for ; Thu, 8 Sep 2011 14:58:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s= cryptonector.com; b=l9OazGLfeaJBxJKxpMjXeY5WEHEDo1sfIhgYSiTU+l9f ottAwilGaPDSHEbRVxGfIAxBwhw0K4dVVEUIZxur961SftlLi9SRqzy7wqttHqnH OkomZJzXG6zAsi6aL3HQ2EZvCJ4cFBWeu2Rd9vQqieNXsKYVsA2YpFNRRsK4BFM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=HYpRus5138vJybredRVFsfrzGPA=; b=W7r/7aaVkVV RM+ahioYb3CQrfwAfTQicNKZ8+rW5u5FFIeXTITf5wwzi0voSVXMEeHVXmU0ADEz 2Kf+8h+TVcZB9JqCbtkkGAcHzsiUF+IBS/WBh0sKku0MENPnMgGeHLjYKh9OjF4M aXvnc/0qYrZo7RKYkyqnkWTuhvEpfKNM= Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id F05A7768056 for ; Thu, 8 Sep 2011 14:58:41 -0700 (PDT) Received: by gxk9 with SMTP id 9so455315gxk.40 for ; Thu, 08 Sep 2011 14:58:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.164 with SMTP id s4mr1630818pbi.265.1315519121031; Thu, 08 Sep 2011 14:58:41 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 14:58:41 -0700 (PDT) Date: Thu, 8 Sep 2011 16:58:41 -0500 Message-ID: From: Nico Williams To: Dirk Balfanz Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: [TLS] OBC and logout (Re: TLS-OBC proposal) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 21:56:49 -0000 Also note that here the client can make logout work better: the server can't accept the old cookies if the client destroys the corresponding OBC's private key. Sure, the server could loosen its rules and accept such cookies anyways, but it'd be opening itself to a big vulnerability unless it greatly limited what it will allow clients presenting such cookies to do (i.e., the server could allow such cookies only for post-logout tracking. If we know which cookies are channel bound to OBCs then the client can destroy those cookies when the corresponding OBCs' private keys are destroyed. So then the only way channel bound cookies can be used for tracking would be if they leaked. This would be almost as strong a logout semantic as you'd get with, say, REST-GSS. Strong enough for me. Nico -- From tdierks@gmail.com Sat Sep 10 09:39:36 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7665A21F8744 for ; Sat, 10 Sep 2011 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX0KhlesHbPd for ; Sat, 10 Sep 2011 09:39:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D89CD21F8569 for ; Sat, 10 Sep 2011 09:39:34 -0700 (PDT) Received: by wwf5 with SMTP id 5so1425137wwf.13 for ; Sat, 10 Sep 2011 09:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=wrD4BvRFElLAh6bDE2bKvaQ04lEqvqsVx8qrGgXnnYM=; b=SsGwAoXjdxCL+vg+BLrkjDeLKkEvK8zNZ0jOpFekrkgU4vofOThf5kEVfSqot+sM9v Qm7hBzRYMtHAUutur2bjCNOug4OA69fre8340QeZDxQTX9YhjnMblSbu3Rv0Wm3HLhQO wrunaqBKtIHNjkkpFqpDd1DQ2NS6gyeo0noLs= Received: by 10.216.38.141 with SMTP id a13mr1448391web.7.1315672891246; Sat, 10 Sep 2011 09:41:31 -0700 (PDT) MIME-Version: 1.0 Sender: tdierks@gmail.com Received: by 10.216.176.6 with HTTP; Sat, 10 Sep 2011 09:41:11 -0700 (PDT) From: Tim Dierks Date: Sat, 10 Sep 2011 12:41:11 -0400 X-Google-Sender-Auth: 4BOcABsbTrDfd9QG1gtpOCrgIBw Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016367b688052c9cb04ac98f764 Subject: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 16:39:36 -0000 --0016367b688052c9cb04ac98f764 Content-Type: text/plain; charset=ISO-8859-1 Does anyone have any ideas what Rizzo may be announcing @ ekoparty? http://www.ekoparty.org/2011/juliano-rizzo.php BEAST: Surprising crypto attack against HTTPS We present a new fast block-wise chosen-plaintext attack against SSL/TLS. We also describe one application of the attack that allows an adversary to efficiently decrypt and obtain authentication tokens and cookies from HTTPS requests. Our exploit abuses a vulnerability present in the SSL/TLS implementation of major Web browsers at the time of writing. - Tim --0016367b688052c9cb04ac98f764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Does anyone have any ideas what Rizzo may be announcing @ ekoparty?
http= ://www.ekoparty.org/2011/juliano-rizzo.php

BEAST: Surprising crypto attack against HTTPS

We p= resent a new fast block-wise chosen-plaintext attack against SSL/TLS. We al= so describe one application of the attack that allows an adversary to effic= iently decrypt and obtain authentication tokens and cookies from HTTPS requ= ests. Our exploit abuses a vulnerability present in the SSL/TLS implementat= ion of major Web browsers at the time of writing.

=A0- Tim
--0016367b688052c9cb04ac98f764-- From pgut001@login01.cs.auckland.ac.nz Sat Sep 10 10:10:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534B021F86E0 for ; Sat, 10 Sep 2011 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF9WKMTjhyAD for ; Sat, 10 Sep 2011 10:10:18 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 29BDF21F86C7 for ; Sat, 10 Sep 2011 10:10:16 -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=1315674737; x=1347210737; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20tim@dierks.org,=20tls@ietf.org|Subject:=20Re:=20[T LS]=20Rizzo=20claims=20implementation=20attach,=20should =20be=20interesting|In-Reply-To:=20 |Message-Id:=20|Date:=20Sun,=2011=20Sep=202011=2005:11:31=20+1200; bh=YhN8R1SAZvHP9NCFqmo2qqExEaK65DrOee+hDRdpBzg=; b=n1fwmR3e53j0f9BkY/fgcfsVxFK/3E6qYKXwKIW01RO0ECrVn8qq9AWv 22bsJI4nsoE/orF/B+f4+0EgXteD/HWtvgosKU7a9tjuy3hBGmmEqsGxJ bcsWV913/3AKsP5wbW+eqDZlhNZb+N5/T31KKq8VjahpMV93xoCl1bumO 8=; X-IronPort-AV: E=Sophos;i="4.68,361,1312113600"; d="scan'208";a="82806126" 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; 11 Sep 2011 05:11:31 +1200 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 1R2R5X-0006n2-Hd; Sun, 11 Sep 2011 05:11:31 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1R2R5X-0007XV-Dp; Sun, 11 Sep 2011 05:11:31 +1200 From: Peter Gutmann To: tim@dierks.org, tls@ietf.org In-Reply-To: Message-Id: Date: Sun, 11 Sep 2011 05:11:31 +1200 Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 17:10:19 -0000 Tim Dierks writes: >Does anyone have any ideas what Rizzo may be announcing @ ekoparty? I don't know about this one, but his previous work has been on CBC padding oracle attacks, and was pretty impressive stuff, so it may be something on those lines. Peter. From Jeff.Hodges@KingsMountain.com Mon Sep 12 10:43:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4E21F8C1F for ; Mon, 12 Sep 2011 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.431 X-Spam-Level: X-Spam-Status: No, score=-99.431 tagged_above=-999 required=5 tests=[AWL=-1.536, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTE4WFQF8n8O for ; Mon, 12 Sep 2011 10:43:25 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 9707721F8B91 for ; Mon, 12 Sep 2011 10:43:24 -0700 (PDT) Received: (qmail 14405 invoked by uid 0); 12 Sep 2011 17:45:27 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 12 Sep 2011 17:45:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=dnsq56K8q+8UQ6h12T3Ji0TCS8hpOmMr4vK5CJ/JUAI=; b=RK7LyGlIY50Sb93VrD+piGqRxg2ZPJxa3rDdSlGxJBIuY7op537eiE9o9kRbkBAdIUStyQ4DgIQzqrWET+j/NnO9MEYohpVdDF8YXhTCVkGVL0Nl6SedYkMIm26paOWk; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.218]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R3AZT-0003aB-6r for tls@ietf.org; Mon, 12 Sep 2011 11:45:27 -0600 Message-ID: <4E6E4537.9080709@KingsMountain.com> Date: Mon, 12 Sep 2011 10:45:27 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 17:43:27 -0000 perhaps based on similar attacks against the predictable implicit IV in SSL 3.0 and TLS 1.0 described several years ago by Greg Bard: A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL ? =JeffH From fweimer@bfk.de Tue Sep 13 07:58:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16A21F8AE6 for ; Tue, 13 Sep 2011 07:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q0EoRiigSnM for ; Tue, 13 Sep 2011 07:58:03 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 306A921F8A67 for ; Tue, 13 Sep 2011 07:58:03 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R3UT2-0000y0-Hz for tls@ietf.org; Tue, 13 Sep 2011 15:00:08 +0000 Received: by bfk.de with local id 1R3UT2-00063Q-Ee for tls@ietf.org; Tue, 13 Sep 2011 15:00:08 +0000 From: Florian Weimer To: tls@ietf.org Date: Tue, 13 Sep 2011 15:00:08 +0000 Message-ID: <82pqj4ij2f.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [TLS] Large extensions in the ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 14:58:07 -0000 I need to fit up to 2**24-1 bytes into a ClientHello extension. If I read the protocol language correctly, the limit is 2**16-1, for all extensions, and there is no way around that without major protocol changes. Is this correct? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From agl@google.com Tue Sep 13 08:04:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231AC21F8B2C for ; Tue, 13 Sep 2011 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUZy0z+UzUF4 for ; Tue, 13 Sep 2011 08:04:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F721F8B24 for ; Tue, 13 Sep 2011 08:04:21 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p8DF6Rrm011257 for ; Tue, 13 Sep 2011 08:06:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315926387; bh=XhOsYibeWd0cQovMYiXLP+buogQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=R2iVKuWL35veUs4ZmTSCrOLO1jIo9yC3G8MwEh/U76JgBU+GXmekngLLSdiZcsuL/ pKAvPKmi4ZAHllek/f2sg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=SjZkFn4akuXzSFLLnhV8vGQdlV8BG20imAoQICHjjnXjESlnVzRuiTIg5vU4aTRI2 uIGbZjfqx6WFPr2dkXKgg== Received: from yih10 (yih10.prod.google.com [10.243.66.202]) by wpaz17.hot.corp.google.com with ESMTP id p8DF6PfC019848 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2011 08:06:26 -0700 Received: by yih10 with SMTP id 10so626279yih.7 for ; Tue, 13 Sep 2011 08:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LAWpybOxyFznyy1dcmC1S4rKG4wNDVVg9jL5d7NT0lM=; b=EAEzgzkNiM87V2Bqs5YUCfWHZoeWqDMN8WJqQnRgWiJ+atOkEYAoJMu6Lni/SxnKHr 4sBVLFW+edJ/NWtunDCg== Received: by 10.42.29.8 with SMTP id p8mr579027icc.157.1315926385629; Tue, 13 Sep 2011 08:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.29.8 with SMTP id p8mr579022icc.157.1315926385443; Tue, 13 Sep 2011 08:06:25 -0700 (PDT) Received: by 10.231.19.137 with HTTP; Tue, 13 Sep 2011 08:06:25 -0700 (PDT) In-Reply-To: <82pqj4ij2f.fsf@mid.bfk.de> References: <82pqj4ij2f.fsf@mid.bfk.de> Date: Tue, 13 Sep 2011 11:06:25 -0400 Message-ID: From: Adam Langley To: Florian Weimer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Large extensions in the ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 15:04:22 -0000 On Tue, Sep 13, 2011 at 11:00 AM, Florian Weimer wrote: > I need to fit up to 2**24-1 bytes into a ClientHello extension. =C2=A0If = I > read the protocol language correctly, the limit is 2**16-1, for all > extensions, and there is no way around that without major protocol > changes. =C2=A0Is this correct? That's correct. At best I think you could use a small extension to negotiate and then have the client send it's jumbo handshake message as a new handshake type. (Although keep in mind that some TLS implementations will reject handshake messages are are split over multiple records, although hopefully any that negotiate your extension will have sorted that out.) Cheers AGL From juhovh@iki.fi Tue Sep 13 09:12:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0350621F8BF3 for ; Tue, 13 Sep 2011 09:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yTSXZ8Ew7Fa for ; Tue, 13 Sep 2011 09:12:12 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7821F8BEC for ; Tue, 13 Sep 2011 09:12:12 -0700 (PDT) Received: from mail.visino.fi (88.192.37.90) by jenni2.inet.fi (8.5.133) id 4DF73E85046C0255; Tue, 13 Sep 2011 19:14:16 +0300 Received: from [192.168.1.101] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 05EDE1FE85; Tue, 13 Sep 2011 19:14:14 +0300 (EEST) References: <82pqj4ij2f.fsf@mid.bfk.de> In-Reply-To: <82pqj4ij2f.fsf@mid.bfk.de> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Tue, 13 Sep 2011 19:14:08 +0300 To: Florian Weimer Cc: "tls@ietf.org" Subject: Re: [TLS] Large extensions in the ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:12:13 -0000 On 13.9.2011, at 18.00, Florian Weimer wrote: > I need to fit up to 2**24-1 bytes into a ClientHello extension. If I > read the protocol language correctly, the limit is 2**16-1, for all > extensions, and there is no way around that without major protocol > changes. Is this correct? Yes, the length limit for all extensions combined together in ClientHello is= 2^16-1 and there's no easy way aroud that as far as I can see. In theory I g= uess one could add some more data after the extensions in versions up to TLS= 1.1, but TLS 1.2 explicitly forbids that as well, and I'm not sure if it wo= uld result in problems in interoperability anyway. More proper way for you to send over 2^16-1 bytes of data would be to define= a short extension for negotiating your intended use and also define a new h= andshake message you can send to server after receiving ServerHelloDone, if t= he server indicated it supports your extension. This doesn't work of course i= f you need that large chunk of data _before_ sending ServerHello, but I wond= er what would be the use case there. Maybe you can shed some light on that. >=20 Juho From marsh@extendedsubset.com Tue Sep 13 09:58:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE80321F8B42 for ; Tue, 13 Sep 2011 09:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfVnRxccHs2T for ; Tue, 13 Sep 2011 09:58:31 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 281AE21F8B2F for ; Tue, 13 Sep 2011 09:58:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1R3WLd-000F2s-Do; Tue, 13 Sep 2011 17:00:37 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 56FE76067; Tue, 13 Sep 2011 17:00:35 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18A3DTZvPqAbTOafpzQsI85q0J3OWD6IX4= Message-ID: <4E6F8C34.1080503@extendedsubset.com> Date: Tue, 13 Sep 2011 12:00:36 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Florian Weimer References: <82pqj4ij2f.fsf@mid.bfk.de> In-Reply-To: <82pqj4ij2f.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Large extensions in the ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:58:31 -0000 On 09/13/2011 10:00 AM, Florian Weimer wrote: > I need to fit up to 2**24-1 bytes into a ClientHello extension. If I > read the protocol language correctly, the limit is 2**16-1, for all > extensions, and there is no way around that without major protocol > changes. Is this correct? A big part of the reason this isn't in the current protocol is that it would be particularly susceptible to DoS. Receiving that much data is not free and it's usually not a good idea to have your server be willing to receive and process it from an unauthenticated source. Still, you might be able to achieve the same semantics: 1. Exchange a small extension on the initial handshake to negotiate the use of the "jumbo extension". In that handshake propose one or more TLS_DH_anon cipher suites. 2. If the server chooses to accept the use of the jumbo extension in the ServerHello, he is coded to also accept one of your proposed TLS_DH_anon cipher suites and not transmit any server certs (nor request client auth). 3. The 2**24 - 1 bytes are sent from the client to the server as application data. Be certain that you have a crypto-quality record structure in this data so the server can determine where it ends without ambiguity. 4. When the server has received and processed all the data, he sends a 'Hello Request' to the client. The client agrees to renegotiate the session with the server, both strictly requiring the use of the RFC 5746 'Renegotiation Indication' extension. Yes, TLS renegotiation has gotten a bad name but RFC 5746 fixes all that. The client sends the small extension again on his Client Hello, perhaps with an indication that it's phase 2. 5a. If now after seeing the 2**24 - 1 bytes, the server agrees to the use of the jumbo extension, it replies with a confirming small extension on the Server Hello. 5b. If the server does not confirm the use of this extension, all prior state and buffered data is discarded by the client and server and this renegotiation handshake is treated exactly like an initial handshake (with the exception of the valid RI extension data) which declined the use of the extension. Important considerations: * Both client and server must be extra careful to ensure that a TLS_anon_DH cipher suites is never accepted for sessions that should not have them. * Both client and server must be extra careful to require the successful negotiation of RFC 5746 RI. * Anyone deploying such a scheme knows exactly what they're buying in terms of DoS exposure. You may have something in mind to address it. * Middle boxes are likely to puke all over this. Even TLS stacks may need to be compiled specially to allow anon DH, (but it's a new extension anyway). * Martin Rex (and others) will likely have some very thoughtful feedback on this scheme. :-) - Marsh From mrex@sap.com Wed Sep 14 17:56:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BAC21F8B68 for ; Wed, 14 Sep 2011 17:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcKuCwGCaLF8 for ; Wed, 14 Sep 2011 17:56:26 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6321F8B67 for ; Wed, 14 Sep 2011 17:56:25 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8F0wUae029280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 02:58:30 +0200 (MEST) From: Martin Rex Message-Id: <201109150058.p8F0wTX7003865@fs4113.wdf.sap.corp> To: agl@google.com (Adam Langley) Date: Thu, 15 Sep 2011 02:58:29 +0200 (MEST) In-Reply-To: from "Adam Langley" at Sep 13, 11 11:06:25 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] Large extensions in the ClientHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 00:56:26 -0000 Adam Langley wrote: > > On Tue, Sep 13, 2011 at 11:00 AM, Florian Weimer wrote: > > I need to fit up to 2**24-1 bytes into a ClientHello extension.  If I > > read the protocol language correctly, the limit is 2**16-1, for all > > extensions, and there is no way around that without major protocol > > changes. Is this correct? > > That's correct. At best I think you could use a small extension to > negotiate and then have the client send it's jumbo handshake message > as a new handshake type. > > (Although keep in mind that some TLS implementations will reject > handshake messages are are split over multiple records, although > hopefully any that negotiate your extension will have sorted that > out.) A ClientHello extension of size 2**24-1 = 16 MBytes ? There are likely numerous more pleasurable ways to commit suicide than doing this. Really, what is it that you're trying to accomplish? There are so many problems that something like this will cause, that it is likely better to use a totally different solution (_not_ within the TLS handshake). A large ClientHello is terrible for TCP congenstion control (TCP slow start), the data is unavoidably in the clear, the data not even integrity protected until after successful completion of the TLS handshake, so the TLS stack has to keep it around over a network round trip (once as TLS extension data, and maybe a second time as a "cached handshake message" in order to compute a handshake message hash with any possible hash algorithm later during the TLS handshake. -Martin From mrex@sap.com Mon Sep 19 11:55:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AFC21F8CE4 for ; Mon, 19 Sep 2011 11:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.728 X-Spam-Level: X-Spam-Status: No, score=-9.728 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St9b00qquAcl for ; Mon, 19 Sep 2011 11:55:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5B68321F8CE3 for ; Mon, 19 Sep 2011 11:55:25 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8JIviBe027941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Sep 2011 20:57:45 +0200 (MEST) From: Martin Rex Message-Id: <201109191857.p8JIvik9021961@fs4113.wdf.sap.corp> To: tim@dierks.org (Tim Dierks) Date: Mon, 19 Sep 2011 20:57:44 +0200 (MEST) In-Reply-To: from "Tim Dierks" at Sep 10, 11 12:41:11 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] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 18:55:27 -0000 Tim Dierks wrote: > > Does anyone have any ideas what Rizzo may be announcing @ ekoparty? > > http://www.ekoparty.org/2011/juliano-rizzo.php > > BEAST: Surprising crypto attack against HTTPS The first details seem to be leaking: http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611 It seems to be a Man-in-the-Browser attack on SSLv3/TLSv1.0 confidentiality of ciphers suites with a block cipher in CBC-mode, similar to the original attack here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf The original SSL&TLS protocol was never designed to protect data that is multiplexed onto a single TLS connection to be protected from each other, because the traffic-keys are created once per connection. SSL VPNs, which are an abuse of the SSL&TLS technology clearly beyond its original design scope, are likely much more difficult to fix than Web Browsers. The explicit IVs introduced by TLSv1.1 for block ciphers with CBC-mode might be an acceptable mitigation, but it is not a clean solution (because it does not address the underlying design, where the same symmetric crypto key is reused for data controlled by the attacker. A Web-Browser with a reasonable design of security zones could try to ensure that requests originating from different security domains never re-use network sockets from other domains. Resuming TLS sessions from other domains is not a problem, because traffic encryption and mac keys are regenerated for each connection, so you don't need more TLS handshakes, only more sockets whose scope for reuse/multiplex is limited. TLS cipher suites with stream ciphers (like rc4-128) or with block ciphers abused as stream ciphers (AES GCM or CCM, i.e. the AEAD cipher suites) are probably not as much affected, because they do not exactly "reuse" the exact same secret keys for data of the victim and data of the attacker, I assume. -Martin From asteingruebl@paypal-inc.com Mon Sep 19 16:39:55 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BCE21F8B3E for ; Mon, 19 Sep 2011 16:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIDxy2nf6IQJ for ; Mon, 19 Sep 2011 16:39:54 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEEC21F8B3D for ; Mon, 19 Sep 2011 16:39:54 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=c+h5YT4Ybj0vscao2qPRyWrEHMe1pVeR8I0ZIxwRIWx+ikIXuvDcpiGt 642PGVSNlloqtp5snUFsmF09UiieXTgOKQ5agaEOycB5j4cE6vxp6drxz FTFLJlugGPI/O5q; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1316475739; x=1348011739; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cEQW8STiZ8ktsAn3FthXwgskqcueWdpPn+shpS2unH0=; b=EQ+jEkREwQif+omCawp486kzcF1kHgsdAaSCsU2x/sIjCfeg/BlXk3Pv CIxgtFI5k1hi6oGeR7/pnj281Fsv+8ACqPGeapeXN5THdLstMGEP6Lp6p 08hyFdUhDvZdET8; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.68,408,1312182000"; d="scan'208";a="3950543" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 19 Sep 2011 16:42:19 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Mon, 19 Sep 2011 17:42:18 -0600 From: "Steingruebl, Andy" To: "mrex@sap.com" , "tls@ietf.org" Date: Mon, 19 Sep 2011 17:42:17 -0600 Thread-Topic: [TLS] Rizzo claims implementation attach, should be interesting Thread-Index: Acx2/iAnZ0mAF63YREKubJMpnC1LRQAJ2evQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEBD61B6ACA@DEN-MEXMS-001.corp.ebay.com> References: from "Tim Dierks" at Sep 10, 11 12:41:11 pm <201109191857.p8JIvik9021961@fs4113.wdf.sap.corp> In-Reply-To: <201109191857.p8JIvik9021961@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: tUJxIlQEikrrPavCDqYPNg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 23:39:55 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Martin Rex >=20 > Tim Dierks wrote: > > > > Does anyone have any ideas what Rizzo may be announcing @ ekoparty? > > > > http://www.ekoparty.org/2011/juliano-rizzo.php > > > > BEAST: Surprising crypto attack against HTTPS >=20 > The first details seem to be leaking: >=20 > http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality- > model-ssl-allows-theft-encrypted-cookies-091611 More "details" here: http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ Or at least more confirming quotes from the researchers about how quickly t= he can perform the attack. From mrex@sap.com Mon Sep 19 17:50:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2721F84C9 for ; Mon, 19 Sep 2011 17:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0q+H486WXLR for ; Mon, 19 Sep 2011 17:50:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C889121F84C2 for ; Mon, 19 Sep 2011 17:50:42 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8K0r5gr027993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 02:53:06 +0200 (MEST) From: Martin Rex Message-Id: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> To: asteingruebl@paypal-inc.com (Steingruebl Andy) Date: Tue, 20 Sep 2011 02:53:05 +0200 (MEST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEBD61B6ACA@DEN-MEXMS-001.corp.ebay.com> from "Steingruebl, Andy" at Sep 19, 11 05:42:17 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] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 00:50:45 -0000 Steingruebl, Andy wrote: > > Martin Rex wrote: > > > > Tim Dierks wrote: > > > > > > Does anyone have any ideas what Rizzo may be announcing @ ekoparty? > > > > > > http://www.ekoparty.org/2011/juliano-rizzo.php > > > > > > BEAST: Surprising crypto attack against HTTPS > > > > The first details seem to be leaking: > > > > http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality- > > model-ssl-allows-theft-encrypted-cookies-091611 > > More "details" here: > > http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ > > Or at least more confirming quotes from the researchers about how > quickly the can perform the attack. It seem to be a huge hype an exxageration of the problem. There is *no* problem in SSLv3 or TLSv1.0. This particular attack is a very clear "Man-in-the-Browser" attack enabled solely by the entirely braindead (lack-of) security in common Web Browsers. Since the attack happens entirely at the browser, it should IMHO the browser's duty to fix this. Potential server-side mitigation of the problem: - disable HTTP request pipelining (aka Connect: keep-alive) - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0 is negotiated), and use RC4-128 instead. -Martin From marsh@extendedsubset.com Mon Sep 19 19:28:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B963721F8AE1 for ; Mon, 19 Sep 2011 19:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGGbyIDufYva for ; Mon, 19 Sep 2011 19:28:56 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id C8D7E21F8ADC for ; Mon, 19 Sep 2011 19:28:56 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1R5q7F-0007Hf-0d; Tue, 20 Sep 2011 02:31:21 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7816D606C; Tue, 20 Sep 2011 02:31:18 +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: U2FsdGVkX18iKor3Ez4FZEQqq4ENuFSZPmQdsg5iMVw= Message-ID: <4E77FAF6.90707@extendedsubset.com> Date: Mon, 19 Sep 2011 21:31:18 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: mrex@sap.com References: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> In-Reply-To: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steingruebl Andy , tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 02:28:57 -0000 On 09/19/2011 07:53 PM, Martin Rex wrote: > > It seem to be a huge hype an exxageration of the problem. > There is *no* problem in SSLv3 or TLSv1.0. This particular attack > is a very clear "Man-in-the-Browser" attack enabled solely by the > entirely braindead (lack-of) security in common Web Browsers. > > Since the attack happens entirely at the browser, it should IMHO > the browser's duty to fix this. Last I checked, the TLS RFC stated explicitly that the protocol defended explicitly against man-in-the-middle attacks. It did not say it defended against "blockwise-adaptive chosen-plaintext" attacks. But why split hairs over it? It breaks a basic security properties of the system even if the application designer has done everything according to the recommendations in the spec. Since when did "trusted script only" in the application become a requirement for transport layer security? > Potential server-side mitigation of the problem: > > - disable HTTP request pipelining (aka Connect: keep-alive) Expensive. > - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0 > is negotiated), and use RC4-128 instead. Does TLS's use of RC4 still take the first bytes after initialization with the key? Or does it discard the proper amount? I believe there was a mitigation put in place by OpenSSL: sending an empty (just padding) message before each app data message. The document at eprint.iacr.org/2006/136 suggests that this could be a server-side only change. I don't see how that would work since the session cookie recovery attack is clearly happening on the client->server channel. I read somewhere that this mitigation was off by default in OpenSSL because it some software (an old MSIE IIRC). Does anyone believe there would be support for a TLS 1.0 Hello extension that could compatibly negotiate the use of empty messages in each direction as a mitigation for this attack? I've not been told the details of Duong and Rizzo's attack and haven't seen "the BEAST" in action yet, so I'm not sure if that would be sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys for dribbling out the information one hint at a time like this. - Marsh From ekr@rtfm.com Mon Sep 19 20:47:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E1021F8B08 for ; Mon, 19 Sep 2011 20:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqKhH6eYWgOl for ; Mon, 19 Sep 2011 20:47:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3F121F8AFF for ; Mon, 19 Sep 2011 20:47:22 -0700 (PDT) Received: by wyg24 with SMTP id 24so99411wyg.31 for ; Mon, 19 Sep 2011 20:49:47 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr326532wby.18.1316490587228; Mon, 19 Sep 2011 20:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.82 with HTTP; Mon, 19 Sep 2011 20:49:27 -0700 (PDT) In-Reply-To: <4E77FAF6.90707@extendedsubset.com> References: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> <4E77FAF6.90707@extendedsubset.com> From: Eric Rescorla Date: Mon, 19 Sep 2011 20:49:27 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: Steingruebl Andy , tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 03:47:23 -0000 On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray wrote: > Does anyone believe there would be support for a TLS 1.0 Hello extension > that could compatibly negotiate the use of empty messages in each direction > as a mitigation for this attack? The difference between TLS 1.0 and TLS 1.1 is so slight that if TLS 1.1 is indeed immune it would probably be easier to just have servers upgrade to 1.1. -Ekr From ekr@rtfm.com Mon Sep 19 20:48:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B560221F8B08 for ; Mon, 19 Sep 2011 20:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uBP78KjujjC for ; Mon, 19 Sep 2011 20:48:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1869B21F8B0E for ; Mon, 19 Sep 2011 20:48:23 -0700 (PDT) Received: by wyg24 with SMTP id 24so99911wyg.31 for ; Mon, 19 Sep 2011 20:50:48 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr327331wby.18.1316490648141; Mon, 19 Sep 2011 20:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.82 with HTTP; Mon, 19 Sep 2011 20:50:28 -0700 (PDT) In-Reply-To: References: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> <4E77FAF6.90707@extendedsubset.com> From: Eric Rescorla Date: Mon, 19 Sep 2011 20:50:28 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: Steingruebl Andy , tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 03:48:24 -0000 On Mon, Sep 19, 2011 at 8:49 PM, Eric Rescorla wrote: > On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray wrote: >> Does anyone believe there would be support for a TLS 1.0 Hello extension >> that could compatibly negotiate the use of empty messages in each direction >> as a mitigation for this attack? > > The difference between TLS 1.0 and TLS 1.1 is so slight that if TLS > 1.1 is indeed > immune it would probably be easier to just have servers upgrade to 1.1. s/servers/clients and servers/ Best, -Ekr From ynir@checkpoint.com Mon Sep 19 21:10:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B20821F86F6 for ; Mon, 19 Sep 2011 21:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnmFV3Ixmg7H for ; Mon, 19 Sep 2011 21:10:28 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E226321F85B1 for ; Mon, 19 Sep 2011 21:10:27 -0700 (PDT) X-CheckPoint: {4E781FC6-3-1B221DC2-FFFF} 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 p8K4COGS019162; Tue, 20 Sep 2011 07:12:25 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 20 Sep 2011 07:12:25 +0300 From: Yoav Nir To: Marsh Ray Date: Tue, 20 Sep 2011 07:12:23 +0300 Thread-Topic: [TLS] Rizzo claims implementation attach, should be interesting Thread-Index: Acx3S3+gssyfqBPgRnS2DXCwJXM/Bg== Message-ID: <2B2DBCE0-2B5A-42BC-B3F9-C215393320C5@checkpoint.com> References: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> <4E77FAF6.90707@extendedsubset.com> In-Reply-To: <4E77FAF6.90707@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Steingruebl Andy , "tls@ietf.org" Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 04:10:29 -0000 On Sep 20, 2011, at 5:31 AM, Marsh Ray wrote: > On 09/19/2011 07:53 PM, Martin Rex wrote: >=20 > I believe there was a mitigation put in place by OpenSSL: sending an=20 > empty (just padding) message before each app data message. The document=20 > at eprint.iacr.org/2006/136 suggests that this could be a server-side=20 > only change. I don't see how that would work since the session cookie=20 > recovery attack is clearly happening on the client->server channel. >=20 > I read somewhere that this mitigation was off by default in OpenSSL=20 > because it some software (an old MSIE IIRC). Yes, Internet Explorer 6 has that problem. Also SSL-using services running = under XP. >=20 > Does anyone believe there would be support for a TLS 1.0 Hello extension= =20 > that could compatibly negotiate the use of empty messages in each=20 > direction as a mitigation for this attack? If you're going to upgrade to a browser that supports the extension, might = as well upgrade to IE7. It can deal with the empty fragment. >=20 > I've not been told the details of Duong and Rizzo's attack and haven't=20 > seen "the BEAST" in action yet, so I'm not sure if that would be=20 > sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys=20 > for dribbling out the information one hint at a time like this. A time like what?= From marsh@extendedsubset.com Mon Sep 19 21:17:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A138521F8AFA for ; Mon, 19 Sep 2011 21:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiwSY975heGC for ; Mon, 19 Sep 2011 21:17:32 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3FB21F8AE6 for ; Mon, 19 Sep 2011 21:17:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1R5roJ-000B1K-VA; Tue, 20 Sep 2011 04:19:56 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E84BF606C; Tue, 20 Sep 2011 04:19:52 +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/zS7MHEkBkoKuw+tGPpf6uTLMhMGq1B9I= Message-ID: <4E781468.1040507@extendedsubset.com> Date: Mon, 19 Sep 2011 23:19:52 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Yoav Nir References: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> <4E77FAF6.90707@extendedsubset.com> <2B2DBCE0-2B5A-42BC-B3F9-C215393320C5@checkpoint.com> In-Reply-To: <2B2DBCE0-2B5A-42BC-B3F9-C215393320C5@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steingruebl Andy , "tls@ietf.org" Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 04:17:32 -0000 On 09/19/2011 11:12 PM, Yoav Nir wrote: > > On Sep 20, 2011, at 5:31 AM, Marsh Ray wrote: > >> I am slightly annoyed at >> these guys for dribbling out the information one hint at a time >> like this. > > A time like what? (one hint at a time) like this not one hint (at a time like this) Sorry for the parsing ambiguity. :-) - Marsh From ynir@checkpoint.com Mon Sep 19 22:22:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B3821F8A35 for ; Mon, 19 Sep 2011 22:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.396 X-Spam-Level: X-Spam-Status: No, score=-10.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KyVcoMXbsgo for ; Mon, 19 Sep 2011 22:22:37 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 666BA21F858D for ; Mon, 19 Sep 2011 22:22:37 -0700 (PDT) X-CheckPoint: {4E7830C6-A-1B221DC2-FFFF} 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 p8K5OvFc028493; Tue, 20 Sep 2011 08:24:57 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 20 Sep 2011 08:24:57 +0300 From: Yoav Nir To: Marsh Ray Date: Tue, 20 Sep 2011 08:24:55 +0300 Thread-Topic: [TLS] Rizzo claims implementation attach, should be interesting Thread-Index: Acx3VaHjnC74NFkXTFe+GFQOJJDr7w== Message-ID: <732877EA-C7CA-4E2F-872E-D9C1C3FA8C1A@checkpoint.com> References: <201109200053.p8K0r5Pv012913@fs4113.wdf.sap.corp> <4E77FAF6.90707@extendedsubset.com> <2B2DBCE0-2B5A-42BC-B3F9-C215393320C5@checkpoint.com> <4E781468.1040507@extendedsubset.com> In-Reply-To: <4E781468.1040507@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Steingruebl Andy , "tls@ietf.org" Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 05:22:39 -0000 On Sep 20, 2011, at 7:19 AM, Marsh Ray wrote: > On 09/19/2011 11:12 PM, Yoav Nir wrote: >>=20 >> On Sep 20, 2011, at 5:31 AM, Marsh Ray wrote: >>=20 >>> I am slightly annoyed at >>> these guys for dribbling out the information one hint at a time >>> like this. >>=20 >> A time like what? >=20 > (one hint at a time) like this > not > one hint (at a time like this) >=20 > Sorry for the parsing ambiguity. :-) Sorry. Reading it again, it's obvious. Guess we should switch all IETF mail= ing lists to lojban. From mrex@sap.com Tue Sep 20 07:43:40 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74D221F8C8A for ; Tue, 20 Sep 2011 07:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.037 X-Spam-Level: X-Spam-Status: No, score=-10.037 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNyFXJJ0S5Xv for ; Tue, 20 Sep 2011 07:43:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 593DB21F8BEB for ; Tue, 20 Sep 2011 07:43:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8KEjvpM022396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 16:45:57 +0200 (MEST) From: Martin Rex Message-Id: <201109201445.p8KEju3B029762@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 20 Sep 2011 16:45:56 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Sep 19, 11 08:49:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 14:43:40 -0000 Eric Rescorla wrote: > > On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray wrote: > > Does anyone believe there would be support for a TLS 1.0 Hello extension > > that could compatibly negotiate the use of empty messages in each direction > > as a mitigation for this attack? > > The difference between TLS 1.0 and TLS 1.1 is so slight that if TLS > 1.1 is indeed immune it would probably be easier to just have servers > upgrade to 1.1. Using the TLSv1.1 explicit random IVs for TLS cipher suites with block ciphers in CBC-mode would be my preferred solution -- provided that a significant majority believes this to be a sufficient mitigation. (Personally, I think that it is not a clean solution, but may be OK as a mitigation that makes this attack sufficiently "expensive"). I don't see why adding and enabling TLSv1.1 on Servers should cause interop problems, but I'm completely lacking experience in that area to make any assessments. A client that announces TLSv1.1 (and no application level reconnect fallback) is much more likely to run into interop problems, similar to a client that includes a TLS extension in ClientHello. Newer Browsers (those that are affected by this Man-in-the-Browser attack) usually have a reconnect fallback capability and should be able to cope with this. But really, the underlying problem is letting an attacker reuse the very same symmetric key for his own data (adaptive chosen plaintext). Knowing the IV ahead of time can significantly improve an adequate choice of plaintexts, which is why the problem is worse in SSLv3 and TLSv1.0. But it should really be possible for browsers to seperate the TLS sockets that evil code can use and the sockets that victim code can use safely. Sharing cached TLS sessions is not a problem, each connection will derive their own traffic encryption and mac keys. If Browsers can not seperate those network traffics, then there will be much more serious problems in the browser architecture to worry about than an attack that requires a cooperating network sniffer and malware running in your browser and a significant amount of network traffic between them. -Martin From marsh@extendedsubset.com Tue Sep 20 08:10:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FF921F8CDD for ; Tue, 20 Sep 2011 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+jHWU3CgUUq for ; Tue, 20 Sep 2011 08:10:45 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2C21F8CD0 for ; Tue, 20 Sep 2011 08:10:45 -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 1R620V-000C3f-6B; Tue, 20 Sep 2011 15:13:11 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F3A0E606C; Tue, 20 Sep 2011 15:13:08 +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: U2FsdGVkX19Zjei0TvoNILnPc8o1b2n0YgH/4Qa5GHs= Message-ID: <4E78AD85.4000504@extendedsubset.com> Date: Tue, 20 Sep 2011 10:13:09 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: mrex@sap.com References: <201109201445.p8KEju3B029762@fs4113.wdf.sap.corp> In-Reply-To: <201109201445.p8KEju3B029762@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:10:46 -0000 On 09/20/2011 09:45 AM, Martin Rex wrote: > > But really, the underlying problem is letting an attacker reuse > the very same symmetric key for his own data (adaptive chosen plaintext). > Knowing the IV ahead of time can significantly improve an adequate choice > of plaintexts, which is why the problem is worse in SSLv3 and TLSv1.0. > > But it should really be possible for browsers to seperate the TLS sockets > that evil code can use and the sockets that victim code can use safely. If only applications would set the 'evil bit' it would make a lot of things simpler! But we can't add that as a new requirement for the existing protocols. > Sharing cached TLS sessions is not a problem, each connection will > derive their own traffic encryption and mac keys. If Browsers can not > seperate those network traffics, then there will be much more serious > problems in the browser architecture to worry about than an attack > that requires a cooperating network sniffer and malware running in > your browser and a significant amount of network traffic between > them. People keep thinking of this in terms of a compromised endpoint attack. Bard 2004 even talks about requiring a "trojan horse plug in" to be practical. Bard 2006 reduces that to a malicious Java applet. But I'm not convinced. Basic HTTP and browser behavior still leaves a lot of room for creativity. When the corresponding flaw was identified in IPsec it was not so easily dismissed on the basis that it required a compromised endpoint. From what I hear, TLS is used for VPN trunking too. What about SMTP/POP/IMAP over TLS? They have similar amounts of known plaintext as HTTP, and an attacker may have the ability to control a large volume of messages, perhaps even in both directions. - Marsh From mrex@sap.com Tue Sep 20 08:19:06 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CA821F8B75 for ; Tue, 20 Sep 2011 08:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPn2aDWovAxe for ; Tue, 20 Sep 2011 08:19:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE821F8B71 for ; Tue, 20 Sep 2011 08:19:05 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8KFLSY1028757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 17:21:28 +0200 (MEST) From: Martin Rex Message-Id: <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Tue, 20 Sep 2011 17:21:27 +0200 (MEST) In-Reply-To: <4E77FAF6.90707@extendedsubset.com> from "Marsh Ray" at Sep 19, 11 09:31:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:19:06 -0000 Marsh Ray wrote: > > I've not been told the details of Duong and Rizzo's attack and haven't > seen "the BEAST" in action yet, so I'm not sure if that would be > sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys > for dribbling out the information one hint at a time like this. The "ekoparty conference" is 21-23 Sep., and usually if you get a paper accepted for a conference, you're not supposed to publish before the conference... > > Last I checked, the TLS RFC stated explicitly that the protocol defended > explicitly against man-in-the-middle attacks. It did not say it defended > against "blockwise-adaptive chosen-plaintext" attacks. It does defend against man-in-the-middle attacks. > > But why split hairs over it? It breaks a basic security properties of > the system even if the application designer has done everything > according to the recommendations in the spec. Wrong. I do not believe that it breaks any of the security properties. It does break some flawed assumptions. SSL was NEVER designed with a promise that you could multiplex data from an evil attack with data from a victim over the very same SSL connection and be secure against adaptive chose plaintext attacks trying to recover data from the victim. >From the SSL design it is quite clear that for CBC encryption, the encryption key is static for a single connection (=reused for every cipher block), so mupliplexing data from evil and victim like it is done in SSL-VPNs or allegedly here by "BEAST" by subverting the browser security model, that is a clear abuse of the SSL protocol beyond it's design limitations. You see it in every episode of Star Trek -- whenever the captain decides to operate the engines significantly beyond the design limits, the engine suffers significant damages. That's not "ficition", it applies similarily to NASA spacecraft, to aircrafts, vehicles on the road and other products of technical design. > > Since when did "trusted script only" in the application become a > requirement for transport layer security? Do NOT run trusted and untrusted data over the very same SSL connection, because there are no properties in the SSL design to avoid this impairing the resulting confidentiality. SSL is no panacea or silver bullet (never was) and using a technology beyond its design limits is always a bad idea. > > > Potential server-side mitigation of the problem: > > > > - disable HTTP request pipelining (aka Connect: keep-alive) > > Expensive. Not for those braindead "secure checkout" or "secure payment" pages in an otherwise completely unprotected online shop -- which includes Paypal. > > > - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0 > > is negotiated), and use RC4-128 instead. > > Does TLS's use of RC4 still take the first bytes after initialization > with the key? Or does it discard the proper amount? How significant is the RC4 initialization bias for a brief communication with an SSL-secured checkout / payment ? (The suggestion was meant to be a mitigation, not a solution) -Martin From ekr@rtfm.com Tue Sep 20 08:25:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EF221F8CB8 for ; Tue, 20 Sep 2011 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0ux6921h+cd for ; Tue, 20 Sep 2011 08:25:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C19F021F8CAB for ; Tue, 20 Sep 2011 08:25:28 -0700 (PDT) Received: by wyg24 with SMTP id 24so726864wyg.31 for ; Tue, 20 Sep 2011 08:27:54 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr1098121wby.18.1316532474243; Tue, 20 Sep 2011 08:27:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.82 with HTTP; Tue, 20 Sep 2011 08:27:34 -0700 (PDT) In-Reply-To: <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> References: <4E77FAF6.90707@extendedsubset.com> <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 20 Sep 2011 08:27:34 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:25:29 -0000 On Tue, Sep 20, 2011 at 8:21 AM, Martin Rex wrote: > Marsh Ray wrote: >> >> I've not been told the details of Duong and Rizzo's attack and haven't >> seen "the BEAST" in action yet, so I'm not sure if that would be >> sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys >> for dribbling out the information one hint at a time like this. > > The "ekoparty conference" is 21-23 Sep., and usually if you get a > paper accepted for a conference, you're not supposed to publish > before the conference... For what it's worth, that's not the convention in most academic security conferences I've been involved with (e.g., USENIX Security, ISOC NDSS, IEEE Oakland). Indeed, it's common to see papers submitted (i.e., not even accepted!) that have already been distributed on the author's web sites. I don't know what the rules for ekoparty are, however. -Ekr From hallam@gmail.com Tue Sep 20 13:01:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDE421F8B01 for ; Tue, 20 Sep 2011 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbWT1xviN2eo for ; Tue, 20 Sep 2011 13:01:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 082BD21F8AFA for ; Tue, 20 Sep 2011 13:01:56 -0700 (PDT) Received: by gyd12 with SMTP id 12so790507gyd.31 for ; Tue, 20 Sep 2011 13:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RspFcP6Jcs4M6tfGBmvt6H51eDugRoJSU6AiIvhDtSw=; b=ip/OxuE2vVFz+pGaE7jkHvlsU4ciGstQ5Veoxohu83yu+pGAKi1Xk3Q9XBBsUtPQ47 5FRfjtQuqxnRIdeY37prI4hdTNvt2iW5qQsEZgc2VVIGpqZRfbUHC6gDeh0L6YOUWH9+ eB+yjL1dtl0Xfc4lSkigQH6drFX/oc9WmfZm0= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr1174083anq.140.1316549063562; Tue, 20 Sep 2011 13:04:23 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Tue, 20 Sep 2011 13:04:23 -0700 (PDT) In-Reply-To: <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> References: <4E77FAF6.90707@extendedsubset.com> <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> Date: Tue, 20 Sep 2011 16:04:23 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636ed746443565804ad64f764 Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 20:01:57 -0000 --001636ed746443565804ad64f764 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex wrote: > Marsh Ray wrote: > > But why split hairs over it? It breaks a basic security properties of > > the system even if the application designer has done everything > > according to the recommendations in the spec. > > Wrong. I do not believe that it breaks any of the security properties. > It does break some flawed assumptions. > > SSL was NEVER designed with a promise that you could multiplex > data from an evil attack with data from a victim over the very same > SSL connection and be secure against adaptive chose plaintext > attacks trying to recover data from the victim. > SSL came before Javascript and even before cookies. So this is certainly outside the model. Adding AES in CBC mode probably came after the model had been changed though. If we want to avoid this type of attack we should probably change the encryption mode. I don't like stream ciphers in general, but SSL was designed round one and has been extensively verified when a stream cipher is used. >From a design point of view, re-use of the same key to encrypt each block is bad news and turning a block cipher into a stream cipher is bad news. Anyone know why CBC is so popular vs PCBC? -- Website: http://hallambaker.com/ --001636ed746443565804ad64f764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 20, 2011 at 11:21 AM, Martin= Rex <mrex@sap.com= > wrote:
Marsh Ray wrote:
> But why split hairs over it? It breaks a basic security properties of<= br> > the system even if the application designer has done everything
> according to the recommendations in the spec.

Wrong. =A0I do not believe that it breaks any of the security propert= ies.
It does break some flawed assumptions.

SSL was NEVER designed with a promise that you could multiplex
data from an evil attack with data from a victim over the very same
SSL connection and be secure against adaptive chose plaintext
attacks trying to recover data from the victim.

SSL came before Javascript and even before cookies. So this is cer= tainly outside the model.

Adding AES in CBC mode p= robably came after the model had been changed though.=A0


If we want to avoid this type of attack = we should probably change the encryption mode. I don't like stream ciph= ers in general, but SSL was designed round one and has been extensively ver= ified when a stream cipher is used.=A0

From a design point of view, re-use of the same key to = encrypt each block is bad news and turning a block cipher into a stream cip= her is bad news. Anyone know why CBC is so popular vs PCBC?


--
Website: http://hallambaker.com/

--001636ed746443565804ad64f764-- From nico@cryptonector.com Tue Sep 20 14:02:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F3E21F85AA for ; Tue, 20 Sep 2011 14:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYGAms7tGo7s for ; Tue, 20 Sep 2011 14:02:00 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id B96C421F888A for ; Tue, 20 Sep 2011 14:01:59 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6097E2F4059 for ; Tue, 20 Sep 2011 14:04:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=vXWB7ZrRChI/4xBGjwdbt 2dfgzJKRMOYXxsOuag1hwuLoLhfjh2DQnlFhOHXUy/iBN1/z8gvaqzanX4UYPZjv K+2EBmfXjbynealFDyAWCyj3sWHVN8egwsQTQJ2fiDqJ3cLroWjHqcUSKWpu9Xx7 8KBhxlKAIdDPJMXzHOU9mk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ycyBSfOggFeWKiAyWf3C Pvnwm9s=; b=tjVJw4vpzEK4alko77LhX1W65ZyJ5bh+Jo418ZxKA8pyx7AYFheL NevGrVWN31vgIU0osWSxXftKi0k+5HiqbdMu+jUZwNqlma/9+8Gr05QrEFkM/hMl Y3y3GYBAmAbiCre+7eHNrP7tK/19L+ItMSkHx3rOl6mE0tQq2+4Cdb8= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 4401D2F4057 for ; Tue, 20 Sep 2011 14:04:26 -0700 (PDT) Received: by pzk37 with SMTP id 37so272983pzk.9 for ; Tue, 20 Sep 2011 14:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.0.170 with SMTP id 10mr141346pbf.198.1316552665780; Tue, 20 Sep 2011 14:04:25 -0700 (PDT) Received: by 10.68.60.4 with HTTP; Tue, 20 Sep 2011 14:04:25 -0700 (PDT) In-Reply-To: References: <4E77FAF6.90707@extendedsubset.com> <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> Date: Tue, 20 Sep 2011 16:04:25 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 21:02:01 -0000 On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker wrote: > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex wrote: >> SSL was NEVER designed with a promise that you could multiplex >> data from an evil attack with data from a victim over the very same >> SSL connection and be secure against adaptive chose plaintext >> attacks trying to recover data from the victim. I wasn't there. I don't know what it was designed for. But here's the thing: why shouldn't the designers have assumed that some of the data sent over SSL might be untrusted? On what grounds would it have been OK to say "no untrusted data, please"? And where was this restriction documented? But let's grant that restriction. That would have meant that we should never have allowed IMAP over SSL, for example, and taking the argument to extremes, we should never have allowed HTTP POST over SSL either. This is really Marsh's point, I think, and I agree with it. > SSL came before Javascript and even before cookies. So this is certainly > outside the model. > Adding AES in CBC mode probably came after the model had been changed > though. Yeah, sure, but I think it's fairer to say that the subject probably didn't come up, not that SSL was not intended for this. > If we want to avoid this type of attack we should probably change the > encryption mode. I don't like stream ciphers in general, but SSL was > designed round one and has been extensively verified when a stream cipher is > used. > From a design point of view, re-use of the same key to encrypt each block is > bad news and turning a block cipher into a stream cipher is bad news. Anyone > know why CBC is so popular vs PCBC? Block ciphers in counter mode are as broken in the face of key&IV reuse as any stream cipher, and for the same sorts of reasons. This is not a reason to not use counter modes. It's a reason to use them with care. For example, in a situation like Kerberos' PDUs counter modes are dangerous because there's no "connection" context for most of those PDUs, thus no way to prevent key&IV reuse. But for TLS, and even DTLS, there's no such issue. Nico -- From mrex@sap.com Tue Sep 20 14:29:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E790E1F0C87 for ; Tue, 20 Sep 2011 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.439 X-Spam-Level: X-Spam-Status: No, score=-9.439 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_29=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4T4xaO-FjdZ for ; Tue, 20 Sep 2011 14:29:37 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE91F0C62 for ; Tue, 20 Sep 2011 14:29:31 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8KLVqkY017599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 23:31:52 +0200 (MEST) From: Martin Rex Message-Id: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Tue, 20 Sep 2011 23:31:51 +0200 (MEST) In-Reply-To: from "Nico Williams" at Sep 20, 11 04:04:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 21:29:38 -0000 Nico Williams wrote: > > On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker wrote: > > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex wrote: > >> SSL was NEVER designed with a promise that you could multiplex > >> data from an evil attack with data from a victim over the very same > >> SSL connection and be secure against adaptive chose plaintext > >> attacks trying to recover data from the victim. > > I wasn't there. I don't know what it was designed for. But here's > the thing: why shouldn't the designers have assumed that some of the > data sent over SSL might be untrusted? On what grounds would it have > been OK to say "no untrusted data, please"? And where was this > restriction documented? It is a design limit that should be obvious to the conscious reader with background knowledge about cryptography. > > But let's grant that restriction. That would have meant that we > should never have allowed IMAP over SSL, for example, and taking the > argument to extremes, we should never have allowed HTTP POST over SSL > either. > > This is really Marsh's point, I think, and I agree with it. No, you're entirely confusing things. Independent TLS connection states (even for the same cached TLS session) do not share traffic encryption and mac keys, so these are protected from each other. But when you start multiplexing adaptively chosen plaintext from an attacker with data from a victim, then you're creating an oracle. For TLS cipher suites using block ciphers in CBC mode, there is a fixed encryption key for all blocks of data. Now if the block of data for which the attacker wants to recover the exact plaintext is sufficiently short (e.g. DES-based = 64-bit), and this block of contains a small amount of unknown entropy, and the attacker is permitted sufficient guesses at the original plaintext, the attacker may perform a guessing attempt at that unknown victim data. > > > SSL came before Javascript and even before cookies. So this is certainly > > outside the model. > > Adding AES in CBC mode probably came after the model had been changed > > though. > > Yeah, sure, but I think it's fairer to say that the subject probably > didn't come up, not that SSL was not intended for this. It was not a design requirement at that time, so that property does not exist in the original SSLv3 (and TLS) design. When cipher suites with stream ciphers are not affected, then this is a lucky coincidence, not a result of a conscious design (based on a requirement). > > Block ciphers in counter mode are as broken in the face of key&IV > reuse as any stream cipher, and for the same sorts of reasons. This > is not a reason to not use counter modes. It's a reason to use them > with care. For every block with a known IV and known plaintext, the attacker learns equal to the blocksize IV+plaintext pairs for a static key. (flip the same bit in IV and plaintext and you get the same ciphertext). For CBC, the IV is the ciphertext on the wire from the previous block (except for the first IV on the first record in all version of TLS). > > For example, in a situation like Kerberos' PDUs counter modes are > dangerous because there's no "connection" context for most of those > PDUs, thus no way to prevent key&IV reuse. But for TLS, and even > DTLS, there's no such issue. I actually feel more uncomfortable with cryptographic protocols that are used in automated online scenarios and do not employ replay protection (which probably means that communication with the Kerberos KDC is theoretically vulnerable, and what's missing is only attractive attacks that exploit this.) -Martin From marsh@extendedsubset.com Tue Sep 20 14:45:28 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8C01F0CA5 for ; Tue, 20 Sep 2011 14:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHnMd5OtgSaZ for ; Tue, 20 Sep 2011 14:45:27 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0271F0C91 for ; Tue, 20 Sep 2011 14:45:27 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1R68AU-000FLK-9v; Tue, 20 Sep 2011 21:47:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E55DF606C; Tue, 20 Sep 2011 21:47:51 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18jSs2XYJU6/7C8+OWCZoCkrJOiU4JqRLI= Message-ID: <4E790A09.7020007@extendedsubset.com> Date: Tue, 20 Sep 2011 16:47:53 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: mrex@sap.com References: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> In-Reply-To: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, asteingruebl@paypal-inc.com Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 21:45:28 -0000 On 09/20/2011 04:31 PM, Martin Rex wrote: > > Independent TLS connection states (even for the same cached TLS session) > do not share traffic encryption and mac keys, so these are protected > from each other. > > But when you start multiplexing adaptively chosen plaintext from > an attacker with data from a victim, then you're creating an oracle. It's only an oracle if there is information revealed to the attacker. If that's the case, it should be considered a cryptographic weakness. > For TLS cipher suites using block ciphers in CBC mode, there is > a fixed encryption key for all blocks of data. Now if the > block of data for which the attacker wants to recover the exact > plaintext is sufficiently short (e.g. DES-based = 64-bit), and this > block of contains a small amount of unknown entropy, and the attacker > is permitted sufficient guesses at the original plaintext, the attacker > may perform a guessing attempt at that unknown victim data. Yeah CBC sucks, especially with predictable IVs. It's a weakness. > It was not a design requirement at that time, so that property does > not exist in the original SSLv3 (and TLS) design. When cipher suites > with stream ciphers are not affected, then this is a lucky coincidence, > not a result of a conscious design (based on a requirement). Well where does that reasoning end? If a defect were found in TLS which could be exploited using long strings of the letter 'A', would you say that the protocol was never "designed to resist long strings of the letter 'A' attacks"? This protocol is something called "IETF Transport Layer Security". It's not "Security for Data That M. Rex Feels Web Browsers Should Be Able to Transport Securely". :-) - Marsh From mrex@sap.com Tue Sep 20 14:50:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C5B11E80CC for ; Tue, 20 Sep 2011 14:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.037 X-Spam-Level: X-Spam-Status: No, score=-10.037 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKAatF7ovebw for ; Tue, 20 Sep 2011 14:50:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5893311E80BD for ; Tue, 20 Sep 2011 14:50:56 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8KLrJ35018792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2011 23:53:19 +0200 (MEST) From: Martin Rex Message-Id: <201109202153.p8KLrIQj025096@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 20 Sep 2011 23:53:18 +0200 (MEST) In-Reply-To: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 20, 11 11:31:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, asteingruebl@paypal-inc.com Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 21:50:57 -0000 Martin Rex wrote: > > Nico Williams wrote: > > > > On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker wrote: > > > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex wrote: > > >> SSL was NEVER designed with a promise that you could multiplex > > >> data from an evil attack with data from a victim over the very same > > >> SSL connection and be secure against adaptive chose plaintext > > >> attacks trying to recover data from the victim. > > > > I wasn't there. I don't know what it was designed for. But here's > > the thing: why shouldn't the designers have assumed that some of the > > data sent over SSL might be untrusted? On what grounds would it have > > been OK to say "no untrusted data, please"? And where was this > > restriction documented? > > It is a design limit that should be obvious to the conscious reader > with background knowledge about cryptography. > > > > > > But let's grant that restriction. That would have meant that we > > should never have allowed IMAP over SSL, for example, and taking the > > argument to extremes, we should never have allowed HTTP POST over SSL > > either. > > > > This is really Marsh's point, I think, and I agree with it. > > No, you're entirely confusing things. > > Independent TLS connection states (even for the same cached TLS session) > do not share traffic encryption and mac keys, so these are protected > from each other. > > But when you start multiplexing adaptively chosen plaintext from > an attacker with data from a victim, then you're creating an oracle. > For TLS cipher suites using block ciphers in CBC mode, there is > a fixed encryption key for all blocks of data. Now if the > block of data for which the attacker wants to recover the exact > plaintext is sufficiently short (e.g. DES-based = 64-bit), and this > block of contains a small amount of unknown entropy, and the attacker > is permitted sufficient guesses at the original plaintext, the attacker > may perform a guessing attempt at that unknown victim data. What I forgot: if the attacker knows the IV ahead of time (the IV that will be used to CBC-encrypt the attackers chosen plaintext) or if the attacker can force the IV value that will be used, then the guessing will become extremely effective for low-entropy unknowns (provided that the attacker knows the IV that was used for the unknown, but for CBC that is well known whenever that IV is either explicit or when CBC is used and the unknown io in a later block. -Martin From geoffk@geoffk.org Tue Sep 20 15:33:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC7A11E80BC for ; Tue, 20 Sep 2011 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cD4xsqawXZW for ; Tue, 20 Sep 2011 15:33:09 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBE811E8080 for ; Tue, 20 Sep 2011 15:33:09 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 30A5A33D145; Tue, 20 Sep 2011 22:35:33 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <4E77FAF6.90707@extendedsubset.com> <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 20 Sep 2011 15:35:32 -0700 In-Reply-To: <201109201521.p8KFLR81001748@fs4113.wdf.sap.corp> Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 22:33:10 -0000 Martin Rex writes: > SSL was NEVER designed with a promise that you could multiplex > data from an evil attack with data from a victim over the very same > SSL connection and be secure against adaptive chose plaintext > attacks trying to recover data from the victim. This would imply that you should not use SSL for downloading e-mail using POP or IMAP, because that's multiplexing evil data (mail sent to you by the attacker) with trusted data (credentials and non-evil mail). From mrex@sap.com Tue Sep 20 15:56:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EF421F869E for ; Tue, 20 Sep 2011 15:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.038 X-Spam-Level: X-Spam-Status: No, score=-11.038 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf17zU5vouND for ; Tue, 20 Sep 2011 15:56:32 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0221F86FF for ; Tue, 20 Sep 2011 15:56:31 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8KMwr8M022953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 00:58:53 +0200 (MEST) From: Martin Rex Message-Id: <201109202258.p8KMwqdU029069@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 21 Sep 2011 00:58:52 +0200 (MEST) In-Reply-To: <4E790A09.7020007@extendedsubset.com> from "Marsh Ray" at Sep 20, 11 04:47:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, asteingruebl@paypal-inc.com Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 22:56:33 -0000 Marsh Ray wrote: > > Yeah CBC sucks, especially with predictable IVs. > > It's a weakness. It is a well known design characteristic of CBC-Mode. It only becomes a weakness when CBC-Mode is used inappropriately, like when the same key is used to protect data that ought to be seperate. Or when it is used in a fashion that gives attackers an easy "adaptive chosen plaintext attack capability" for free. (Applied Cryptography 2nd Ed., page 6 (4.) -- such as a Web-Browser that not only runs arbitrary active content as a courtesy to the attacker, but also lets this malicious code re-use an established SSL connection through which supposedly confidential data was transmitted to mount an adaptive chosen plaintext attack. On my sorecard, that is a Browser shooting itself in the foot. > > > It was not a design requirement at that time, so that property does > > not exist in the original SSLv3 (and TLS) design. When cipher suites > > with stream ciphers are not affected, then this is a lucky coincidence, > > not a result of a conscious design (based on a requirement). > > Well where does that reasoning end? > > If a defect were found in TLS which could be exploited using long > strings of the letter 'A', would you say that the protocol was never > "designed to resist long strings of the letter 'A' attacks"? That would be a weakness in the chosen cipher and the particular operating mode that was used for the particular affected cipher suite. Of course, the TLS protocol will inherit any weaknesses from underlying crypto protocols. The TLS renegotiation problem was not a protocol defect of TLS, it was a flawed assumption of consumers of TLS about a security property that never existed. And obviously, noone who relied on TLS renegotiation to be secure ever cared to look at the protocol specification and check whether it really provided such a security property. Anyone who had _seriously_ looked at TLS would have realized that no secure renegotiation property existed in the original SSLv3 specification. > > This protocol is something called "IETF Transport Layer Security". It's > not "Security for Data That M. Rex Feels Web Browsers Should Be Able to > Transport Securely". :-) I know that it is called "IETF Transport Layer Security". But lots of folks seem to confuse TLS with "magic pixie dust" or "snake oil", a panacea that cures everything, known and unknown -- and completely fail to recognize that _every_ design has limits and ignoring any such limits will regularly have dire consequences. If random pads are reused and that results in recovery of both messages that were protected with that random pad through cryptoanalysis of the XORed plaintexts, then this is not a "totally unexpected weakness of the random pad encryption scheme", but instead a known design limit and a complete failure of the users who goofed the management of the cryptographic keys (the random pad). I haven't yet seen a detailed description of the BEAST attack, but what has been leaked so far (and that TLSv1.1 is allegedly not susceptible to this particular attack) suggests that they're exploiting a definite design flaw in the web browser that exhibits an obvious and serious negligence in the management of TLS connection states therefore providing a free "chosen adaptive plaintext attack" facility as a courtesy to the attacker besides the courtesy to run arbitrary attacker-supplied active content. -Martin From mrex@sap.com Tue Sep 20 16:12:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D88A21F8BF0 for ; Tue, 20 Sep 2011 16:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.046 X-Spam-Level: X-Spam-Status: No, score=-10.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgndKTTaMtIU for ; Tue, 20 Sep 2011 16:12:14 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7123C21F8BE8 for ; Tue, 20 Sep 2011 16:12:14 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8KNES2q026545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 01:14:33 +0200 (MEST) From: Martin Rex Message-Id: <201109202314.p8KNERej029946@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Wed, 21 Sep 2011 01:14:27 +0200 (MEST) In-Reply-To: from "Geoffrey Keating" at Sep 20, 11 03:35:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 23:12:15 -0000 Geoffrey Keating wrote: > > Martin Rex writes: > > > SSL was NEVER designed with a promise that you could multiplex > > data from an evil attack with data from a victim over the very same > > SSL connection and be secure against adaptive chose plaintext > > attacks trying to recover data from the victim. > > This would imply that you should not use SSL for downloading e-mail > using POP or IMAP, because that's multiplexing evil data (mail sent to > you by the attacker) with trusted data (credentials and non-evil > mail). You are quite correct in recognizing that you might be helping the attacker in a known-plaintext or chosen-plaintext attack (and when you have an automatically polling IMAP client, maybe even an adaptive chosen-plaintext attack). So it would be sensible to limit the number of guesses for the attacker, and to not re-use the same crypto keys on subsequent accesses to the same IMAP server (TLS does the latter for you when you create a new TLS connection state for each subsequent access, i.e. TLS session resume or full handshake, both will do). -Martin From Jeff.Hodges@KingsMountain.com Tue Sep 20 16:29:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7500321F8CA4 for ; Tue, 20 Sep 2011 16:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.777 X-Spam-Level: X-Spam-Status: No, score=-99.777 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8xGH+VoliVo for ; Tue, 20 Sep 2011 16:29:25 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 89F1321F8CA2 for ; Tue, 20 Sep 2011 16:29:24 -0700 (PDT) Received: (qmail 6337 invoked by uid 0); 20 Sep 2011 23:31:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 20 Sep 2011 23:31:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=QtyV+B2Vfo536hZedgJBj56n4joHoynoJD9goEbSR6U=; b=rhkol7+b9JfxDMnUPxCVBjow2V7IQzCFlVqGK5KlZlgbAORQeyTE6/ccVIb/mhZnS+0bIJpqjk0+oSJNP2AbsX2cdHMpFDmrzT3SO8KvwaOdzJYEuMq3EhT5nIfuT3sk; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.14]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R69n4-0005As-C7 for tls@ietf.org; Tue, 20 Sep 2011 17:31:50 -0600 Message-ID: <4E792266.3050601@KingsMountain.com> Date: Tue, 20 Sep 2011 16:31:50 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 23:29:26 -0000 Martin Rex noted.. > > I haven't yet seen a detailed description of the BEAST attack, but > what has been leaked so far (and that TLSv1.1 is allegedly not > susceptible to this particular attack) suggests that they're > exploiting a definite design flaw in the web browser that exhibits an > obvious and serious negligence in the management of TLS connection states > therefore providing a free "chosen adaptive plaintext attack" facility > as a courtesy to the attacker besides the courtesy to run arbitrary > attacker-supplied active content. uh, yes, web browsers are full of such issues, some by accident, some (more or less) by design.This provides a high-level & very brief survey & bibliography of the landscape.. The Need for a Coherent Web Security Policy Framework See also.. Browser Security Handbook https://code.google.com/p/browsersec/wiki/Main =JeffH From nico@cryptonector.com Tue Sep 20 16:31:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE85421F8CAE for ; Tue, 20 Sep 2011 16:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvtqJP1Ar+qp for ; Tue, 20 Sep 2011 16:31:02 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id BC3DB21F8CA9 for ; Tue, 20 Sep 2011 16:30:50 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id B48B91F0087 for ; Tue, 20 Sep 2011 16:33:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=LXmMsQYxGcfiVhX7jMWlFVDgN9kj8wSDA4/qfQfOV86W fRyaB7z3PR1rjVFp0/z6Khh49TM4WVhknA0KS+GmQpnvAKfLLCtGTaYI5RA+CX9X Osoh4ChbTtxipiytrsoHRwZ3sFzFK2qxZohEno6abcZMFQYca2nW8I8kTeHzkEM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=5XG3wDD8t1WMIvSF1KqxjPY/aLo=; b=ZQmgmq2a1h8 pAwCLlaTcD5tOufN+AgOAHFO2foPFk050YS2ZyN/MTc7c3BekxSnJOSPz1yHDPF3 UX1+hyUXp9PqZ92GAkbWOnEnJZjnPEmdMqAQrLqVe6R2+CYOEc995TePpmwu8yMx i4kzevITZ+CFGQSJTxAful0RFHLzcAr4= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 954CE1F0081 for ; Tue, 20 Sep 2011 16:33:17 -0700 (PDT) Received: by pzk37 with SMTP id 37so548992pzk.9 for ; Tue, 20 Sep 2011 16:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.50.68 with SMTP id a4mr362856pbo.64.1316561597117; Tue, 20 Sep 2011 16:33:17 -0700 (PDT) Received: by 10.68.60.4 with HTTP; Tue, 20 Sep 2011 16:33:17 -0700 (PDT) In-Reply-To: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> References: <201109202131.p8KLVpd0024045@fs4113.wdf.sap.corp> Date: Tue, 20 Sep 2011 18:33:17 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 23:31:02 -0000 On Tue, Sep 20, 2011 at 4:31 PM, Martin Rex wrote: > Nico Williams wrote: >> On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker = wrote: >> > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex wrote: >> >> SSL was NEVER designed with a promise that you could multiplex >> >> data from an evil attack with data from a victim over the very same >> >> SSL connection and be secure against adaptive chose plaintext >> >> attacks trying to recover data from the victim. >> >> I wasn't there. =C2=A0I don't know what it was designed for. =C2=A0But h= ere's >> the thing: why shouldn't the designers have assumed that some of the >> data sent over SSL might be untrusted? =C2=A0On what grounds would it ha= ve >> been OK to say "no untrusted data, please"? =C2=A0And where was this >> restriction documented? > > It is a design limit that should be obvious to the conscious reader > with background knowledge about cryptography. It's been roughly two decades, and only now did this get noticed. And there are many experts who've worked on TLS and apps that use it. Undocumented design limitations are not obvious, even if in retrospect they should have been. >> But let's grant that restriction. =C2=A0That would have meant that we >> should never have allowed IMAP over SSL, for example, and taking the >> argument to extremes, we should never have allowed HTTP POST over SSL >> either. >> >> This is really Marsh's point, I think, and I agree with it. > > No, you're entirely confusing things. > > Independent TLS connection states (even for the same cached TLS session) > do not share traffic encryption and mac keys, so these are protected > from each other. I said nothing about sharing of keys across connections. I did not even imply it. > But when you start multiplexing adaptively chosen plaintext from > an attacker with data from a victim, then you're creating an oracle. Multiplexing? Just mixing will do. IMAP lets you... read emails from untrusted sources (e.g., spam), as well as ones from trusted sources. Oops. This is silly. Nico -- From mrex@sap.com Tue Sep 20 17:08:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83A41F0C44 for ; Tue, 20 Sep 2011 17:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-UUjWSLfal1 for ; Tue, 20 Sep 2011 17:08:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 027781F0C47 for ; Tue, 20 Sep 2011 17:08:03 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8L0AP6P002502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 02:10:25 +0200 (MEST) From: Martin Rex Message-Id: <201109210010.p8L0AOMB003130@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Wed, 21 Sep 2011 02:10:24 +0200 (MEST) In-Reply-To: from "Nico Williams" at Sep 20, 11 06:33:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 00:08:07 -0000 Nico Williams wrote: > > Martin Rex wrote: > > > data sent over SSL might be untrusted?  On what grounds would it have > > > been OK to say "no untrusted data, please"?  And where was this > > > restriction documented? > > > > It is a design limit that should be obvious to the conscious reader > > with background knowledge about cryptography. > > It's been roughly two decades, and only now did this get noticed. And > there are many experts who've worked on TLS and apps that use it. > > Undocumented design limitations are not obvious, even if in retrospect > they should have been. You seem to be approaching the issue from the wrong end. Rely only on those design properties that have been explicitly specified _and_ independently verified. NEVER assume capabilities / properties that are neither specified nor independently verified. Of course, taking short cuts is much easier and cheaper, but don't complain later if you get burnt. > > > But when you start multiplexing adaptively chosen plaintext from > > an attacker with data from a victim, then you're creating an oracle. > > Multiplexing? Just mixing will do. IMAP lets you... read emails from > untrusted sources (e.g., spam), as well as ones from trusted sources. > Oops. This is silly. No, this isn't silly. Welcome to the real world. Your 2^112 bits symmetric crypto strength for 3DES-EDE-CBC and 2^128 bits symmetric crypto strength for AES128-CBC can be significantly reduced by your usage scenarios. In a highly automated online world up to the point of non-existence, as in Rizzo's last years demonstration for ASP.NET: http://www.schneier.com/blog/archives/2010/09/new_attack_agai_1.html Such flaws are _not_ limited to propriatary misuse of crypto. There is more to come later this year. -Martin From mrex@sap.com Tue Sep 20 18:17:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F16821F8C76 for ; Tue, 20 Sep 2011 18:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr5qvSmq0cbi for ; Tue, 20 Sep 2011 18:17:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9D05921F8C61 for ; Tue, 20 Sep 2011 18:17:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8L1JpW4003149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 03:19:51 +0200 (MEST) From: Martin Rex Message-Id: <201109210119.p8L1Jo9w007503@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Wed, 21 Sep 2011 03:19:50 +0200 (MEST) In-Reply-To: from "Nico Williams" at Sep 20, 11 04:04:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 01:17:30 -0000 Nico Williams wrote: > > I wasn't there. I don't know what it was designed for. But here's > the thing: why shouldn't the designers have assumed that some of the > data sent over SSL might be untrusted? On what grounds would it have > been OK to say "no untrusted data, please"? And where was this > restriction documented? Btw. in my reading, it is documented in TLS v1.0 (rfc2246) http://tools.ietf.org/html/rfc2246#section-6 Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. -Martin From mrex@sap.com Tue Sep 20 18:40:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1784411E80B4 for ; Tue, 20 Sep 2011 18:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oizLNH43vXRJ for ; Tue, 20 Sep 2011 18:40:08 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 428BF11E80B1 for ; Tue, 20 Sep 2011 18:40:08 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8L1gNX3014004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 03:42:28 +0200 (MEST) From: Martin Rex Message-Id: <201109210142.p8L1gM3s008605@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 21 Sep 2011 03:42:22 +0200 (MEST) In-Reply-To: <201109202314.p8KNERej029946@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 21, 11 01:14:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 01:40:09 -0000 Martin Rex wrote: > > Geoffrey Keating wrote: > > > > Martin Rex writes: > > > > > SSL was NEVER designed with a promise that you could multiplex > > > data from an evil attack with data from a victim over the very same > > > SSL connection and be secure against adaptive chose plaintext > > > attacks trying to recover data from the victim. > > > > This would imply that you should not use SSL for downloading e-mail > > using POP or IMAP, because that's multiplexing evil data (mail sent to > > you by the attacker) with trusted data (credentials and non-evil > > mail). > > You are quite correct in recognizing that you might be helping > the attacker in a known-plaintext or chosen-plaintext attack (and when > you have an automatically polling IMAP client, maybe even an adaptive > chosen-plaintext attack). So it would be sensible to limit the number > of guesses for the attacker, and to not re-use the same crypto keys > on subsequent accesses to the same IMAP server (TLS does the latter for > you when you create a new TLS connection state for each subsequent access, > i.e. TLS session resume or full handshake, both will do). Ooops -- what I forgot: Your IMAP cleartext logon password travels Client->Server and the attackers EMail on download travels Server->Client. Since TLS uses distinct traffic encryption and mac keys for both directions, there is no chosen plaintext or adaptive chosen plaintext attack for the particular situation of IMAP Email download, I believe. But that would also suggest that BEAST is not attacking the Cookie from the Server response, but instead the cookie from a client request. (If the browser automatically inserts the cookie into arbitrary requests issued by the attackers malware, then this would mean that a serious Cross-Site-Request-Forgery problem in the browser is a prerequisite for the BEAST attack to succeed. -Martin From nico@cryptonector.com Tue Sep 20 19:23:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB67C21F8C61 for ; Tue, 20 Sep 2011 19:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm2SHcbCr1TU for ; Tue, 20 Sep 2011 19:23:46 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6312721F8C5F for ; Tue, 20 Sep 2011 19:23:46 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id C629F584058 for ; Tue, 20 Sep 2011 19:26:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=D6AzPQpKRbO6sSwHeZusk PC/KG3g3iBVuI5Yk2NkvDTOzvmnlHOZDUDhQPhtpqlzjudfOHvF82EQrwKAsIAII jE73Ufhu24bbptcWLC1lanbfr1lOEIurZe+whuLQx32aJonhEG+f5eR0+XLlwzy+ t0vN8E5jL9inbnJJKxTUOo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=mfiblHlPZYCzgWRBS6OY jCTCHmw=; b=LOHFz3E53ril8c6Qpk6MiV/xZWphOD2X2UED1yMbcI0nAneWVIeZ 6C278nXwk20BMY/bF+Y4qXDee7OMJas/2bWu4ByoaYh7UvnAE1VZqGiKHYQIisRi YiEAfMvkjwCaPuw/okzuAWiCNi+zC9sN/cKEiOla3joSAMlNhgRuzPg= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 9F94B584057 for ; Tue, 20 Sep 2011 19:26:13 -0700 (PDT) Received: by yxt33 with SMTP id 33so1007329yxt.31 for ; Tue, 20 Sep 2011 19:26:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.46.101 with SMTP id u5mr562453pbm.332.1316571972638; Tue, 20 Sep 2011 19:26:12 -0700 (PDT) Received: by 10.68.60.4 with HTTP; Tue, 20 Sep 2011 19:26:12 -0700 (PDT) In-Reply-To: <201109210010.p8L0AOMB003130@fs4113.wdf.sap.corp> References: <201109210010.p8L0AOMB003130@fs4113.wdf.sap.corp> Date: Tue, 20 Sep 2011 21:26:12 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 02:23:47 -0000 On Tue, Sep 20, 2011 at 7:10 PM, Martin Rex wrote: > Nico Williams wrote: >> Martin Rex wrote: >> Undocumented design limitations are not obvious, even if in retrospect >> they should have been. > > You seem to be approaching the issue from the wrong end. As if I was at fault. Or as if saying any of this could undo what happened. Did SSLv2, v3, TLS 1.0, say anything that would have caused others to realize that it was not a good choice of technology for IMAP, or to notice that JavaScript in browsers was a recipe for disaster? RFC2246 doesn't say anything about this: section F outlines the threat model and says nothing about carrying untrusted content, but that's hardly dispositive. Nico -- From marsh@extendedsubset.com Tue Sep 20 19:31:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A7021F8C83 for ; Tue, 20 Sep 2011 19:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-UEHgCum6r1 for ; Tue, 20 Sep 2011 19:31:05 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 025A221F8C88 for ; Tue, 20 Sep 2011 19:31:04 -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 1R6Ccu-0001S1-8n; Wed, 21 Sep 2011 02:33:32 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 32498606C; Wed, 21 Sep 2011 02:33: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: U2FsdGVkX19OUNl5L4vPdZbSoBP/Sjrj5j6iMA5oyXo= Message-ID: <4E794CF9.5080408@extendedsubset.com> Date: Tue, 20 Sep 2011 21:33:29 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: mrex@sap.com References: <201109210142.p8L1gM3s008605@fs4113.wdf.sap.corp> In-Reply-To: <201109210142.p8L1gM3s008605@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: asteingruebl@paypal-inc.com, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 02:31:05 -0000 On 09/20/2011 08:42 PM, Martin Rex wrote: > > But that would also suggest that BEAST is not attacking the > Cookie from the Server response, but instead the cookie from a > client request. (If the browser automatically inserts the cookie into > arbitrary requests issued by the attackers malware, then this would > mean that a serious Cross-Site-Request-Forgery problem in the browser > is a prerequisite for the BEAST attack to succeed. But such an attack would only need the cookie sent once client-to-server. A GET request which sends the secret cookie would work just fine. If there happened to be additional request(s) over that channel transmit the adaptive plaintext (constructed from the ciphertext block containing secret cookie data), would it actually be a requirement that they re-send the cookie then? Even if there were CSRF restrictions on cookies, would they apply to GET and POST equally? If cookie restrictions applied to GET, how would https://google-analytics.com/ work? Sorry if I sound nonsensically hypothetical. I'm still trying to figure out what I've promised not to say vs. what I already knew. :-) - Marsh From nico@cryptonector.com Tue Sep 20 19:38:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A00B21F8BE8 for ; Tue, 20 Sep 2011 19:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNp1v2AhM2sB for ; Tue, 20 Sep 2011 19:38:42 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E861821F8BDC for ; Tue, 20 Sep 2011 19:38:42 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 5B5F0202018 for ; Tue, 20 Sep 2011 19:41:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ynZCMxuOVRp973h4IW9X8a90g9+p2pD1V9zr6ULyEz/v k81uWcZKCHupP4sXpo32in672VpEXI/qFYfqBtfwwlNWCwXMUOyCuUMmEV5HCtts bqRRha5Q86k/GRKLIwpCi1JQhVQg6quKRU3lJKht0JgAU9IYeVvwXy63n7QY4Ws= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=MMObEYnDUZuBQDN0m9tAJq26rlQ=; b=TynmyZFk0sR mQgeJvwvbg7pPleR0ner8SQVFMGgXt1oYkIjKv6q6T4Z1OHnmBhCaxMMldR6J+vt GzMRJFVGQ6D3sC1bPp6Qvp9HfQ+t8cJ9Tl5zmJ4PVY/UeIwguusTL2w2mBdziCz8 d98h0IXz0ycmu9W/ALawCVdVM6kSJ0tE= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 3329B202017 for ; Tue, 20 Sep 2011 19:41:10 -0700 (PDT) Received: by pzk37 with SMTP id 37so895284pzk.9 for ; Tue, 20 Sep 2011 19:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.129 with SMTP id g1mr578913pbk.399.1316572869946; Tue, 20 Sep 2011 19:41:09 -0700 (PDT) Received: by 10.68.60.4 with HTTP; Tue, 20 Sep 2011 19:41:09 -0700 (PDT) In-Reply-To: <201109210142.p8L1gM3s008605@fs4113.wdf.sap.corp> References: <201109202314.p8KNERej029946@fs4113.wdf.sap.corp> <201109210142.p8L1gM3s008605@fs4113.wdf.sap.corp> Date: Tue, 20 Sep 2011 21:41:09 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: asteingruebl@paypal-inc.com, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 02:38:43 -0000 On Tue, Sep 20, 2011 at 8:42 PM, Martin Rex wrote: > But that would also suggest that BEAST is not attacking the > Cookie from the Server response, but instead the cookie from a > client request. =C2=A0(If the browser automatically inserts the cookie in= to > arbitrary requests issued by the attackers malware, then this would > mean that a serious Cross-Site-Request-Forgery problem in the browser > is a prerequisite for the BEAST attack to succeed. It's almost certainly the case that BEAST works by adding an IMG element to a page where one of its scripts can run, with the IMG referring to a resource on the service that the attacker wants to steal cookies to, with the script and the eavesdropper working to attack the GET of the IMG src to extract any cookies from the GET request. At least that's how I imagine it to work. So, yes, that would be the client request that's getting attacked. We'll find out soon enough. Nico -- From mrex@sap.com Tue Sep 20 19:59:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539C321F8CB6 for ; Tue, 20 Sep 2011 19:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.05 X-Spam-Level: X-Spam-Status: No, score=-10.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VX1IHUo5Y21 for ; Tue, 20 Sep 2011 19:59:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2157C21F8CB3 for ; Tue, 20 Sep 2011 19:59:28 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8L31kiV013667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 05:01:46 +0200 (MEST) From: Martin Rex Message-Id: <201109210301.p8L31jLK013412@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 21 Sep 2011 05:01:45 +0200 (MEST) In-Reply-To: <4E794CF9.5080408@extendedsubset.com> from "Marsh Ray" at Sep 20, 11 09:33:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 02:59:30 -0000 Marsh Ray wrote: > > On 09/20/2011 08:42 PM, Martin Rex wrote: > > > > But that would also suggest that BEAST is not attacking the > > Cookie from the Server response, but instead the cookie from a > > client request. (If the browser automatically inserts the cookie into > > arbitrary requests issued by the attackers malware, then this would > > mean that a serious Cross-Site-Request-Forgery problem in the browser > > is a prerequisite for the BEAST attack to succeed. > > > But such an attack would only need the cookie sent once > client-to-server. A GET request which sends the secret cookie would work > just fine. If there happened to be additional request(s) over that > channel transmit the adaptive plaintext That is a vital prerequisite. The Javascript of the BEAST trojan would have to be dribbling out SSL records based on the very same TLS Connection status (and watch that encrypted network traffic to learn the last Cipherblock in the SSL record that will be used as IV to the next SSL record in SSLv3&TLSv1.0 in order to fabricate the next guess for the plaintext (->adaptively chosen plaintext). But in order for the attack to succeed so fast in guessing (10 minutes for the PayPal cookie) I would expect that there needs to be a small block size (3DES-EDE-CBC) plus a fairly low entropy in that Cookie. A sensible cookie would be base64-encoded and contain at least 128-bit strong random (meaning up to 48 bits of entropy per cipher block and 2-3 blocks to recover). Much less guessing if it uses an unsafe low-entropy cookie or a very inefficient encoding (but more blocks to guess). > (constructed from the ciphertext > block containing secret cookie data), would it actually be a requirement > that they re-send the cookie then? No, one cookie is sufficient if the connection does not abort during the attack. But spreading the attack over multiple successive or parallel requests (one for each cipher block, each request with its own encryption keys and encrypted cookie) and combinding the results should work. > > Even if there were CSRF restrictions on cookies, would they apply to GET > and POST equally? Since the client needs to send a significant number of small SSL records with stuff that will look like junk to the Server. The server might be more patiently with a (dribbling) POST than a GET in this respect. -Martin From mrex@sap.com Wed Sep 21 13:46:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80B71F0CDD for ; Wed, 21 Sep 2011 13:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.752 X-Spam-Level: X-Spam-Status: No, score=-9.752 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASXJLC5WBYPe for ; Wed, 21 Sep 2011 13:46:08 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E8E221F0CB1 for ; Wed, 21 Sep 2011 13:46:07 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8LKmYPl024896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Sep 2011 22:48:34 +0200 (MEST) From: Martin Rex Message-Id: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 21 Sep 2011 22:48:33 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 20:46:09 -0000 Does anyone (SSL Labs, Opera, others) have any figures/stats about the current "TLSv1.1 version (in)tolerance" for TLS servers on the public internet? A quick google search about the current client side situation for proposing TLSv1.1 gave me (among others) to this information: http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx I am somewhat puzzled about the description of the reconnect fallback described there for WinINET, and I believe that code/logic is wrong. Quoting: If you examine the Encrypted Alert from the server, you will see that it contains the byte sequence 02 46, meaning Fatal Alert: Protocol Version. The server isn't supposed to behave this wayits instead expected to simply reply using the latest HTTPS protocol version it supports (e.g. "3.1 aka TLS 1.0). Now, had the server gracefully closed the connection at this point, it would be okay-- code in WinINET would fallback and retry the connection offering only TLS 1.0. The only downside would be performancethe extra roundtrips required for the new TLS 1.0 handshake will usually result in a penalty amounting to tens or hundreds of milliseconds. However, this server used a TCP/IP RST to abort the connection, which disables the fallback code in WinINET and causes the entire connection sequence to be abandoned, leaving the user with the Internet Explorer cannot display the webpage error message. I believe that the Server's TCP/IP stack closing the connection with RST is OK and perfectly permissible, and WinINET ought to use a reconnect fallback here. TCP RST with the meaning ("no one is listening") applies only when an RST is received _instead_of_ SYN+ACK during TCP connection establishment, with the effect of synchronous connect() failing with an error or asynchrounous connect reporting an error on getsockopt() after signalling writability. In the above case, connect() had definitely successfully completed -- they did send the ClientHello and even did receive an SSL Alert, didn't they?) But on top of that, the WinINET client seeing a fatal "protocol_version" TLS alert is a "Blue's clue" on suggested retrying with TLSv1.0. The TCP RST in the above situation, as described in Stevens' Network Programming, Section 7.5, Socket Option SO_LINGER, only indicates the specific SO_LINGER setting that the server had used for his side of the connection / his socket (Fig. 7.10 close() l_onoff=1, l_linger=0) The SO_LINGER setting for a socket is entirely at the discretion of each peer and closing the socket immediately after sending a fatal alert is exactly what the TLS spec suggests: http://tools.ietf.org/html/rfc2246#section-7.2.2 7.2.2. Error alerts Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of an fatal alert message, both parties immediately close the connection. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^! I believe that the informtion in this blog is incorrect (about what the server should do and about what WinINET should do) and if my analysis is correct this information should be fixed or removed. Likewise, if my analsis is correct and that Blog accurately describes WinINETs behaviour, that WinINET behaviour should be fixed to allow MSIE users on Win7 to enable TLSv1.1 with less risk of interop problems. -Martin From yngve@opera.com Wed Sep 21 14:29:38 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF3711E80C5 for ; Wed, 21 Sep 2011 14:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkpJFsZk9jVR for ; Wed, 21 Sep 2011 14:29:37 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2F11E80AA for ; Wed, 21 Sep 2011 14:29:37 -0700 (PDT) Received: from acorna.oslo.osa (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 p8LLW4RE003727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2011 21:32:05 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "Martin Rex" References: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> Date: Wed, 21 Sep 2011 23:32:12 +0200 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: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.63 (Win32) Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 21:29:38 -0000 On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex wrote: > Does anyone (SSL Labs, Opera, others) have any figures/stats about the > current "TLSv1.1 version (in)tolerance" for TLS servers on the public > internet? This week's test of 609726 servers gave these numbers: * 1.145% of the probed servers were version intolerant for at least one of the current TLS versions (1.0, 1.1, 1.2) * 1.742% were extension intolerant for the same versions * 1.136% belonged in both groups This gives an estimated total of 1.751% that are either version and/or extension intolerant for the currently defined TLS versions. These numbers have been decreasing during the past year and a half, around January 2011 it was 1.951% just for the version intolerant, 2.657% in may 2010 (the extension numbers are not as detailed for those runs). Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, but some are SSLv3 only servers that are also intolerant for TLS 1.0. There is even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn" as the hostname). If Opera encounters an intolerant server it will shut down the connection and fall back step by step. Essentially, the fallback sequence is currently TLS 1.0 + extensions TLS 1.0 w/o extensions SSL v3 Upwards it is v1.1 and v1.2, and fallback if negotiation failed. -- 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 ynir@checkpoint.com Wed Sep 21 14:44:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCAF11E8124 for ; Wed, 21 Sep 2011 14:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.401 X-Spam-Level: X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkAf2k1ownxL for ; Wed, 21 Sep 2011 14:44:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E11FF11E811A for ; Wed, 21 Sep 2011 14:44:48 -0700 (PDT) X-CheckPoint: {4E7A687A-14-1B221DC2-FFFF} 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 p8LLlGL6003236; Thu, 22 Sep 2011 00:47:16 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 22 Sep 2011 00:47:16 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 22 Sep 2011 00:47:17 +0300 From: Yoav Nir To: "Yngve N. Pettersen (Developer Opera Software ASA)" Date: Thu, 22 Sep 2011 00:47:14 +0300 Thread-Topic: [TLS] interop for TLS clients proposing TLSv1.1 Thread-Index: Acx4qAc6cSlg44atRE+0mCfuTIMQ3w== Message-ID: <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com> References: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 21:44:49 -0000 Hi Yngve On Sep 22, 2011, at 12:32 AM, Yngve N. Pettersen (Developer Opera Software = ASA) wrote: > On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex wrote: >=20 >> Does anyone (SSL Labs, Opera, others) have any figures/stats about the >> current "TLSv1.1 version (in)tolerance" for TLS servers on the public >> internet? >=20 > This week's test of 609726 servers gave these numbers: >=20 > * 1.145% of the probed servers were version intolerant for at least one= =20 > of the current TLS versions (1.0, 1.1, 1.2) > * 1.742% were extension intolerant for the same versions > * 1.136% belonged in both groups >=20 > This gives an estimated total of 1.751% that are either version and/or =20 > extension intolerant for the currently defined TLS versions. >=20 > These numbers have been decreasing during the past year and a half, aroun= d =20 > January 2011 it was 1.951% just for the version intolerant, 2.657% in may= =20 > 2010 (the extension numbers are not as detailed for those runs). >=20 > Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, bu= t =20 > some are SSLv3 only servers that are also intolerant for TLS 1.0. There i= s =20 > even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn" = =20 > as the hostname). By "version intolerant" do you mean that you're sending a TLS 1.1 or 1.2 ha= ndshake message and the server rejects it? If you send a TLS 1.0 handshake message, with the version field of the Clie= ntHello showing 1.2, what portion of the servers would reject that (rather = than just replying in TLS 1.0)? Is that something you measure? If the portion is very low, it could be fea= sible to implement a client without fallback behavior. Yoav= From mrex@sap.com Wed Sep 21 15:22:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7171F0CFC for ; Wed, 21 Sep 2011 15:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.051 X-Spam-Level: X-Spam-Status: No, score=-10.051 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjxsIXBwRIrQ for ; Wed, 21 Sep 2011 15:22:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ADED81F0CF1 for ; Wed, 21 Sep 2011 15:22:24 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8LMOfV2009822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 00:24:46 +0200 (MEST) From: Martin Rex Message-Id: <201109212224.p8LMOemO019618@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Thu, 22 Sep 2011 00:24:40 +0200 (MEST) In-Reply-To: <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com> from "Yoav Nir" at Sep 22, 11 00:47:14 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 22:22:27 -0000 Yoav Nir wrote: > > Yngve N. Pettersen (Developer Opera Software ASA) wrote: > > > > Martin Rex wrote: > > > > > > Does anyone (SSL Labs, Opera, others) have any figures/stats about the > > > current "TLSv1.1 version (in)tolerance" for TLS servers on the public > > > internet? > > > > This week's test of 609726 servers gave these numbers: > > > > * 1.145% of the probed servers were version intolerant for at least one > > of the current TLS versions (1.0, 1.1, 1.2) > > * 1.742% were extension intolerant for the same versions > > * 1.136% belonged in both groups > > > > This gives an estimated total of 1.751% that are either version and/or > > extension intolerant for the currently defined TLS versions. > > > > These numbers have been decreasing during the past year and a half, around > > January 2011 it was 1.951% just for the version intolerant, 2.657% in may > > 2010 (the extension numbers are not as detailed for those runs). > > > > Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, but > > some are SSLv3 only servers that are also intolerant for TLS 1.0. There is > > even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn" > > as the hostname). > > By "version intolerant" do you mean that you're sending a TLS 1.1 > or 1.2 handshake message and the server rejects it? > > If you send a TLS 1.0 handshake message, with the version field of the > ClientHello showing 1.2, what portion of the servers would reject that > (rather than just replying in TLS 1.0)? The latter is what I'm actually interested in (but seem not have been sufficiently clear about). Sending TLSv1.1 or TLSv1.2 in the Record Layer for ClientHello constitutes a version-intolerant client (or more appropriately it indicates a client that is unwilling to talk TLSv1.0). Other than a very last resort in trying to get a TLS handshake succeed I see little value in sending a value above TLSv1.0 in the protocol version field of the SSL3 Record carrying the initial ClientHello on a connection. > > If the portion is very low, it could be feasible to implement a > client without fallback behavior. Since "fallback behaviour" is dumped entirely on the app calling the TLS implementation, I expect "clients without fallback behaviour" to be the norm for programmatic clients. The version intolerance stats for public servers on the internet is not really representative. I expect a significant amount of version-intolerant servers to not be publicly accessible. I'm seeing a desire to raise the number of TLS peers use TLSv1.1 with CBC-based cipher suites and explicit IVs, and I'm also seeing a residual, non-negligible number of version intolerant TLS servers interfering with original design of TLS protocol version negotiation. I would appreciate a solution for decoupling of these two issues so that clients without fallback capabilities become able to use TLSv1.1 right away, while neither facing new interop problems or having to wait 5+ years for sufficient of the version intolerant TLS servers to die. -Martin From mrex@sap.com Wed Sep 21 15:28:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9482D21F8C9E for ; Wed, 21 Sep 2011 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.052 X-Spam-Level: X-Spam-Status: No, score=-10.052 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLwRic4LXwaQ for ; Wed, 21 Sep 2011 15:28:26 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D9FBE21F8AB0 for ; Wed, 21 Sep 2011 15:28:25 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8LMUmJM004758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 00:30:53 +0200 (MEST) From: Martin Rex Message-Id: <201109212230.p8LMUmc2020172@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 22 Sep 2011 00:30:48 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Sep 21, 11 11:32:12 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 22:28:26 -0000 Yngve N. Pettersen wrote: > > On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex wrote: > > > Does anyone (SSL Labs, Opera, others) have any figures/stats about the > > current "TLSv1.1 version (in)tolerance" for TLS servers on the public > > internet? > > This week's test of 609726 servers gave these numbers: > > * 1.145% of the probed servers were version intolerant for at least one > of the current TLS versions (1.0, 1.1, 1.2) > * 1.742% were extension intolerant for the same versions > * 1.136% belonged in both groups > > This gives an estimated total of 1.751% that are either version and/or > extension intolerant for the currently defined TLS versions. OK, I'll try to be more specific about the numbers that *I* would be interest in (in case you could extract from your data): When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer), how many servers abort immediately, depending on the value of the client_version: for client_version = { 0x03,0x00 } (SSLv3) for client_version = { 0x03,0x01 } (TLSv1.0) for client_version = { 0x03,0x02 } (TLSv1.1) for client_version = { 0x03,0x03 } (TLSv1.2) and how many continue the handshake but fail the finished macs? -Martin From yngve@opera.com Wed Sep 21 15:42:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3FE1F0CE4 for ; Wed, 21 Sep 2011 15:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VyZXZZMqPpZ for ; Wed, 21 Sep 2011 15:42:01 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0490A21F8BF7 for ; Wed, 21 Sep 2011 15:42:00 -0700 (PDT) Received: from acorna.oslo.osa (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 p8LMiKCL015442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2011 22:44:21 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Organization: Opera Software AS References: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com> To: "Yoav Nir" Date: Thu, 22 Sep 2011 00:44:29 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Message-ID: In-Reply-To: <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com> User-Agent: Opera Mail/10.63 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 22:42:02 -0000 On Wed, 21 Sep 2011 23:47:14 +0200, Yoav Nir wrote: > Hi Yngve > > On Sep 22, 2011, at 12:32 AM, Yngve N. Pettersen (Developer Opera > Software ASA) wrote: > >> On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex wrote: >> >>> Does anyone (SSL Labs, Opera, others) have any figures/stats about the >>> current "TLSv1.1 version (in)tolerance" for TLS servers on the public >>> internet? >> >> This week's test of 609726 servers gave these numbers: >> >> * 1.145% of the probed servers were version intolerant for at least >> one >> of the current TLS versions (1.0, 1.1, 1.2) >> * 1.742% were extension intolerant for the same versions >> * 1.136% belonged in both groups >> >> This gives an estimated total of 1.751% that are either version and/or >> extension intolerant for the currently defined TLS versions. >> >> These numbers have been decreasing during the past year and a half, >> around >> January 2011 it was 1.951% just for the version intolerant, 2.657% in >> may >> 2010 (the extension numbers are not as detailed for those runs). >> >> Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, >> but >> some are SSLv3 only servers that are also intolerant for TLS 1.0. There >> is >> even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn" >> as the hostname). > > By "version intolerant" do you mean that you're sending a TLS 1.1 or 1.2 > handshake message and the server rejects it? > > If you send a TLS 1.0 handshake message, with the version field of the > ClientHello showing 1.2, what portion of the servers would reject that > (rather than just replying in TLS 1.0)? > > Is that something you measure? If the portion is very low, it could be > feasible to implement a client without fallback behavior. The testing is performed using two record protocol versions: Either 3.0 or 3.1 (starting with 3.0), depending on what actually works The record version is supposed to be the lowest version the server is known to support. At present all clients are AFAIK sending 3.1, unless they are offering 3.0 as the highest version, or is trying 3.0 in combination with 3.1. Intolerance is considered present if the server does not negotiate a version it is known to support, when a higher version than supported is sent in the Client Hello (e.g 3.1 is known, sending 3.2), and there is some form of handshake failure (including abrupt connection shutdown) either as the handshake is sent, or during the handshake, before it is completed. There are some servers (0.487%), for example www.mozilla.com, that will not negotiate TLS 1.0 (0.487%) or TLS 1.1 (0.217%) if the record protocol is 3.0. Extension intolerance is detected in a similar fashion. -- 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 geoffk@geoffk.org Wed Sep 21 15:52:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33751F0D0F for ; Wed, 21 Sep 2011 15:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsqfxUfLzdEq for ; Wed, 21 Sep 2011 15:52:08 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 426B81F0CF9 for ; Wed, 21 Sep 2011 15:52:08 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 8128933D145; Wed, 21 Sep 2011 22:54:35 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 21 Sep 2011 15:54:35 -0700 In-Reply-To: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> Message-ID: Lines: 43 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 22:52:08 -0000 Martin Rex writes: > Does anyone (SSL Labs, Opera, others) have any figures/stats about the > current "TLSv1.1 version (in)tolerance" for TLS servers on the public > internet? I find that about 1.4% of servers will refuse to connect using a TLS 1.2 hello but will connect using a TLS 1.0 hello. Some of those might be unhappy about something else in the TLS 1.2 hello (extensions, for example). The other 99% accept a TLS 1.2 hello, even though only a small fraction (about 0.15%) actually supports TLS 1.1 or 1.2. > The TCP RST in the above situation, as described in Stevens' Network > Programming, Section 7.5, Socket Option SO_LINGER, only indicates the > specific SO_LINGER setting that the server had used for his side > of the connection / his socket (Fig. 7.10 close() l_onoff=1, l_linger=0) > > The SO_LINGER setting for a socket is entirely at the discretion of each peer > and closing the socket immediately after sending a fatal alert is exactly > what the TLS spec suggests: > > http://tools.ietf.org/html/rfc2246#section-7.2.2 > > 7.2.2. Error alerts > > Error handling in the TLS Handshake protocol is very simple. When an > error is detected, the detecting party sends a message to the other > party. Upon transmission or receipt of an fatal alert message, both > parties immediately close the connection. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^! RFC 793 says, in section 3.5, that a connection is closed by sending a FIN. A RST is not a close of the connection but an abort; as RFC 793 says, "Such a message indicates to the site B TCP that something is wrong, and it is expected to abort the connection." However, the question of how to close the connection is secondary, because it should not have been closed in the first place; as the blog entry says, "The server isn't supposed to behave this way---it's instead expected to simply reply using the latest HTTPS protocol version it supports". You can't really expect software that's broken in one way to work perfectly in all other ways... From yngve@opera.com Wed Sep 21 16:17:04 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997F511E8095 for ; Wed, 21 Sep 2011 16:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEJH9YjSjFVD for ; Wed, 21 Sep 2011 16:17:03 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 853E611E8073 for ; Wed, 21 Sep 2011 16:17:03 -0700 (PDT) Received: from acorna.oslo.osa (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 p8LNJUt6021066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2011 23:19:31 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <201109212230.p8LMUmc2020172@fs4113.wdf.sap.corp> Date: Thu, 22 Sep 2011 01:19:38 +0200 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: <201109212230.p8LMUmc2020172@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.63 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:17:04 -0000 On Thu, 22 Sep 2011 00:30:48 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex wrote: >> >> > Does anyone (SSL Labs, Opera, others) have any figures/stats about the >> > current "TLSv1.1 version (in)tolerance" for TLS servers on the public >> > internet? >> >> This week's test of 609726 servers gave these numbers: >> >> * 1.145% of the probed servers were version intolerant for at least >> one >> of the current TLS versions (1.0, 1.1, 1.2) >> * 1.742% were extension intolerant for the same versions >> * 1.136% belonged in both groups >> >> This gives an estimated total of 1.751% that are either version and/or >> extension intolerant for the currently defined TLS versions. > > OK, I'll try to be more specific about the numbers that > *I* would be interest in (in case you could extract from your data): > > When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer), > how many servers abort immediately, depending on the value of the > client_version: > > for client_version = { 0x03,0x00 } (SSLv3) > for client_version = { 0x03,0x01 } (TLSv1.0) > for client_version = { 0x03,0x02 } (TLSv1.1) > for client_version = { 0x03,0x03 } (TLSv1.2) > > and how many continue the handshake but fail the finished macs? I am currently not registering data that detailed (although I do register results for each tested client_version value tested, the results are not that fine-grained), and IMO it does not really make that much a difference (to the client) if the server just shut down the connection, or failed the finished message; establishing the connection still failed. As mentioned earlier I do register servers that refuse to accept a SSL v3 record protocol for the Hello, but require a TLS 1.0 instead (the number of servers that require that, and are included in the above version intolerance count is 29, 0.005 percentage points) One case where we do (implictly) get a failure during the finished mac, is for the 0.117% of servers that mirror any version back, even if they do not support it. The number of servers that require the RSA client key exchange version field to be the same as the negotiated version, not sent version, is about 4.6% (April 2011; data not reliable since then :( ): about 27% ignore that version field. -- 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 mrex@sap.com Wed Sep 21 16:18:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313501F0D33 for ; Wed, 21 Sep 2011 16:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED7ri2yaCDXV for ; Wed, 21 Sep 2011 16:18:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8811F0D31 for ; Wed, 21 Sep 2011 16:18:08 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8LNKWx6007847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 01:20:33 +0200 (MEST) From: Martin Rex Message-Id: <201109212320.p8LNKWl5023077@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Thu, 22 Sep 2011 01:20:32 +0200 (MEST) In-Reply-To: from "Geoffrey Keating" at Sep 21, 11 03:54:35 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:18:17 -0000 Geoffrey Keating wrote: > > > > Does anyone (SSL Labs, Opera, others) have any figures/stats about the > > current "TLSv1.1 version (in)tolerance" for TLS servers on the public > > internet? > > I find that about 1.4% of servers will refuse to connect using a TLS 1.2 > hello but will connect using a TLS 1.0 hello. Some of those might be > unhappy about something else in the TLS 1.2 hello (extensions, for > example). The other 99% accept a TLS 1.2 hello, even though only a small > fraction (about 0.15%) actually supports TLS 1.1 or 1.2. > > > The TCP RST in the above situation, as described in Stevens' Network > > Programming, Section 7.5, Socket Option SO_LINGER, only indicates the > > specific SO_LINGER setting that the server had used for his side > > of the connection / his socket (Fig. 7.10 close() l_onoff=1, l_linger=0) > > > > The SO_LINGER setting for a socket is entirely at the discretion of each peer > > and closing the socket immediately after sending a fatal alert is exactly > > what the TLS spec suggests: > > > > http://tools.ietf.org/html/rfc2246#section-7.2.2 > > > > 7.2.2. Error alerts > > > > Error handling in the TLS Handshake protocol is very simple. When an > > error is detected, the detecting party sends a message to the other > > party. Upon transmission or receipt of an fatal alert message, both > > parties immediately close the connection. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^! > > RFC 793 says, in section 3.5, that a connection is closed by sending a > FIN. A RST is not a close of the connection but an abort; as RFC 793 > says, "Such a message indicates to the site B TCP that something is > wrong, and it is expected to abort the connection." Your on the wrong page, see RFC1122 Section 4.2.2.13. Sending RST on cluse, indicating loss of data (that includes future loss of data). When not lingering on close, the server closes and destroys the socket immediately, there will not be a graceful three way handshake and the server does not care whether the data is received by the recipient, not even whether the data is delivered by the network. > > However, the question of how to close the connection is secondary, > because it should not have been closed in the first place; as the blog > entry says, "The server isn't supposed to behave this way---it's > instead expected to simply reply using the latest HTTPS protocol > version it supports". You can't really expect software that's broken > in one way to work perfectly in all other ways... You're missing the point. The blog is describing a reconnect fallback implemented in WinINET, and writes that the fallback fails to work because the server behaves incorrectly. This is wrong, The server behaviour is perfectly fine, but the described reconnect fallback logic is flawed. -Martin From mrex@sap.com Wed Sep 21 16:48:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C029F21F8C15 for ; Wed, 21 Sep 2011 16:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwqIqaYZbomg for ; Wed, 21 Sep 2011 16:48:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E7A7721F8C16 for ; Wed, 21 Sep 2011 16:48:08 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8LNoaR9008763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 01:50:36 +0200 (MEST) From: Martin Rex Message-Id: <201109212350.p8LNoZUk024729@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 22 Sep 2011 01:50:35 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Sep 22, 11 01:19:38 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:48:09 -0000 Yngve N. Pettersen wrote: > > Martin Rex wrote: > > > > When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer), > > how many servers abort immediately, depending on the value of the > > client_version: > > > > for client_version = { 0x03,0x00 } (SSLv3) > > for client_version = { 0x03,0x01 } (TLSv1.0) > > for client_version = { 0x03,0x02 } (TLSv1.1) > > for client_version = { 0x03,0x03 } (TLSv1.2) > > > > and how many continue the handshake but fail the finished macs? > > I am currently not registering data that detailed (although I do register > results for each tested client_version value tested, the results are not > that fine-grained), and IMO it does not really make that much a difference > (to the client) if the server just shut down the connection, or failed the > finished message; establishing the connection still failed. Thank you very much for providing the information that have collected. It's not that I urgently need exactly that information. I'm mainly trying to figure out what is the most interoperable set of "features" for a ClientHello for a TLS client that is _not_ capable of reconnect fallback. > > The number of servers that require the RSA client key exchange version > field to be the same as the negotiated version, not sent version, is about > 4.6% (April 2011; data not reliable since then :( ): about 27% ignore that > version field. Thank you very much for reminding me of this problem. I had entirely forgotten about this, and that number (4.6%) is quite disappointing. Add to that the RSA client key exchange version bug that Microsoft has shipped with Windows 7 SChannel for the renegotiation handshake, where they check the premaster secret version against the proposed version of the initial handshake instead of the proposed version of the current handshake and you will get the bottom line that suggesting the use of TLS version 1.1 or 1.2 through ClientHello.client_version will result in a significant amount of interop problems. I really think we (the TLS WG) should provide a remedy to this awful situation for the TLS protocol version negotiation in the installed base. > > As mentioned earlier I do register servers that refuse to accept a SSL v3 > record protocol for the Hello, but require a TLS 1.0 instead (the number > of servers that require that, and are included in the above version > intolerance count is 29, 0.005 percentage points) OK. I personally don't see those as a problem because I consider SSLv3 and TLSv1.0 equivalent when used with any of the regular SSLv3 cipher suites plus rfc3268 AES. > > One case where we do (implictly) get a failure during the finished mac, is > for the 0.117% of servers that mirror any version back, even if they do > not support it. While being technically different, those will likely be covered by a fairly conservative strategy of exclusively using either SSLRecord.protocol = { 0x03,0x00 } ClientHello.client_version = { 0x03,0x01 } or SSLRecord.protocol = { 0x03,0x01 } ClientHello.client_version = { 0x03,0x01 } for a client without reconnect fallback. -Martin From geoffk@geoffk.org Wed Sep 21 17:07:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697411F0C56 for ; Wed, 21 Sep 2011 17:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE2uz9I1lxL6 for ; Wed, 21 Sep 2011 17:07:17 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31521F8D1D for ; Wed, 21 Sep 2011 17:07:17 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id DCC0033D145; Thu, 22 Sep 2011 00:09:42 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <201109212320.p8LNKWl5023077@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 21 Sep 2011 17:09:42 -0700 In-Reply-To: <201109212320.p8LNKWl5023077@fs4113.wdf.sap.corp> Message-ID: Lines: 23 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 00:07:17 -0000 Martin Rex writes: > Geoffrey Keating wrote: > > RFC 793 says, in section 3.5, that a connection is closed by sending a > > FIN. A RST is not a close of the connection but an abort; as RFC 793 > > says, "Such a message indicates to the site B TCP that something is > > wrong, and it is expected to abort the connection." > > Your on the wrong page, see RFC1122 Section 4.2.2.13. > Sending RST on cluse, indicating loss of data (that includes future > loss of data). > > When not lingering on close, the server closes and destroys the socket > immediately, there will not be a graceful three way handshake and the > server does not care whether the data is received by the recipient, > not even whether the data is delivered by the network. I think we're agreeing? For the purposes of TLS, you definitely don't want to do an abort by sending a RST, because it doesn't guarantee that the alert gets delivered to the endpoint---even if it gets physically sent, and it's not dropped in transit, the other end may discard it before delivering it to the TLS layer (flushing its buffers on receipt of a RST). From pgut001@login01.cs.auckland.ac.nz Thu Sep 22 03:23:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B72C21F8D1E for ; Thu, 22 Sep 2011 03:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJqZRsSA5k7g for ; Thu, 22 Sep 2011 03:23:18 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9379621F8D23 for ; Thu, 22 Sep 2011 03:23:17 -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=1316687150; x=1348223150; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20interop=20fo r=20TLS=20clients=20proposing=20TLSv1.1|Cc:=20tls@ietf.or g|In-Reply-To:=20<201109212048.p8LKmXnH014242@fs4113.wdf. sap.corp>|Message-Id:=20|Date:=20Thu,=2022=20Sep=202011=2022:25:44 =20+1200; bh=UrpmMeXo3LgjuXaXOsYrn7fYgBg0A8Klntk14+7xoj0=; b=hu8uau0af85CMO50QNVe+2EskmAeTDTDEUiN1zC8JQUlxygW+mnaObFI K/+COfsfLtATC4FXKv4BBBVZrKAwA9+/C+0z4GeyvH9w7wjuy6sb8OrZy EFZsLItnu9Y43NF3Z7dMI0mwSwBTtktdVR7o6D2gI4zG5kCrbm5JcRjR6 U=; X-IronPort-AV: E=Sophos;i="4.68,422,1312113600"; d="scan'208";a="85004660" 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; 22 Sep 2011 22:25:45 +1200 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 1R6gTQ-0008BS-IV; Thu, 22 Sep 2011 22:25:44 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1R6gTQ-0000IT-MW; Thu, 22 Sep 2011 22:25:44 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> Message-Id: Date: Thu, 22 Sep 2011 22:25:44 +1200 Cc: tls@ietf.org Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 10:23:20 -0000 Martin Rex writes: >Likewise, if my analsis is correct and that Blog accurately describes >WinINETs behaviour, that WinINET behaviour should be fixed to allow MSIE >users on Win7 to enable TLSv1.1 with less risk of interop problems. I've been told this is an artefact of schannel/wininet layering, that there's no way for schannel to communicate the necessary info to wininet, so it responds with a RST. There are other situations where it does this as well, not just protocol-version issues. There's apparently no easy way to fix this without considerable re-architecting. Peter. From gjserrao8@gmail.com Fri Sep 23 07:15:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6721F8CA9 for ; Fri, 23 Sep 2011 07:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBPDdsIEc6ok for ; Fri, 23 Sep 2011 07:15:08 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1EC121F8C80 for ; Fri, 23 Sep 2011 07:15:07 -0700 (PDT) Received: by gwj15 with SMTP id 15so3458115gwj.31 for ; Fri, 23 Sep 2011 07:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=qGVCbNf/yeTpx7yX5CUwg+iCvW1PR92C/6QDz3Et4iM=; b=kfge/v46FM3/5nu66ZFBvZsx2cSfKP+Rl1GC+qu2ezU08qdoNGczdthk+ubjPutinK 9YLSwjS/IhCz3eAvWBV27c0MOsNIr6IUSUe9jdo9VJ5vtnNt07LV5Ln62QHvlqMwrJN/ FJ+tjM/uZSaKFy7fTfn/M25qK0e1YPjENYo08= Received: by 10.150.52.11 with SMTP id z11mr2230296ybz.304.1316787460941; Fri, 23 Sep 2011 07:17:40 -0700 (PDT) Received: from localhost (54.sub-174-252-134.myvzw.com. [174.252.134.54]) by mx.google.com with ESMTPS id m4sm2686649ybc.5.2011.09.23.07.17.36 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 07:17:38 -0700 (PDT) Date: Fri, 23 Sep 2011 10:17:47 -0400 Message-ID: From: Gloria To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [TLS] TLS Digest, Vol 86, Issue 19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:15:09 -0000 CgpTZW50IGZyb20gbXkgVmVyaXpvbiBXaXJlbGVzcyBQaG9uZQoKdGxzLXJlcXVlc3RAaWV0Zi5v cmcgd3JvdGU6Cgo+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwg dGhlIGluZGl2aWR1YWwgbWVzc2FnZQo+YXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRh dGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxpc3QKPnN1YnNjcmlwdGlvbi4gIFRvIGRv IHNvLCBnbyB0byAKPgo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMK Pgo+Q2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGlu LCBhbmQgc2V0ICJHZXQKPk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlv dSBjYW4gc2V0IHRoaXMgb3B0aW9uCj5nbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMg eW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4KPgo+Cj4KPlNlbmQgVExTIG1haWxpbmcgbGlzdCBz dWJtaXNzaW9ucyB0bwo+CXRsc0BpZXRmLm9yZwo+Cj5UbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3Jp YmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQKPglodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscwo+b3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBz dWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvCj4JdGxzLXJlcXVlc3RAaWV0Zi5vcmcKPgo+WW91IGNh biByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0Cj4JdGxzLW93bmVyQGlldGYu b3JnCj4KPldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0 IGlzIG1vcmUgc3BlY2lmaWMKPnRoYW4gIlJlOiBDb250ZW50cyBvZiBUTFMgZGlnZXN0Li4uIgo+ Cj4KPlRvZGF5J3MgVG9waWNzOgo+Cj4gICAxLiBSZTogIGludGVyb3AgZm9yIFRMUyBjbGllbnRz IHByb3Bvc2luZyBUTFN2MS4xCj4gICAgICAoWW5ndmUgTi4gUGV0dGVyc2VuIChEZXZlbG9wZXIg T3BlcmEgU29mdHdhcmUgQVNBKSkKPiAgIDIuIFJlOiAgaW50ZXJvcCBmb3IgVExTIGNsaWVudHMg cHJvcG9zaW5nIFRMU3YxLjEgKE1hcnRpbiBSZXgpCj4gICAzLiBSZTogIGludGVyb3AgZm9yIFRM UyBjbGllbnRzIHByb3Bvc2luZyBUTFN2MS4xIChNYXJ0aW4gUmV4KQo+ICAgNC4gUmU6ICBpbnRl cm9wIGZvciBUTFMgY2xpZW50cyBwcm9wb3NpbmcgVExTdjEuMSAoR2VvZmZyZXkgS2VhdGluZykK PiAgIDUuIFJlOiAgaW50ZXJvcCBmb3IgVExTIGNsaWVudHMgcHJvcG9zaW5nIFRMU3YxLjEgKFBl dGVyIEd1dG1hbm4pCj4KPgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAxCj5EYXRlOiBUaHUs IDIyIFNlcCAyMDExIDAxOjE5OjM4ICswMjAwCj5Gcm9tOiAiWW5ndmUgTi4gUGV0dGVyc2VuIChE ZXZlbG9wZXIgT3BlcmEgU29mdHdhcmUgQVNBKSIKPgk8eW5ndmVAb3BlcmEuY29tPgo+VG86ICJN YXJ0aW4gUmV4IiA8bXJleEBzYXAuY29tPgo+Q2M6IHRsc0BpZXRmLm9yZwo+U3ViamVjdDogUmU6 IFtUTFNdIGludGVyb3AgZm9yIFRMUyBjbGllbnRzIHByb3Bvc2luZyBUTFN2MS4xCj5NZXNzYWdl LUlEOiA8b3AudjE2bHEwc2FxcnE3dHBAYWNvcm5hLm9zbG8ub3NhPgo+Q29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PWlzby04ODU5LTE1OyBmb3JtYXQ9Zmxvd2VkOwo+CWRlbHNwPXll cwo+Cj5PbiBUaHUsIDIyIFNlcCAyMDExIDAwOjMwOjQ4ICswMjAwLCBNYXJ0aW4gUmV4IDxtcmV4 QHNhcC5jb20+IHdyb3RlOgo+Cj4+IFluZ3ZlIE4uIFBldHRlcnNlbiB3cm90ZToKPj4+Cj4+PiBP biBXZWQsIDIxIFNlcCAyMDExIDIyOjQ4OjMzICswMjAwLCBNYXJ0aW4gUmV4IDxtcmV4QHNhcC5j b20+IHdyb3RlOgo+Pj4KPj4+ID4gRG9lcyBhbnlvbmUgKFNTTCBMYWJzLCBPcGVyYSwgb3RoZXJz KSBoYXZlIGFueSBmaWd1cmVzL3N0YXRzIGFib3V0IHRoZQo+Pj4gPiBjdXJyZW50ICJUTFN2MS4x IHZlcnNpb24gKGluKXRvbGVyYW5jZSIgZm9yIFRMUyBzZXJ2ZXJzIG9uIHRoZSBwdWJsaWMKPj4+ ID4gaW50ZXJuZXQ/Cj4+Pgo+Pj4gVGhpcyB3ZWVrJ3MgdGVzdCBvZiA2MDk3MjYgc2VydmVycyBn YXZlIHRoZXNlIG51bWJlcnM6Cj4+Pgo+Pj4gICAgKiAxLjE0NSUgb2YgdGhlIHByb2JlZCBzZXJ2 ZXJzIHdlcmUgdmVyc2lvbiBpbnRvbGVyYW50IGZvciBhdCBsZWFzdCAgCj4+PiBvbmUKPj4+ICAg ICAgb2YgdGhlIGN1cnJlbnQgVExTIHZlcnNpb25zICgxLjAsIDEuMSwgMS4yKQo+Pj4gICAgKiAx Ljc0MiUgd2VyZSBleHRlbnNpb24gaW50b2xlcmFudCBmb3IgdGhlIHNhbWUgdmVyc2lvbnMKPj4+ ICAgICogMS4xMzYlIGJlbG9uZ2VkIGluIGJvdGggZ3JvdXBzCj4+Pgo+Pj4gVGhpcyBnaXZlcyBh biBlc3RpbWF0ZWQgdG90YWwgb2YgMS43NTElIHRoYXQgYXJlIGVpdGhlciB2ZXJzaW9uIGFuZC9v cgo+Pj4gZXh0ZW5zaW9uIGludG9sZXJhbnQgZm9yIHRoZSBjdXJyZW50bHkgZGVmaW5lZCBUTFMg dmVyc2lvbnMuCj4+Cj4+IE9LLCBJJ2xsIHRyeSB0byBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHRo ZSBudW1iZXJzIHRoYXQKPj4gKkkqIHdvdWxkIGJlIGludGVyZXN0IGluIChpbiBjYXNlIHlvdSBj b3VsZCBleHRyYWN0IGZyb20geW91ciBkYXRhKToKPj4KPj4gV2hlbiBzZW5kaW5nIGFuIFNTTHYz IENsaWVudEhlbGxvIChpLmUuIHsweDAzLDB4MDB9IGF0IHRoZSByZWNvcmQgbGF5ZXIpLAo+PiBo b3cgbWFueSBzZXJ2ZXJzIGFib3J0IGltbWVkaWF0ZWx5LCBkZXBlbmRpbmcgb24gdGhlIHZhbHVl IG9mIHRoZQo+PiBjbGllbnRfdmVyc2lvbjoKPj4KPj4gICAgIGZvciBjbGllbnRfdmVyc2lvbiA9 IHsgMHgwMywweDAwIH0gICAoU1NMdjMpCj4+ICAgICBmb3IgY2xpZW50X3ZlcnNpb24gPSB7IDB4 MDMsMHgwMSB9ICAgKFRMU3YxLjApCj4+ICAgICBmb3IgY2xpZW50X3ZlcnNpb24gPSB7IDB4MDMs MHgwMiB9ICAgKFRMU3YxLjEpCj4+ICAgICBmb3IgY2xpZW50X3ZlcnNpb24gPSB7IDB4MDMsMHgw MyB9ICAgKFRMU3YxLjIpCj4+Cj4+IGFuZCBob3cgbWFueSBjb250aW51ZSB0aGUgaGFuZHNoYWtl IGJ1dCBmYWlsIHRoZSBmaW5pc2hlZCBtYWNzPwo+Cj5JIGFtIGN1cnJlbnRseSBub3QgcmVnaXN0 ZXJpbmcgZGF0YSB0aGF0IGRldGFpbGVkIChhbHRob3VnaCBJIGRvIHJlZ2lzdGVyICAKPnJlc3Vs dHMgZm9yIGVhY2ggdGVzdGVkIGNsaWVudF92ZXJzaW9uIHZhbHVlIHRlc3RlZCwgdGhlIHJlc3Vs dHMgYXJlIG5vdCAgCj50aGF0IGZpbmUtZ3JhaW5lZCksIGFuZCBJTU8gaXQgZG9lcyBub3QgcmVh bGx5IG1ha2UgdGhhdCBtdWNoIGEgZGlmZmVyZW5jZSAgCj4odG8gdGhlIGNsaWVudCkgaWYgdGhl IHNlcnZlciBqdXN0IHNodXQgZG93biB0aGUgY29ubmVjdGlvbiwgb3IgZmFpbGVkIHRoZSAgCj5m aW5pc2hlZCBtZXNzYWdlOyBlc3RhYmxpc2hpbmcgdGhlIGNvbm5lY3Rpb24gc3RpbGwgZmFpbGVk Lgo+Cj5BcyBtZW50aW9uZWQgZWFybGllciBJIGRvIHJlZ2lzdGVyIHNlcnZlcnMgdGhhdCByZWZ1 c2UgdG8gYWNjZXB0IGEgU1NMIHYzICAKPnJlY29yZCBwcm90b2NvbCBmb3IgdGhlIEhlbGxvLCBi dXQgcmVxdWlyZSBhIFRMUyAxLjAgaW5zdGVhZCAodGhlIG51bWJlciAgCj5vZiBzZXJ2ZXJzIHRo YXQgcmVxdWlyZSB0aGF0LCBhbmQgYXJlIGluY2x1ZGVkIGluIHRoZSBhYm92ZSB2ZXJzaW9uICAK PmludG9sZXJhbmNlIGNvdW50IGlzIDI5LCAwLjAwNSBwZXJjZW50YWdlIHBvaW50cykKPgo+T25l IGNhc2Ugd2hlcmUgd2UgZG8gKGltcGxpY3RseSkgZ2V0IGEgZmFpbHVyZSBkdXJpbmcgdGhlIGZp bmlzaGVkIG1hYywgaXMgIAo+Zm9yIHRoZSAwLjExNyUgb2Ygc2VydmVycyB0aGF0IG1pcnJvciBh bnkgdmVyc2lvbiBiYWNrLCBldmVuIGlmIHRoZXkgZG8gIAo+bm90IHN1cHBvcnQgaXQuCj4KPlRo ZSBudW1iZXIgb2Ygc2VydmVycyB0aGF0IHJlcXVpcmUgdGhlIFJTQSBjbGllbnQga2V5IGV4Y2hh bmdlIHZlcnNpb24gIAo+ZmllbGQgdG8gYmUgdGhlIHNhbWUgYXMgdGhlIG5lZ290aWF0ZWQgdmVy c2lvbiwgbm90IHNlbnQgdmVyc2lvbiwgaXMgYWJvdXQgIAo+NC42JSAoQXByaWwgMjAxMTsgZGF0 YSBub3QgcmVsaWFibGUgc2luY2UgdGhlbiA6KCApOiBhYm91dCAyNyUgaWdub3JlIHRoYXQgIAo+ dmVyc2lvbiBmaWVsZC4KPgo+LS0gCj5TaW5jZXJlbHksCj5Zbmd2ZSBOLiBQZXR0ZXJzZW4KPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqCj5TZW5pb3IgRGV2ZWxvcGVyCQkgICAgIEVtYWlsOiB5bmd2ZUBvcGVyYS5jb20K Pk9wZXJhIFNvZnR3YXJlIEFTQSAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3Lm9wZXJhLmNv bS8KPlBob25lOiAgKzQ3IDIzIDY5IDMyIDYwICAgICAgICAgICAgICBGYXg6ICAgICs0NyAyMyA2 OSAyNCAwMQo+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioKPgo+Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Pgo+TWVzc2FnZTogMgo+RGF0ZTogVGh1LCAyMiBTZXAgMjAxMSAwMToyMDozMiArMDIwMCAoTUVT VCkKPkZyb206IE1hcnRpbiBSZXggPG1yZXhAc2FwLmNvbT4KPlRvOiBnZW9mZmtAZ2VvZmZrLm9y ZyAoR2VvZmZyZXkgS2VhdGluZykKPkNjOiB0bHNAaWV0Zi5vcmcKPlN1YmplY3Q6IFJlOiBbVExT XSBpbnRlcm9wIGZvciBUTFMgY2xpZW50cyBwcm9wb3NpbmcgVExTdjEuMQo+TWVzc2FnZS1JRDog PDIwMTEwOTIxMjMyMC5wOExOS1dsNTAyMzA3N0BmczQxMTMud2RmLnNhcC5jb3JwPgo+Q29udGVu dC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PUlTTy04ODU5LTEKPgo+R2VvZmZyZXkgS2VhdGlu ZyB3cm90ZToKPj4gCj4+IAo+PiA+IERvZXMgYW55b25lIChTU0wgTGFicywgT3BlcmEsIG90aGVy cykgaGF2ZSBhbnkgZmlndXJlcy9zdGF0cyBhYm91dCB0aGUKPj4gPiBjdXJyZW50ICJUTFN2MS4x IHZlcnNpb24gKGluKXRvbGVyYW5jZSIgZm9yIFRMUyBzZXJ2ZXJzIG9uIHRoZSBwdWJsaWMKPj4g PiBpbnRlcm5ldD8KPj4gCj4+IEkgZmluZCB0aGF0IGFib3V0IDEuNCUgb2Ygc2VydmVycyB3aWxs IHJlZnVzZSB0byBjb25uZWN0IHVzaW5nIGEgVExTIDEuMgo+PiBoZWxsbyBidXQgd2lsbCBjb25u ZWN0IHVzaW5nIGEgVExTIDEuMCBoZWxsby4gIFNvbWUgb2YgdGhvc2UgbWlnaHQgYmUKPj4gdW5o YXBweSBhYm91dCBzb21ldGhpbmcgZWxzZSBpbiB0aGUgVExTIDEuMiBoZWxsbyAoZXh0ZW5zaW9u cywgZm9yCj4+IGV4YW1wbGUpLiAgVGhlIG90aGVyIDk5JSBhY2NlcHQgYSBUTFMgMS4yIGhlbGxv LCBldmVuIHRob3VnaCBvbmx5IGEgc21hbGwKPj4gZnJhY3Rpb24gKGFib3V0IDAuMTUlKSBhY3R1 YWxseSBzdXBwb3J0cyBUTFMgMS4xIG9yIDEuMi4KPj4gCj4+ID4gVGhlIFRDUCBSU1QgaW4gdGhl IGFib3ZlIHNpdHVhdGlvbiwgYXMgZGVzY3JpYmVkIGluIFN0ZXZlbnMnIE5ldHdvcmsKPj4gPiBQ cm9ncmFtbWluZywgU2VjdGlvbiA3LjUsIFNvY2tldCBPcHRpb24gU09fTElOR0VSLCBvbmx5IGlu ZGljYXRlcyB0aGUKPj4gPiBzcGVjaWZpYyBTT19MSU5HRVIgc2V0dGluZyB0aGF0IHRoZSBzZXJ2 ZXIgaGFkIHVzZWQgZm9yIGhpcyBzaWRlCj4+ID4gb2YgdGhlIGNvbm5lY3Rpb24gLyBoaXMgc29j a2V0IChGaWcuIDcuMTAgIGNsb3NlKCkgbF9vbm9mZj0xLCBsX2xpbmdlcj0wKQo+PiA+IAo+PiA+ IFRoZSBTT19MSU5HRVIgc2V0dGluZyBmb3IgYSBzb2NrZXQgaXMgZW50aXJlbHkgYXQgdGhlIGRp c2NyZXRpb24gb2YgZWFjaCBwZWVyCj4+ID4gYW5kIGNsb3NpbmcgdGhlIHNvY2tldCBpbW1lZGlh dGVseSBhZnRlciBzZW5kaW5nIGEgZmF0YWwgYWxlcnQgaXMgZXhhY3RseQo+PiA+IHdoYXQgdGhl IFRMUyBzcGVjIHN1Z2dlc3RzOgo+PiA+IAo+PiA+ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzIyNDYjc2VjdGlvbi03LjIuMgo+PiA+IAo+PiA+ICAgIDcuMi4yLiBFcnJvciBhbGVy dHMKPj4gPiAKPj4gPiAgICBFcnJvciBoYW5kbGluZyBpbiB0aGUgVExTIEhhbmRzaGFrZSBwcm90 b2NvbCBpcyB2ZXJ5IHNpbXBsZS4gV2hlbiBhbgo+PiA+ICAgIGVycm9yIGlzIGRldGVjdGVkLCB0 aGUgZGV0ZWN0aW5nIHBhcnR5IHNlbmRzIGEgbWVzc2FnZSB0byB0aGUgb3RoZXIKPj4gPiAgICBw YXJ0eS4gVXBvbiB0cmFuc21pc3Npb24gb3IgcmVjZWlwdCBvZiBhbiBmYXRhbCBhbGVydCBtZXNz YWdlLCBib3RoCj4+ID4gICAgcGFydGllcyBpbW1lZGlhdGVseSBjbG9zZSB0aGUgY29ubmVjdGlv bi4gCj4+ID4gCj4+ID4gICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e XiEKPj4gCj4+IFJGQyA3OTMgc2F5cywgaW4gc2VjdGlvbiAzLjUsIHRoYXQgYSBjb25uZWN0aW9u IGlzIGNsb3NlZCBieSBzZW5kaW5nIGEKPj4gRklOLiAgQSBSU1QgaXMgbm90IGEgY2xvc2Ugb2Yg dGhlIGNvbm5lY3Rpb24gYnV0IGFuIGFib3J0OyBhcyBSRkMgNzkzCj4+IHNheXMsICJTdWNoIGEg bWVzc2FnZSBpbmRpY2F0ZXMgdG8gdGhlIHNpdGUgQiBUQ1AgdGhhdCBzb21ldGhpbmcgaXMKPj4g d3JvbmcsIGFuZCBpdCBpcyBleHBlY3RlZCB0byBhYm9ydCB0aGUgY29ubmVjdGlvbi4iCj4KPllv dXIgb24gdGhlIHdyb25nIHBhZ2UsIHNlZSBSRkMxMTIyIFNlY3Rpb24gNC4yLjIuMTMuCj5TZW5k aW5nIFJTVCBvbiBjbHVzZSwgaW5kaWNhdGluZyBsb3NzIG9mIGRhdGEgKHRoYXQgaW5jbHVkZXMg ZnV0dXJlCj5sb3NzIG9mIGRhdGEpLgo+Cj5XaGVuIG5vdCBsaW5nZXJpbmcgb24gY2xvc2UsIHRo ZSBzZXJ2ZXIgY2xvc2VzIGFuZCBkZXN0cm95cyB0aGUgc29ja2V0Cj5pbW1lZGlhdGVseSwgdGhl cmUgd2lsbCBub3QgYmUgYSBncmFjZWZ1bCB0aHJlZSB3YXkgaGFuZHNoYWtlIGFuZCB0aGUKPnNl cnZlciBkb2VzIG5vdCBjYXJlIHdoZXRoZXIgdGhlIGRhdGEgaXMgcmVjZWl2ZWQgYnkgdGhlIHJl Y2lwaWVudCwKPm5vdCBldmVuIHdoZXRoZXIgdGhlIGRhdGEgaXMgZGVsaXZlcmVkIGJ5IHRoZSBu ZXR3b3JrLgo+Cj4KPj4gCj4+IEhvd2V2ZXIsIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8gY2xvc2Ug dGhlIGNvbm5lY3Rpb24gaXMgc2Vjb25kYXJ5LAo+PiBiZWNhdXNlIGl0IHNob3VsZCBub3QgaGF2 ZSBiZWVuIGNsb3NlZCBpbiB0aGUgZmlyc3QgcGxhY2U7IGFzIHRoZSBibG9nCj4+IGVudHJ5IHNh eXMsICJUaGUgc2VydmVyIGlzbid0IHN1cHBvc2VkIHRvIGJlaGF2ZSB0aGlzIHdheS0tLWl0J3MK Pj4gaW5zdGVhZCBleHBlY3RlZCB0byBzaW1wbHkgcmVwbHkgdXNpbmcgdGhlIGxhdGVzdCBIVFRQ UyBwcm90b2NvbAo+PiB2ZXJzaW9uIGl0IHN1cHBvcnRzIi4gIFlvdSBjYW4ndCByZWFsbHkgZXhw ZWN0IHNvZnR3YXJlIHRoYXQncyBicm9rZW4KPj4gaW4gb25lIHdheSB0byB3b3JrIHBlcmZlY3Rs eSBpbiBhbGwgb3RoZXIgd2F5cy4uLgo+IAo+Cj5Zb3UncmUgbWlzc2luZyB0aGUgcG9pbnQuICBU aGUgYmxvZyBpcyBkZXNjcmliaW5nIGEgcmVjb25uZWN0IGZhbGxiYWNrCj5pbXBsZW1lbnRlZCBp biBXaW5JTkVULCBhbmQgd3JpdGVzIHRoYXQgdGhlIGZhbGxiYWNrIGZhaWxzIHRvIHdvcmsKPmJl Y2F1c2UgdGhlIHNlcnZlciBiZWhhdmVzIGluY29ycmVjdGx5LiAgVGhpcyBpcyB3cm9uZywgIFRo ZSBzZXJ2ZXIKPmJlaGF2aW91ciBpcyBwZXJmZWN0bHkgZmluZSwgYnV0IHRoZSBkZXNjcmliZWQg cmVjb25uZWN0IGZhbGxiYWNrCj5sb2dpYyBpcyBmbGF3ZWQuCj4KPgo+LU1hcnRpbgo+Cj4KPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAzCj5EYXRlOiBUaHUsIDIy IFNlcCAyMDExIDAxOjUwOjM1ICswMjAwIChNRVNUKQo+RnJvbTogTWFydGluIFJleCA8bXJleEBz YXAuY29tPgo+VG86IHluZ3ZlQG9wZXJhLmNvbSAoWW5ndmUgTi4gUGV0dGVyc2VuKQo+Q2M6IHRs c0BpZXRmLm9yZwo+U3ViamVjdDogUmU6IFtUTFNdIGludGVyb3AgZm9yIFRMUyBjbGllbnRzIHBy b3Bvc2luZyBUTFN2MS4xCj5NZXNzYWdlLUlEOiA8MjAxMTA5MjEyMzUwLnA4TE5vWlVrMDI0NzI5 QGZzNDExMy53ZGYuc2FwLmNvcnA+Cj5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9 SVNPLTg4NTktMQo+Cj5Zbmd2ZSBOLiBQZXR0ZXJzZW4gd3JvdGU6Cj4+IAo+PiBNYXJ0aW4gUmV4 IHdyb3RlOgo+PiA+IAo+PiA+IFdoZW4gc2VuZGluZyBhbiBTU0x2MyBDbGllbnRIZWxsbyAoaS5l LiB7MHgwMywweDAwfSBhdCB0aGUgcmVjb3JkIGxheWVyKSwKPj4gPiBob3cgbWFueSBzZXJ2ZXJz IGFib3J0IGltbWVkaWF0ZWx5LCBkZXBlbmRpbmcgb24gdGhlIHZhbHVlIG9mIHRoZQo+PiA+IGNs aWVudF92ZXJzaW9uOgo+PiA+Cj4+ID4gICAgIGZvciBjbGllbnRfdmVyc2lvbiA9IHsgMHgwMyww eDAwIH0gICAoU1NMdjMpCj4+ID4gICAgIGZvciBjbGllbnRfdmVyc2lvbiA9IHsgMHgwMywweDAx IH0gICAoVExTdjEuMCkKPj4gPiAgICAgZm9yIGNsaWVudF92ZXJzaW9uID0geyAweDAzLDB4MDIg fSAgIChUTFN2MS4xKQo+PiA+ICAgICBmb3IgY2xpZW50X3ZlcnNpb24gPSB7IDB4MDMsMHgwMyB9 ICAgKFRMU3YxLjIpCj4+ID4KPj4gPiBhbmQgaG93IG1hbnkgY29udGludWUgdGhlIGhhbmRzaGFr ZSBidXQgZmFpbCB0aGUgZmluaXNoZWQgbWFjcz8KPj4gCj4+IEkgYW0gY3VycmVudGx5IG5vdCBy ZWdpc3RlcmluZyBkYXRhIHRoYXQgZGV0YWlsZWQgKGFsdGhvdWdoIEkgZG8gcmVnaXN0ZXIgIAo+ PiByZXN1bHRzIGZvciBlYWNoIHRlc3RlZCBjbGllbnRfdmVyc2lvbiB2YWx1ZSB0ZXN0ZWQsIHRo ZSByZXN1bHRzIGFyZSBub3QgIAo+PiB0aGF0IGZpbmUtZ3JhaW5lZCksIGFuZCBJTU8gaXQgZG9l cyBub3QgcmVhbGx5IG1ha2UgdGhhdCBtdWNoIGEgZGlmZmVyZW5jZSAgCj4+ICh0byB0aGUgY2xp ZW50KSBpZiB0aGUgc2VydmVyIGp1c3Qgc2h1dCBkb3duIHRoZSBjb25uZWN0aW9uLCBvciBmYWls ZWQgdGhlICAKPj4gZmluaXNoZWQgbWVzc2FnZTsgZXN0YWJsaXNoaW5nIHRoZSBjb25uZWN0aW9u IHN0aWxsIGZhaWxlZC4KPgo+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgcHJvdmlkaW5nIHRoZSBp bmZvcm1hdGlvbiB0aGF0IGhhdmUgY29sbGVjdGVkLgo+SXQncyBub3QgdGhhdCBJIHVyZ2VudGx5 IG5lZWQgZXhhY3RseSB0aGF0IGluZm9ybWF0aW9uLiAgSSdtIG1haW5seQo+dHJ5aW5nIHRvIGZp Z3VyZSBvdXQgd2hhdCBpcyB0aGUgbW9zdCBpbnRlcm9wZXJhYmxlIHNldCBvZiAiZmVhdHVyZXMi IGZvcgo+YSBDbGllbnRIZWxsbyBmb3IgYSBUTFMgY2xpZW50IHRoYXQgaXMgX25vdF8gY2FwYWJs ZSBvZiByZWNvbm5lY3QgZmFsbGJhY2suCj4KPj4gCj4+IFRoZSBudW1iZXIgb2Ygc2VydmVycyB0 aGF0IHJlcXVpcmUgdGhlIFJTQSBjbGllbnQga2V5IGV4Y2hhbmdlIHZlcnNpb24gIAo+PiBmaWVs ZCB0byBiZSB0aGUgc2FtZSBhcyB0aGUgbmVnb3RpYXRlZCB2ZXJzaW9uLCBub3Qgc2VudCB2ZXJz aW9uLCBpcyBhYm91dCAgCj4+IDQuNiUgKEFwcmlsIDIwMTE7IGRhdGEgbm90IHJlbGlhYmxlIHNp bmNlIHRoZW4gOiggKTogYWJvdXQgMjclIGlnbm9yZSB0aGF0ICAKPj4gdmVyc2lvbiBmaWVsZC4K Pgo+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgcmVtaW5kaW5nIG1lIG9mIHRoaXMgcHJvYmxlbS4g IEkgaGFkIGVudGlyZWx5Cj5mb3Jnb3R0ZW4gYWJvdXQgdGhpcywgYW5kIHRoYXQgbnVtYmVyICg0 LjYlKSBpcyBxdWl0ZSBkaXNhcHBvaW50aW5nLgo+Cj5BZGQgdG8gdGhhdCB0aGUgUlNBIGNsaWVu dCBrZXkgZXhjaGFuZ2UgdmVyc2lvbiBidWcgdGhhdCBNaWNyb3NvZnQKPmhhcyBzaGlwcGVkIHdp dGggV2luZG93cyA3IFNDaGFubmVsIGZvciB0aGUgcmVuZWdvdGlhdGlvbiBoYW5kc2hha2UsCj53 aGVyZSB0aGV5IGNoZWNrIHRoZSBwcmVtYXN0ZXIgc2VjcmV0IHZlcnNpb24gYWdhaW5zdCB0aGUg cHJvcG9zZWQKPnZlcnNpb24gb2YgdGhlIGluaXRpYWwgaGFuZHNoYWtlIGluc3RlYWQgb2YgdGhl IHByb3Bvc2VkIHZlcnNpb24KPm9mIHRoZSBjdXJyZW50IGhhbmRzaGFrZSBhbmQgeW91IHdpbGwg Z2V0IHRoZSBib3R0b20gbGluZSB0aGF0Cj5zdWdnZXN0aW5nIHRoZSB1c2Ugb2YgVExTIHZlcnNp b24gMS4xIG9yIDEuMiB0aHJvdWdoCj5DbGllbnRIZWxsby5jbGllbnRfdmVyc2lvbiB3aWxsIHJl c3VsdCBpbiBhIHNpZ25pZmljYW50IGFtb3VudAo+b2YgaW50ZXJvcCBwcm9ibGVtcy4KPgo+SSBy ZWFsbHkgdGhpbmsgd2UgKHRoZSBUTFMgV0cpIHNob3VsZCBwcm92aWRlIGEgcmVtZWR5IHRvIHRo aXMgYXdmdWwKPnNpdHVhdGlvbiBmb3IgdGhlIFRMUyBwcm90b2NvbCB2ZXJzaW9uIG5lZ290aWF0 aW9uIGluIHRoZSBpbnN0YWxsZWQgYmFzZS4KPgo+Cj4+IAo+PiBBcyBtZW50aW9uZWQgZWFybGll ciBJIGRvIHJlZ2lzdGVyIHNlcnZlcnMgdGhhdCByZWZ1c2UgdG8gYWNjZXB0IGEgU1NMIHYzICAK Pj4gcmVjb3JkIHByb3RvY29sIGZvciB0aGUgSGVsbG8sIGJ1dCByZXF1aXJlIGEgVExTIDEuMCBp bnN0ZWFkICh0aGUgbnVtYmVyICAKPj4gb2Ygc2VydmVycyB0aGF0IHJlcXVpcmUgdGhhdCwgYW5k IGFyZSBpbmNsdWRlZCBpbiB0aGUgYWJvdmUgdmVyc2lvbiAgCj4+IGludG9sZXJhbmNlIGNvdW50 IGlzIDI5LCAwLjAwNSBwZXJjZW50YWdlIHBvaW50cykKPgo+T0suICBJIHBlcnNvbmFsbHkgZG9u J3Qgc2VlIHRob3NlIGFzIGEgcHJvYmxlbSBiZWNhdXNlIEkgY29uc2lkZXIKPlNTTHYzIGFuZCBU TFN2MS4wIGVxdWl2YWxlbnQgd2hlbiB1c2VkIHdpdGggYW55IG9mIHRoZSByZWd1bGFyCj5TU0x2 MyBjaXBoZXIgc3VpdGVzIHBsdXMgcmZjMzI2OCBBRVMuCj4gCj4+IAo+PiBPbmUgY2FzZSB3aGVy ZSB3ZSBkbyAoaW1wbGljdGx5KSBnZXQgYSBmYWlsdXJlIGR1cmluZyB0aGUgZmluaXNoZWQgbWFj LCBpcyAgCj4+IGZvciB0aGUgMC4xMTclIG9mIHNlcnZlcnMgdGhhdCBtaXJyb3IgYW55IHZlcnNp b24gYmFjaywgZXZlbiBpZiB0aGV5IGRvICAKPj4gbm90IHN1cHBvcnQgaXQuCj4KPldoaWxlIGJl aW5nIHRlY2huaWNhbGx5IGRpZmZlcmVudCwgdGhvc2Ugd2lsbCBsaWtlbHkgYmUgY292ZXJlZCBi eQo+YSBmYWlybHkgY29uc2VydmF0aXZlIHN0cmF0ZWd5IG9mIGV4Y2x1c2l2ZWx5IHVzaW5nIGVp dGhlcgo+Cj4gICBTU0xSZWNvcmQucHJvdG9jb2wgICAgICAgICA9IHsgMHgwMywweDAwIH0gCj4g ICBDbGllbnRIZWxsby5jbGllbnRfdmVyc2lvbiA9IHsgMHgwMywweDAxIH0KPgo+b3IKPgo+ICAg U1NMUmVjb3JkLnByb3RvY29sICAgICAgICAgPSB7IDB4MDMsMHgwMSB9IAo+ICAgQ2xpZW50SGVs bG8uY2xpZW50X3ZlcnNpb24gPSB7IDB4MDMsMHgwMSB9Cj4KPmZvciBhIGNsaWVudCB3aXRob3V0 IHJlY29ubmVjdCBmYWxsYmFjay4KPgo+LU1hcnRpbgo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiA0Cj5EYXRlOiAyMSBTZXAgMjAxMSAxNzowOTo0MiAtMDcw MAo+RnJvbTogR2VvZmZyZXkgS2VhdGluZyA8Z2VvZmZrQGdlb2Zmay5vcmc+Cj5UbzogbXJleEBz YXAuY29tCj5DYzogdGxzQGlldGYub3JnCj5TdWJqZWN0OiBSZTogW1RMU10gaW50ZXJvcCBmb3Ig VExTIGNsaWVudHMgcHJvcG9zaW5nIFRMU3YxLjEKPk1lc3NhZ2UtSUQ6IDxtMjM5ZnBlOHUxLmZz ZkBsb2NhbGhvc3QubG9jYWxkb21haW4+Cj5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJz ZXQ9dXMtYXNjaWkKPgo+TWFydGluIFJleCA8bXJleEBzYXAuY29tPiB3cml0ZXM6Cj4KPj4gR2Vv ZmZyZXkgS2VhdGluZyB3cm90ZToKPj4gPiBSRkMgNzkzIHNheXMsIGluIHNlY3Rpb24gMy41LCB0 aGF0IGEgY29ubmVjdGlvbiBpcyBjbG9zZWQgYnkgc2VuZGluZyBhCj4+ID4gRklOLiAgQSBSU1Qg aXMgbm90IGEgY2xvc2Ugb2YgdGhlIGNvbm5lY3Rpb24gYnV0IGFuIGFib3J0OyBhcyBSRkMgNzkz Cj4+ID4gc2F5cywgIlN1Y2ggYSBtZXNzYWdlIGluZGljYXRlcyB0byB0aGUgc2l0ZSBCIFRDUCB0 aGF0IHNvbWV0aGluZyBpcwo+PiA+IHdyb25nLCBhbmQgaXQgaXMgZXhwZWN0ZWQgdG8gYWJvcnQg dGhlIGNvbm5lY3Rpb24uIgo+PiAKPj4gWW91ciBvbiB0aGUgd3JvbmcgcGFnZSwgc2VlIFJGQzEx MjIgU2VjdGlvbiA0LjIuMi4xMy4KPj4gU2VuZGluZyBSU1Qgb24gY2x1c2UsIGluZGljYXRpbmcg bG9zcyBvZiBkYXRhICh0aGF0IGluY2x1ZGVzIGZ1dHVyZQo+PiBsb3NzIG9mIGRhdGEpLgo+PiAK Pj4gV2hlbiBub3QgbGluZ2VyaW5nIG9uIGNsb3NlLCB0aGUgc2VydmVyIGNsb3NlcyBhbmQgZGVz dHJveXMgdGhlIHNvY2tldAo+PiBpbW1lZGlhdGVseSwgdGhlcmUgd2lsbCBub3QgYmUgYSBncmFj ZWZ1bCB0aHJlZSB3YXkgaGFuZHNoYWtlIGFuZCB0aGUKPj4gc2VydmVyIGRvZXMgbm90IGNhcmUg d2hldGhlciB0aGUgZGF0YSBpcyByZWNlaXZlZCBieSB0aGUgcmVjaXBpZW50LAo+PiBub3QgZXZl biB3aGV0aGVyIHRoZSBkYXRhIGlzIGRlbGl2ZXJlZCBieSB0aGUgbmV0d29yay4KPgo+SSB0aGlu ayB3ZSdyZSBhZ3JlZWluZz8gIEZvciB0aGUgcHVycG9zZXMgb2YgVExTLCB5b3UgZGVmaW5pdGVs eSBkb24ndAo+d2FudCB0byBkbyBhbiBhYm9ydCBieSBzZW5kaW5nIGEgUlNULCBiZWNhdXNlIGl0 IGRvZXNuJ3QgZ3VhcmFudGVlCj50aGF0IHRoZSBhbGVydCBnZXRzIGRlbGl2ZXJlZCB0byB0aGUg ZW5kcG9pbnQtLS1ldmVuIGlmIGl0IGdldHMKPnBoeXNpY2FsbHkgc2VudCwgYW5kIGl0J3Mgbm90 IGRyb3BwZWQgaW4gdHJhbnNpdCwgdGhlIG90aGVyIGVuZCBtYXkKPmRpc2NhcmQgaXQgYmVmb3Jl IGRlbGl2ZXJpbmcgaXQgdG8gdGhlIFRMUyBsYXllciAoZmx1c2hpbmcgaXRzIGJ1ZmZlcnMKPm9u IHJlY2VpcHQgb2YgYSBSU1QpLgo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ Cj5NZXNzYWdlOiA1Cj5EYXRlOiBUaHUsIDIyIFNlcCAyMDExIDIyOjI1OjQ0ICsxMjAwCj5Gcm9t OiBQZXRlciBHdXRtYW5uIDxwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56Pgo+VG86IG1yZXhAc2Fw LmNvbQo+Q2M6IHRsc0BpZXRmLm9yZwo+U3ViamVjdDogUmU6IFtUTFNdIGludGVyb3AgZm9yIFRM UyBjbGllbnRzIHByb3Bvc2luZyBUTFN2MS4xCj5NZXNzYWdlLUlEOiA8RTFSNmdUUS0wMDAwSVQt TVdAbG9naW4wMS5mb3MuYXVja2xhbmQuYWMubno+Cj4KPk1hcnRpbiBSZXggPG1yZXhAc2FwLmNv bT4gd3JpdGVzOgo+Cj4+TGlrZXdpc2UsIGlmIG15IGFuYWxzaXMgaXMgY29ycmVjdCBhbmQgdGhh dCBCbG9nIGFjY3VyYXRlbHkgZGVzY3JpYmVzCj4+V2luSU5FVHMgYmVoYXZpb3VyLCB0aGF0IFdp bklORVQgYmVoYXZpb3VyIHNob3VsZCBiZSBmaXhlZCB0byBhbGxvdyBNU0lFCj4+dXNlcnMgb24g V2luNyB0byBlbmFibGUgVExTdjEuMSB3aXRoIGxlc3MgcmlzayBvZiBpbnRlcm9wIHByb2JsZW1z Lgo+Cj5JJ3ZlIGJlZW4gdG9sZCB0aGlzIGlzIGFuIGFydGVmYWN0IG9mIHNjaGFubmVsL3dpbmlu ZXQgbGF5ZXJpbmcsIHRoYXQgdGhlcmUncwo+bm8gd2F5IGZvciBzY2hhbm5lbCB0byBjb21tdW5p Y2F0ZSB0aGUgbmVjZXNzYXJ5IGluZm8gdG8gd2luaW5ldCwgc28gaXQKPnJlc3BvbmRzIHdpdGgg YSBSU1QuICBUaGVyZSBhcmUgb3RoZXIgc2l0dWF0aW9ucyB3aGVyZSBpdCBkb2VzIHRoaXMgYXMg d2VsbCwKPm5vdCBqdXN0IHByb3RvY29sLXZlcnNpb24gaXNzdWVzLiAgVGhlcmUncyBhcHBhcmVu dGx5IG5vIGVhc3kgd2F5IHRvIGZpeCB0aGlzCj53aXRob3V0IGNvbnNpZGVyYWJsZSByZS1hcmNo aXRlY3RpbmcuCj4KPlBldGVyLgo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+VExTIG1h aWxpbmcgbGlzdAo+VExTQGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscwo+Cj4KPkVuZCBvZiBUTFMgRGlnZXN0LCBWb2wgODYsIElzc3VlIDE5Cj4qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From daw@cs.berkeley.edu Fri Sep 23 11:48:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D86321F8C83 for ; Fri, 23 Sep 2011 11:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgg7LDYy0LtQ for ; Fri, 23 Sep 2011 11:48:25 -0700 (PDT) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.153.193]) by ietfa.amsl.com (Postfix) with ESMTP id 955A021F8C7A for ; Fri, 23 Sep 2011 11:48:25 -0700 (PDT) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id p8NIp0TZ014159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Sep 2011 11:51:00 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id p8NIp0Ub014156 for tls@ietf.org; Fri, 23 Sep 2011 11:51:00 -0700 From: David Wagner Message-Id: <201109231851.p8NIp0Ub014156@taverner.cs.berkeley.edu> To: tls@ietf.org Date: Fri, 23 Sep 2011 11:51:00 -0700 (PDT) Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 23 Sep 2011 11:51:22 -0700 Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 18:48:27 -0000 I've been reading the discussion about this attack. Of course, until we see a full description of BEAST, it's hard to draw firm conclusions, but I want to suggest a slightly different perspective on some of the views I see mentioned here. I've seen the claim made that ~"it is inherently unsafe to mix trusted and untrusted content over the same encrypted channel, you should never do that, crypto protocols aren't intended to be secure against that"~. I do not think this is a fruitful or sensible way to think about things. Modern crypto protocols do aim to make it safe to mix trusted and untrusted content over the same channel. They aim to be secure against chosen-plaintext attack; and the notion of chosen-plaintext attacks is motivated exactly by ensuring it is safe to mix trusted and untrusted data over the same channel. The designers of SSL and TLS 1.0 presumably intended for SSL to be secure against chosen-plaintext attacks, but we've sinced learned that there is a subtle flaw that enables a successful chosen-plaintext attack. It is a surprise that they fell short of this natural goal and are vulnerable to chosen-plaintext attack (by the way, no need to bring up blockwise-adaptive attacks; blockwise-adaptivity is not needed). TLS 1.1 introduces revisions to fix this problem, and as far as we know, TLS 1.1 is secure against chosen-plaintext attack. The conventional wisdom until now has been that, while there are known chosen-plaintext attacks on TLS 1.0, they are not very serious in practice. As a result, there has not been much pressure to move to TLS 1.1. It may be time to reconsider that conventional wisdom. I don't think it makes sense to advocate "you should never send both trusted and untrusted content over the same crypto channel"; that advice leads to absurd results. Often dynamic web pages includes both trusted and untrusted content; are you going to advocate that no dynamic web page should sent over TLS? In my view, TLS had darn well better be secure in that threat model, and as far as we know, TLS 1.1 is. I've also seen claims on this list that ~"CBC mode is inherently insecure and should never be used"~. I think that's a little too broad. The problem with TLS 1.0 is not that it uses CBC mode and CBC mode is inherently insecure. Rather, the problem is that TLS 1.0 uses a special variant of CBC mode, one which turns out to be insecure against chosen-plaintext attack. In particular, TLS 1.0 uses "ciphertext block chaining", where the last ciphertext block is used as the next IV. This way of choosing the IV enables chosen-plaintext attacks. It is worth pointing out that the crypto-theory community has proven that, if CBC mode is used properly, it is secure against chosen-plaintext attacks. However, those proofs only apply to the standard form of CBC mode, where the IV is chosen randomly. The proofs do not apply to TLS 1.0's "ciphertext block chaining", and in fact, "ciphertext block chaining" is not secure: it is not IND-CPA secure. As long as you use CBC mode securely, these problems go away. TLS 1.1 does use a secure form of CBC mode. So I don't think it is accurate to suggest that CBC mode is necessarily insecure. In summary, I'd recommend: don't throw out the baby with the bathwater. We don't need to throw out CBC mode; TLS 1.1's use of CBC mode is fine. There's nothing wrong with sending both trusted and untrusted content over the same channel, as long as the crypto protocol is designed properly; and as best as we know, TLS 1.1 is fine for that. References for further reading: See Wei Dai's 2002 attacks on SSH and Bodo Moeller's extension of them to SSL and TLS 1.0: http://osdir.com/ml/ietf.secsh/2002-02/msg00049.html http://www.openssl.org/~bodo/tls-cbc.txt Those messages were clear that the implication of their attack is that SSL is not secure against chosen-plaintext attack, and the key enabler for their attack is that SSL's use of CBC mode chooses IVs unsafely. See also Greg Bard's paper, which extends those early observations and gave an early warning about the risks to SSL and TLS 1.0: http://eprint.iacr.org/2006/136 From mrex@sap.com Fri Sep 23 13:00:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F000A21F8BB3 for ; Fri, 23 Sep 2011 13:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3XHktgAqIQy for ; Fri, 23 Sep 2011 13:00:17 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6421F8BAE for ; Fri, 23 Sep 2011 13:00:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8NK2iRX013868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 22:02:44 +0200 (MEST) From: Martin Rex Message-Id: <201109232002.p8NK2isF025222@fs4113.wdf.sap.corp> To: daw@cs.berkeley.edu (David Wagner) Date: Fri, 23 Sep 2011 22:02:44 +0200 (MEST) In-Reply-To: <201109231851.p8NIp0Ub014156@taverner.cs.berkeley.edu> from "David Wagner" at Sep 23, 11 11:51:00 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] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:00:18 -0000 David Wagner wrote: > > I've seen the claim made that ~"it is inherently unsafe to mix trusted > and untrusted content over the same encrypted channel, you should never > do that, crypto protocols aren't intended to be secure against that"~. That is not exactly what I wrote or intended to say. What I said is that SSLv3&TLSv1.0 were clearly and obviously _NEVER_ designed to protect from adaptive chosen plaintext attacks when you multiplex confidential information and attacker-supplied chosen plaintext and have them encrypted under the same TLS connection state. I agree that it would be valuable if TLS provided such protection, because folks on top of TLS would prefer if they could remain ignorant about any consequence their usage might have on the resulting security. > > I do not think this is a fruitful or sensible way to think about things. As it turns out, as unpleasant as it may be, that is the only sensible way to approach the use of TLS. http://tools.ietf.org/html/rfc5246#page-16 Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. As a practical matter, this means that the protocol designer must be aware of what security properties TLS does and does not provide and cannot safely rely on the latter. > > Modern crypto protocols do aim to make it safe to mix trusted and > untrusted content over the same channel. What exactly do you want to say by that? Does this mean that TLS is not modern, because it obviously never had a property that its consumers silently relied on? > > They aim to be secure against chosen-plaintext attack; > and the notion of chosen-plaintext attacks is motivated exactly by > ensuring it is safe to mix trusted and untrusted data over the > same channel. The cbc-based cipher suies of SSLv3&TLSv1.0 *are* as secure against chosen plaintext attacks as humanely possible. But the specific usage scenario where the application caller of TLS provides to the attacker a feedback loop plus SSL record creation capabilities for an established TLS connection is what subverts the security properties of SSLv3&TLSv1.0 for the cbc-ciphersuites. > > The designers of SSL and TLS 1.0 presumably intended for SSL to be > secure against chosen-plaintext attacks, but we've sinced learned > that there is a subtle flaw that enables a successful > chosen-plaintext attack. You're confusing things. SSLv3&TLSv1.0 are perfectly OK, any flaw is entirely in the protocols on top of TLS being ignorant about the attack facilities they open up. It is very essential to understand this difference. the explicit random IVs of TLSv1.1 make the problem *much* harder to exploit, but the root cause of the problem is in the application and still present: letting an attacker perform a chosen plaintext attack. > > It is a surprise that they fell short of this natural goal and are > vulnerable to chosen-plaintext attack It may be a surprise to you, but as the TLS specification very clearly and explicitly states, it MUST NOT be a surprise to any designer of protocol that run on top of TLS. > > TLS 1.1 introduces revisions to fix this problem, and as > far as we know, TLS 1.1 is secure against chosen-plaintext attack. No, TLSv1.1 does *NOT* actually contain a fix! TLSv1.1 contains _only_ a mitigation by imposing a distortion on the "oracle" (equal to the block size of the underlying block cipher), This mitigation should provide a security margin that is sufficient to stop those attacks that have been demonstrated, but the underlying problem still exists. > > I don't think it makes sense to advocate "you should never send both > trusted and untrusted content over the same crypto channel"; that advice > leads to absurd results. Often dynamic web pages includes both trusted > and untrusted content; are you going to advocate that no dynamic web > page should sent over TLS? In my view, TLS had darn well better be > secure in that threat model, and as far as we know, TLS 1.1 is. You're missing the point. The protocol design MUST take into account the side effects of mixing content from trusted and untrusted sources and have it encrypted under the same encryption keys. What is of particular interest is, whether a protocol provides to the attacker a facility for automated guessing and how many attempts it allows the attacker to make. The security of a 4-digit PIN for an ATM card or for a mobile phone GSM SIM card is ridiculously small. But when the "oracle" only accepts 3 "guesses" and then locks the card, there still is sufficient "security margin" for it to offer some amount of protection. Automated online usage scenarios and low-entropy secrets do not go well together. And I would not be surprised if the issue with PayPal was primarily due to a cookie with a ridiculously low entropy, rather than a serious weakness in SSL. > > I've also seen claims on this list that ~"CBC mode is inherently > insecure and should never be used"~. I think that's a little too broad. I'm in full Agreement! > > The problem with TLS 1.0 is not that it uses CBC mode and CBC mode > is inherently insecure. Rather, the problem is that TLS 1.0 uses a > special variant of CBC mode, one which turns out to be insecure against > chosen-plaintext attack. In particular, TLS 1.0 uses "ciphertext block > chaining", where the last ciphertext block is used as the next IV. > This way of choosing the IV enables chosen-plaintext attacks. Actually, letting the attacker know the IV that will be used for his next plaintext, prior to him choosing that plaintext, is what creates the problem. It removes the "distortion" that CBC intends to add for each first crypto block of an SSL record (except the first one) for SSLv3&TLSv1.0. > > It is worth pointing out that the crypto-theory community has proven that, > if CBC mode is used properly, it is secure against chosen-plaintext > attacks. However, those proofs only apply to the standard form of > CBC mode, where the IV is chosen randomly. Again, you're missing the point. The IVs in SSLv3&TLSv1.0 _are_ random in exactly the fashion that CBC is designed to work. The problem isn't the randomness, but that the first IV of each new SSL record is _predictable_ by the attacker. For TLS, processing is normally done in quantities of SSL records, so creating a single new random IV for the start of the SSL record is sufficient. Other environments might be (ab-)using CBC in a directly-streaming (i.e. data is sent as soon as the cipher block is full), and such a usage scenario would need a random IV for EVERY cipher block (i.e. it must not use CBC at all). > > In summary, I'd recommend: don't throw out the baby with the bathwater. > We don't need to throw out CBC mode; TLS 1.1's use of CBC mode is fine. > There's nothing wrong with sending both trusted and untrusted content over > the same channel, as long as the crypto protocol is designed properly; and > as best as we know, TLS 1.1 is fine for that. I do not feel comfortable with this assertion, because it is technically untrue, the underlying problem remains. Rather, I would like to see a quantification of the resulting security margin that this distortion provides. (something like "if your ciphers block size is X, you must change your crypto keys every Y MB/GB)" to maintain an adequate security margin.") -Martin From ekr@rtfm.com Fri Sep 23 13:15:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064D521F8C87 for ; Fri, 23 Sep 2011 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddLqNq4ggfAp for ; Fri, 23 Sep 2011 13:15:29 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9121F8C82 for ; Fri, 23 Sep 2011 13:15:29 -0700 (PDT) Received: by eye4 with SMTP id 4so2654648eye.31 for ; Fri, 23 Sep 2011 13:18:04 -0700 (PDT) Received: by 10.213.32.194 with SMTP id e2mr21625ebd.135.1316809083705; Fri, 23 Sep 2011 13:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.22.211 with HTTP; Fri, 23 Sep 2011 13:17:23 -0700 (PDT) In-Reply-To: <201109232002.p8NK2isF025222@fs4113.wdf.sap.corp> References: <201109231851.p8NIp0Ub014156@taverner.cs.berkeley.edu> <201109232002.p8NK2isF025222@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Fri, 23 Sep 2011 13:17:23 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, David Wagner Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:15:30 -0000 On Fri, Sep 23, 2011 at 1:02 PM, Martin Rex wrote: > Again, you're missing the point. =A0The IVs in SSLv3&TLSv1.0 _are_ > random in exactly the fashion that CBC is designed to work. > The problem isn't the randomness, but that the first IV of > each new SSL record is _predictable_ by the attacker. > > For TLS, processing is normally done in quantities of > SSL records, so creating a single new random IV for the > start of the SSL record is sufficient. > > Other environments might be (ab-)using CBC in a directly-streaming > (i.e. data is sent as soon as the cipher block is full), and > such a usage scenario would need a random IV for EVERY cipher block > (i.e. it must not use CBC at all). Note that RFC4346 specifically prohibits that behavior in S 6.2.3.2: Note: With block ciphers in CBC mode (Cipher Block Chaining), it is critical that the entire plaintext of the record be known before any ciphertext is transmitted. Otherwise, it is possible for the attacker to mount the attack described in [CBCATT]. This restriction was added precisely to counter the attack you describe. -Ekr From paul.hoffman@vpnc.org Fri Sep 23 17:53:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B05A21F8C8B for ; Fri, 23 Sep 2011 17:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8PLTl92vA1O for ; Fri, 23 Sep 2011 17:53:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DB96421F8C22 for ; Fri, 23 Sep 2011 17:53:29 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p8O0u4ro050144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 23 Sep 2011 17:56:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Sep 2011 17:56:04 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [TLS] Duong and Rizzo, the actual attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 00:53:34 -0000 No link to their paper, but here's Adam Langley's writeup and discussion = of the response in Chrome: = --Paul Hoffman, who is still not Adam Langley From ekr@rtfm.com Fri Sep 23 17:58:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B8021F8C3C for ; Fri, 23 Sep 2011 17:58:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GO9P6WPVgrK for ; Fri, 23 Sep 2011 17:58:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5621F8C3A for ; Fri, 23 Sep 2011 17:58:15 -0700 (PDT) Received: by wwf22 with SMTP id 22so2978164wwf.13 for ; Fri, 23 Sep 2011 18:00:50 -0700 (PDT) Received: by 10.227.154.66 with SMTP id n2mr2803443wbw.3.1316826050148; Fri, 23 Sep 2011 18:00:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Fri, 23 Sep 2011 18:00:10 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 23 Sep 2011 18:00:10 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] Duong and Rizzo, the actual attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 00:58:16 -0000 I'm also not Adam Langley, but here's my writeup: http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html On Fri, Sep 23, 2011 at 5:56 PM, Paul Hoffman wrote: > No link to their paper, but here's Adam Langley's writeup and discussion of the response in Chrome: > > --Paul Hoffman, who is still not Adam Langley > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From fweimer@bfk.de Mon Sep 26 06:27:58 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CEB21F8BA8 for ; Mon, 26 Sep 2011 06:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTzENYzBb80x for ; Mon, 26 Sep 2011 06:27:57 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC421F8B98 for ; Mon, 26 Sep 2011 06:27:57 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R8BGX-0002FO-AQ; Mon, 26 Sep 2011 13:30:37 +0000 Received: by bfk.de with local id 1R8BGX-00005w-6A; Mon, 26 Sep 2011 13:30:37 +0000 From: Florian Weimer To: mrex@sap.com References: <201109212350.p8LNoZUk024729@fs4113.wdf.sap.corp> Date: Mon, 26 Sep 2011 13:30:37 +0000 In-Reply-To: <201109212350.p8LNoZUk024729@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu, 22 Sep 2011 01:50:35 +0200 (MEST)") Message-ID: <82oby7ctxe.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:27:58 -0000 * Martin Rex: > I really think we (the TLS WG) should provide a remedy to this awful > situation for the TLS protocol version negotiation in the installed > base. Most vendors offer automated updates these days. Deployments which are not updated are likely to have other issues besides interoperability problems. Protocol fixes still do not end up in deployment. I think we should try to figure out the reason before we try to work around it. If we're unlucky, the workarounds are broken in a similar way, and we gain very little because vendors and deployments which use arguably more secure protocol versions are still punished by an incompatible installation base. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mrex@sap.com Mon Sep 26 07:25:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D121F8D4C for ; Mon, 26 Sep 2011 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.014 X-Spam-Level: X-Spam-Status: No, score=-9.014 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y58UKPGpoTTQ for ; Mon, 26 Sep 2011 07:25:04 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0221F8D56 for ; Mon, 26 Sep 2011 07:25:03 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8QERgVc006749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 16:27:42 +0200 (MEST) From: Martin Rex Message-Id: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp> To: fweimer@bfk.de (Florian Weimer) Date: Mon, 26 Sep 2011 16:27:41 +0200 (MEST) In-Reply-To: <82oby7ctxe.fsf@mid.bfk.de> from "Florian Weimer" at Sep 26, 11 01:30:37 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:25:10 -0000 Florian Weimer wrote: > > * Martin Rex: > > > I really think we (the TLS WG) should provide a remedy to this awful > > situation for the TLS protocol version negotiation in the installed > > base. > > Most vendors offer automated updates these days. Deployments which are > not updated are likely to have other issues besides interoperability > problems. Protocol fixes still do not end up in deployment. The installed base of TLS is around 2 Billien endpoints (no kidding), so any "updates" and new features should seriously take into account how the installed base (in particular the part that is not going to be updated) reacts to them. Allergic reaction (=interop problems) need to be avoided as much as possible. It seems that no TLS client that propose TLSv1.1 or higher today would want to do so without a reconnect fallback facility in place. The problem of the reconnect fallback is, that it precludes a protected negotiation of the TLS version. There seems to be only one extensibility left in TLS that is sufficiently robust to be usable in _all_ scenarios (and that allows for a real negotiation inside TLS rather than an application level fallback after a TLS handshake failure). > > I think we should try to figure out the reason before we try to work > around it. TLS version negotiation (and the checking of the TLS version in the RSA premaster secret) is sufficiently broken across the installed base that we really don't need to know anything else. A "nanny" spec that provide very detailed guidance about how an alternative TLS version negotiation works, plus all the known issues about the known defects in existing TLS version negotiation and how thing MUST be done in future implementations, should be just fine to address the problem ... and to bridge the 10-15 years that it takes before all of the problematic TLS implementations, that currently exist in the installed base, have died off sufficiently so that the original TLS version negotiation (which is _not_ going to be deprecated, just extended) can be expected to work as originally intended. > > If we're unlucky, the workarounds are broken in a similar way, It is not the original TLS version negotiation that is really broken, but it seems to have been underexplained in a fashion that there was apparent confusion among implementors about which protocol version to use on the record layer for a ClientHello and which protocol version to use (and to check) in the RSA permaster secret. To address the problems apparent in the original installed base, I believe that using a much clearer specification with the scope limited to TLS version negotiation, plus real interop testing of that extensibility feature should be sufficient. Traditional SSL&TLS interop was done only in a limited fashion and only about features that were implemented. If anyone had interop-tested the extensibility before shipping, they would have realized their bugs. It's a real pity that Microsoft did _not_ interop test their RSA premaster version check on renegotiation handshakes before they shipped the TLS renegotiation fix for win7/2008R2 (I haven't checked their older SChannels for this characteristic). > > and we gain very little because vendors and deployments which use > arguably more secure protocol versions are still punished by an > incompatible installation base. We can not do anything about the lack of features in the installed base, other than _not_ let that stop us from using better features with newer peers. Currently, the installed base is a _real_ problem for TLS clients to perform a protected TLS version negotiation, and realizing that, the TLS WG should provide an alternative. -Martin From fweimer@bfk.de Mon Sep 26 07:27:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0221F8BAD for ; Mon, 26 Sep 2011 07:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r1mV-420PVm for ; Mon, 26 Sep 2011 07:27:07 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id F3DED21F8B8E for ; Mon, 26 Sep 2011 07:27:06 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R8CBp-0006Yo-H0 for tls@ietf.org; Mon, 26 Sep 2011 14:29:49 +0000 Received: by bfk.de with local id 1R8CBp-00020f-EV for tls@ietf.org; Mon, 26 Sep 2011 14:29:49 +0000 From: Florian Weimer To: tls@ietf.org Date: Mon, 26 Sep 2011 14:29:49 +0000 Message-ID: <8262kfcr6q.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [TLS] Proposal for detecting fraudulent certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:27:07 -0000 I have submitted draft-weimer-tls-previous-certificate-00, which intents to facilitate detection of fraudulent certificates used in the wild: The basic idea is to use leaks from mobile clients moving between networks with and without a clear path to the server. The previous server certificate chain is included in the client hello, so the server receives it when the client transitions to a network with a clear path. This draft prompted my previous question about extension size limits. Unfortunately, that issue makes this very simple idea somewhat complicated, but I tried to add a fairly straightforward workaround. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mrex@sap.com Mon Sep 26 09:03:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C3A21F8D25 for ; Mon, 26 Sep 2011 09:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqEwE7LAWrQn for ; Mon, 26 Sep 2011 09:03:23 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 31CF221F8D24 for ; Mon, 26 Sep 2011 09:03:23 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8QG5vs9010602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 18:06:02 +0200 (MEST) From: Martin Rex Message-Id: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp> To: fweimer@bfk.de (Florian Weimer) Date: Mon, 26 Sep 2011 18:05:57 +0200 (MEST) In-Reply-To: <8262kfcr6q.fsf@mid.bfk.de> from "Florian Weimer" at Sep 26, 11 02:29: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 Subject: Re: [TLS] Proposal for detecting fraudulent certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:03:24 -0000 Florian Weimer wrote: > > I have submitted draft-weimer-tls-previous-certificate-00, which intents > to facilitate detection of fraudulent certificates used in the wild: > > > > The basic idea is to use leaks from mobile clients moving between > networks with and without a clear path to the server. The previous > server certificate chain is included in the client hello, so the server > receives it when the client transitions to a network with a clear path. > > This draft prompted my previous question about extension size limits. > Unfortunately, that issue makes this very simple idea somewhat > complicated, but I tried to add a fairly straightforward workaround. Having the client send _only_ the servers certificate and not the entire certificate path should IMO be sufficient for the purpose you outline. I don't know why you think the 64 KByte TLS extension size limit would be a problem. A non-marginal fraction of the installed base of TLS will puke when encountering a TLS handshake message that is split/fragmented across TLS record boundaries (which have a limit of 16 KByte). The currently most likely situation where this occurs (and the only one that I've seen in the wild so far) are the CertificateRequest handshake message contains a large number (60+) of certification_authorities. Usually, the server tries to stuff the server response (ServerHello,Certificate, CertificateRequest,ServerHelloDone) into one single 16 KByte SSL Record, so even fitting the Server's certificate chain alone should not normally be a problem. But I don't see how this extension could realistically work in a sane fashion. The TLS implementation in TLS servers is not normally keeping a history of previous TLS Server certificates which it ever used (and might not have a persistence of its own for such a purpose), usually not even across process restarts, and having TLS backends of a Web-Server-Farm or hot-backups keep such a history in a consistent fashion is even more unlikely. And end users would probably prefer their TLS clients to tell them right away when a server credential changes unexpectedly, rather than a TLS server telling them, after they come home from a several weeks trip through some contry YYY, that their last several week of connect(s) had all been MITMd... -Martin From fweimer@bfk.de Mon Sep 26 09:18:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBBF21F8CE9 for ; Mon, 26 Sep 2011 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1v6fkCm6YBp for ; Mon, 26 Sep 2011 09:18:47 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E921F8CD9 for ; Mon, 26 Sep 2011 09:18:47 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R8Dvt-0006vQ-IX; Mon, 26 Sep 2011 16:21:29 +0000 Received: by bfk.de with local id 1R8Dvt-0001ts-Fq; Mon, 26 Sep 2011 16:21:29 +0000 From: Florian Weimer To: mrex@sap.com References: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp> Date: Mon, 26 Sep 2011 16:21:29 +0000 In-Reply-To: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 26 Sep 2011 18:05:57 +0200 (MEST)") Message-ID: <82y5xb9svq.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proposal for detecting fraudulent certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:18:48 -0000 * Martin Rex: > Having the client send _only_ the servers certificate and not the > entire certificate path should IMO be sufficient for the purpose you > outline. I don't think it is. The certificate itself is not proof of fraud if an intermediate CA is involved. More importantly, you cannot tell an intercepting corporate proxy (whose certificate is not rooted in the browser PKI) from a certificate which is. > I don't know why you think the 64 KByte TLS extension size limit would > be a problem. The wire format allows for larger server chains (up to 16 MB). This could be abused to bypass detection (just use a certificate with a logotype extension). I just felt I had to say something about that. > But I don't see how this extension could realistically work in a > sane fashion. The TLS implementation in TLS servers is not normally > keeping a history of previous TLS Server certificates which it ever > used (and might not have a persistence of its own for such a purpose), > usually not even across process restarts, and having TLS backends of > a Web-Server-Farm or hot-backups keep such a history in a consistent > fashion is even more unlikely. The TLS server doesn't have to keep this information. It just has to log it or export it over an out-of-band mechanism to the application (similar to what's already done for client certificates). Client hellos are clear text, so you would see the extension on an IDS host, too. > And end users would probably prefer their TLS clients to tell them right > away when a server credential changes unexpectedly, rather than > a TLS server telling them, after they come home from a several weeks > trip through some contry YYY, that their last several week of connect(s) > had all been MITMd... This has UI issues which appear to unsolvable. And even in web browsers, not all TLS activity is user-initiated (e.g., software and filter list updates). Thanks for your comments. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pritikin@cisco.com Mon Sep 26 09:30:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C81F0C41 for ; Mon, 26 Sep 2011 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlu1UI4oGqdH for ; Mon, 26 Sep 2011 09:30:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF211F0C3C for ; Mon, 26 Sep 2011 09:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3449; q=dns/txt; s=iport; t=1317054770; x=1318264370; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=P06aXEC6Dc6zAPzBBxzoaojeojJTFBSxdctBbngRMME=; b=fh6sXKzwTfw0m2VHJw898duZSQ847iGMfkjtLbJSfcykeucsgdAEaZh+ /t/23i89ls2Go7MPD94Ttg1E67ndntoktQINeiEY6UfiihxRnE1sA5PKN JJmyvgbw1KTH7gZWMSLYYnrHPcXBO4TnjZIYEVO3Miu/iMNujvwK8PEJd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAP2ogE6tJV2Y/2dsb2JhbABCqBF4gVMBAQEBAgEBAQEPAScfFQsFCwsYLicwGSKHVgacYAGOKo9whitgBIdyi2CRUQ X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="24088515" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2011 16:32:49 +0000 Received: from rtp-vpn4-1152.cisco.com (rtp-vpn4-1152.cisco.com [10.82.212.128]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8QGWlg0022617; Mon, 26 Sep 2011 16:32:47 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp> Date: Mon, 26 Sep 2011 11:21:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A5A089A-0F7C-4CDD-8104-F6411FC4D710@cisco.com> References: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Proposal for detecting fraudulent certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:30:07 -0000 In the extreme case an invalid sub-CA certificate would be missed by = this method unless clients send the entire chain, so I understand the = author's motivation for completeness.=20 The intention of this idea is to give web server administrators a tool = for discovering fraudulent certificates in the wild. The concern isn't = so much that a few individuals, perhaps even ones on a several week trip = through evil country YYY, get MitM'd but rather that the web site = administrator receives a clue within some "reasonable" timeframe.=20 What defines "reasonable" and if it is sufficient to drive = implementations toward supporting this extension is a harder question.=20= - max On Sep 26, 2011, at 11:05 AM, Martin Rex wrote: > Florian Weimer wrote: >>=20 >> I have submitted draft-weimer-tls-previous-certificate-00, which = intents >> to facilitate detection of fraudulent certificates used in the wild: >>=20 >> >>=20 >> The basic idea is to use leaks from mobile clients moving between >> networks with and without a clear path to the server. The previous >> server certificate chain is included in the client hello, so the = server >> receives it when the client transitions to a network with a clear = path. >>=20 >> This draft prompted my previous question about extension size limits. >> Unfortunately, that issue makes this very simple idea somewhat >> complicated, but I tried to add a fairly straightforward workaround. >=20 > Having the client send _only_ the servers certificate and not the > entire certificate path should IMO be sufficient for the purpose you > outline. >=20 > I don't know why you think the 64 KByte TLS extension size limit would > be a problem. >=20 > A non-marginal fraction of the installed base of TLS will puke when > encountering a TLS handshake message that is split/fragmented across > TLS record boundaries (which have a limit of 16 KByte). The currently > most likely situation where this occurs (and the only one that > I've seen in the wild so far) are the CertificateRequest handshake > message contains a large number (60+) of certification_authorities. > Usually, the server tries to stuff the server response > (ServerHello,Certificate, CertificateRequest,ServerHelloDone) > into one single 16 KByte SSL Record, so even fitting the Server's > certificate chain alone should not normally be a problem. >=20 >=20 > But I don't see how this extension could realistically work in a > sane fashion. The TLS implementation in TLS servers is not normally > keeping a history of previous TLS Server certificates which it ever > used (and might not have a persistence of its own for such a purpose), > usually not even across process restarts, and having TLS backends of > a Web-Server-Farm or hot-backups keep such a history in a consistent > fashion is even more unlikely. >=20 > And end users would probably prefer their TLS clients to tell them = right > away when a server credential changes unexpectedly, rather than > a TLS server telling them, after they come home from a several weeks > trip through some contry YYY, that their last several week of = connect(s) > had all been MITMd... >=20 >=20 > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Mon Sep 26 09:39:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3B911E80B6 for ; Mon, 26 Sep 2011 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.055 X-Spam-Level: X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzuCzvv4dO48 for ; Mon, 26 Sep 2011 09:39:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 64BA811E809C for ; Mon, 26 Sep 2011 09:39:42 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8QGgHYS025913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 18:42:22 +0200 (MEST) From: Martin Rex Message-Id: <201109261642.p8QGgHet015841@fs4113.wdf.sap.corp> To: fweimer@bfk.de (Florian Weimer) Date: Mon, 26 Sep 2011 18:42:17 +0200 (MEST) In-Reply-To: <82y5xb9svq.fsf@mid.bfk.de> from "Florian Weimer" at Sep 26, 11 04:21:29 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] Proposal for detecting fraudulent certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:39:43 -0000 Florian Weimer wrote: > > * Martin Rex: > > > Having the client send _only_ the servers certificate and not the > > entire certificate path should IMO be sufficient for the purpose you > > outline. > > I don't think it is. The certificate itself is not proof of fraud if an > intermediate CA is involved. More importantly, you cannot tell an > intercepting corporate proxy (whose certificate is not rooted in the > browser PKI) from a certificate which is. The Web Server certificate nails down the public&private key for the server. If a MITM has access to the servers private key, then you've lost already, because that MITM can perform a perfect impersonation for the client (the only thing that the MITM could not do is a client-certificate authentication to the real server (unless the real server lacks rfc5746 renegotiation protection). > > > I don't know why you think the 64 KByte TLS extension size limit would > > be a problem. > > The wire format allows for larger server chains (up to 16 MB). This > could be abused to bypass detection (just use a certificate with a > logotype extension). I just felt I had to say something about that. The client could decide to not talk to such TLS servers at all (while theoretically not "standards compliant", it is what a non-marginal fraction of the installed base is doing...) Are you aware of this Microsoft Hotfix: http://support.microsoft.com/kb/2541763 (Curiously, Search on support.microsoft.com seems unable to find this hotfix for keywords. I know about it because it was offered by Windows Update--my Windows machines are on "manuall install"). -Martin From jsalowey@cisco.com Mon Sep 26 15:08:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C411E811F for ; Mon, 26 Sep 2011 15:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.652 X-Spam-Level: X-Spam-Status: No, score=-103.652 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORe4h2xDLiYl for ; Mon, 26 Sep 2011 15:08:09 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DF27111E80C5 for ; Mon, 26 Sep 2011 15:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=537; q=dns/txt; s=iport; t=1317075054; x=1318284654; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zX0jY+DNEP6CZ8NTDFTgyZW/p9vy4UHtGUM0A0wrx2w=; b=hpVAbHZhXIAJmG+466WrqoCgDpQ5YSF0ok8E5qmKSthSUcKo9lRwW8nV zx6Tf9pidMud9VxYO4+pCWWZn7Cu+xpV6pCjndNCyLObdMORTo0cA2eI9 IELleTYT+SrfiH7esmF4EN2FS47yGSuHXaaITF66BcKOk/n4GyypEjIvi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgHAB/4gE6rRDoH/2dsb2JhbABCmSmORXiBUwEBAQECAQEBAQ8BCh00CwULC0YnMBkih1YGm2cBnj2GK2AEh3KLYIUijDE X-IronPort-AV: E=Sophos;i="4.68,446,1312156800"; d="scan'208";a="4426745" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 26 Sep 2011 22:10:38 +0000 Received: from [10.33.249.43] ([10.33.249.43]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8QMAcAX009581; Mon, 26 Sep 2011 22:10:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> Date: Mon, 26 Sep 2011 15:10:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> To: tls@ietf.org X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org Subject: Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 22:08:10 -0000 Working group last call has completed and there were a few minor = revisions suggested. Authors, please submit a revised draft to be = submitted to the IESG. Thanks, Joe On Aug 21, 2011, at 10:07 PM, Joe Salowey wrote: > This announcement is for the working group last call of = draft-ietf-tls-dtls-heartbeat-02. Please send comments to the list by = September 09, 2011. =20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From yngve@opera.com Mon Sep 26 16:09:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47BF21F8D2A for ; Mon, 26 Sep 2011 16:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvL4flqbj0xi for ; Mon, 26 Sep 2011 16:09:55 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 008C921F8D0D for ; Mon, 26 Sep 2011 16:09:54 -0700 (PDT) Received: from lessa-ii (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 p8QNCU49028821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Sep 2011 23:12:32 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Florian Weimer" , "Martin Rex" References: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp> Date: Tue, 27 Sep 2011 01:12:34 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.62 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 23:09:56 -0000 On Mon, 26 Sep 2011 16:27:41 +0200, Martin Rex wrote: > It seems that no TLS client that propose TLSv1.1 or higher today > would want to do so without a reconnect fallback facility in place. > The problem of the reconnect fallback is, that it precludes a protected > negotiation of the TLS version. As long as there is no way to tell if a server is negotiating version correctly, then we do need a fallback mechanism. It is, however, a mechanism that for HTTPS, at least, is becoming less needed, as I indicated earlier in this thread. I also think we have a mechanism now that can be used as an indicator that the server can negotiate version in the required fashion, without needing a fallback system: The Renegotiation Indication Extension. The Renego specification contain a reminder about version and extension tolerance being required. (Yes, I lobbied for the inclusion of that particular text). My testing indicates that the tolerance is included in most Renego patched servers. The failure rate in my sample is 0.092% up to and including TLS 1.2, mostly extension intolerance. The version intolerance for version code 3.x >= 3.4 is 0.049%. There is some problems with the 4.x+ range, though, due to a missing patch at at least one vendor. (To compare the numbers, this is slightly less than the number of servers that may break if the patch suggested for the BEAST issue is implemented, according to my testing.) My suggestion is that clients that use a fallback policy to an older version than their highest supported version, in case negotiation fails, should always negotiate with their highest version indicated if the server is detected as having been Renego patched, and then not fall back in case negotiation fails. That would essentially eliminate the version rollback potential, at least without a weakness being discovered in the protocol integrity check itself. One way to implement such a policy is that the client starts with TLS 1.0 + extensions, and only upgrade to TLS 1.1 or TLS 1.2 if it detects that the server is renego patched. Alternatively (and I prefer this), the client can start with a higher version, and fall back as needed (currently for 1.8% of the sites), but go back up if the server is detected as Renego patched. This would have the benefit that the client saves time when connecting to 98+% of the servers, by not needing a fallback or an upgrade in a new connection. Currently, 30% (463) of the (max) TLS 1.1 servers are not renego patched servers, only a single of the 133 registered TLS 1.2 servers isn't patched. This group is 0.2% of the unpatched servers (39.9%). I doubt that any other mechanism will work better, and deployment will be at least 3 years behind the Renego curve, and will probably have a lower server deployment rate than Renego. Let's see if we can work with what we have, before we design a new mechanism. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From frantz@pwpconsult.com Mon Sep 26 16:29:59 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4921F8DDE for ; Mon, 26 Sep 2011 16:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9wI2AXk2PCZ for ; Mon, 26 Sep 2011 16:29:57 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2978821F8DDB for ; Mon, 26 Sep 2011 16:29:56 -0700 (PDT) Received: from [173.75.83.49] (helo=Bill-Frantzs-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R8Kf7-0000dX-Hv; Mon, 26 Sep 2011 19:32:37 -0400 Date: Mon, 26 Sep 2011 16:32:37 -0700 From: Bill Frantz To: "Yngve N. Pettersen" X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79b5c79f028f5e8728aeaf9483e5383f70350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.49 Cc: tls@ietf.org Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 23:29:59 -0000 I would add on this topic: Browsers should refuse to display their highest security UI=20 indicators if they negotiate a version of TLS with known flaws. This suggestion would apply to SSL3/TLS0 today. Since modern browsers are either automatically updated (Chrome)=20 or updated regularly with automatic checking mechanisms (Safari,=20 =46irefox, Explorer) this policy can be quite dynamic.=20 Organizations which buy high-security certificates will have a=20 strong incentive to upgrade their servers. Other users, perhaps =20 e-commerce sites using credit cards, do not need as high a=20 quality of security and can be a bit behind on the security=20 update treadmill. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345=20 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos,=20 CA 95032 From mrex@sap.com Mon Sep 26 16:41:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07891F0CAE for ; Mon, 26 Sep 2011 16:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWGqpAYRv6tY for ; Mon, 26 Sep 2011 16:41:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ED1091F0CA6 for ; Mon, 26 Sep 2011 16:41:41 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8QNiNVm013260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 01:44:23 +0200 (MEST) From: Martin Rex Message-Id: <201109262344.p8QNiMnZ010262@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Tue, 27 Sep 2011 01:44:22 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Sep 27, 11 01:12:34 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] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 23:41:42 -0000 Yngve N. Pettersen wrote: > > On Mon, 26 Sep 2011 16:27:41 +0200, Martin Rex wrote: > > > > It seems that no TLS client that propose TLSv1.1 or higher today > > would want to do so without a reconnect fallback facility in place. > > The problem of the reconnect fallback is, that it precludes a protected > > negotiation of the TLS version. > > As long as there is no way to tell if a server is negotiating version > correctly, then we do need a fallback mechanism. > > It is, however, a mechanism that for HTTPS, at least, is becoming less > needed, as I indicated earlier in this thread. > > I also think we have a mechanism now that can be used as an indicator that > the server can negotiate version in the required fashion, without needing > a fallback system: The Renegotiation Indication Extension. > > The Renego specification contain a reminder about version and extension > tolerance being required. (Yes, I lobbied for the inclusion of that > particular text). I know that this was the original plan. But these nice plans were foiled when Microsoft shipped their implementation of rfc5746 with KB980436. In retrospect, we ought to have required in rfc5746 to entirely disable the version checking for the RSA premaster secret on the Server side... -Martin From ekr@rtfm.com Mon Sep 26 16:42:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2D41F0CAB for ; Mon, 26 Sep 2011 16:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPw6LxuD1Ik0 for ; Mon, 26 Sep 2011 16:42:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2B121F0CA6 for ; Mon, 26 Sep 2011 16:42:14 -0700 (PDT) Received: by wyh21 with SMTP id 21so4804841wyh.31 for ; Mon, 26 Sep 2011 16:44:58 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr49128wby.18.1317080698182; Mon, 26 Sep 2011 16:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 16:44:18 -0700 (PDT) From: Eric Rescorla Date: Mon, 26 Sep 2011 16:44:18 -0700 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 23:42:15 -0000 I've been doing some thinking about how to prevent rollback to TLS 1.0/SSLv3 from TLS 1.1-capable agents. Since there's very little deployment of TLS 1.1+, basically anything we do now will roll out more or less in parallel with TLS 1.1 deployment, as long as it's backward compatible.The obvious technique here is to stuff the relevant indicator in the cipher suites list, since we know that servers ignore unknown entries there. I've taken an initial crack at a draft for this: http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt -Ekr From ekr@rtfm.com Mon Sep 26 16:51:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB911F0CAB for ; Mon, 26 Sep 2011 16:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBF-o1fVQClj for ; Mon, 26 Sep 2011 16:51:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB811F0CA6 for ; Mon, 26 Sep 2011 16:51:18 -0700 (PDT) Received: by wyh21 with SMTP id 21so4812699wyh.31 for ; Mon, 26 Sep 2011 16:54:02 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr56340wby.18.1317081242331; Mon, 26 Sep 2011 16:54:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 16:53:22 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 26 Sep 2011 16:53:22 -0700 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 23:51:20 -0000 P.S. Yes, I know this is a big stinking hack. On Mon, Sep 26, 2011 at 4:44 PM, Eric Rescorla wrote: > I've been doing some thinking about how to prevent rollback to > TLS 1.0/SSLv3 from TLS 1.1-capable agents. > > Since there's very little deployment of TLS 1.1+, basically anything > we do now will roll out more or less in parallel with TLS 1.1 deployment, > as long as it's backward compatible.The obvious technique here is to > stuff the relevant indicator in the cipher suites list, since we know that > servers ignore unknown entries there. > > I've taken an initial crack at a draft for this: > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > > -Ekr > From nico@cryptonector.com Mon Sep 26 17:10:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37221F8C78 for ; Mon, 26 Sep 2011 17:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjGcBiQpgx9p for ; Mon, 26 Sep 2011 17:10:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id B480821F8C6A for ; Mon, 26 Sep 2011 17:10:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id A0B306B0079 for ; Mon, 26 Sep 2011 17:13:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=xoTr2W4iZEP0elC1oZ965 tPmdkzxJrG4/s7T1kRtUkcfQKizrkeg20My3nXDSe4HP0hatNmX3PYv/tYK2Aqzv fwr/uItkS6VqG8lTK8i3PKbp4dMwzBQcio6BJRx3vF5y/XIZFuKEmzaGwvDW0Dik rIoajVeJH56Utzq1T7fdtM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=TlJcRpzx/PfOv0u6qfUA xjRhhk4=; b=FHWgTCcKfhyj5W+3wFf2IgDbAhPPhMZwW1pFYNLu/FvaUg5/4Yok 8va1vs46x2CmLotkqPRXm1tsuldo2loRKyvdKU5cNu/0pWhUQxMhnB24SnMUv/Gz FmoEdaVZq4YOdMhKW5Z2Xbiy9CyGnFlUtMDDYZBHsDD3aOYS4GOMgNM= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 831316B0059 for ; Mon, 26 Sep 2011 17:13:22 -0700 (PDT) Received: by gyd12 with SMTP id 12so5812573gyd.31 for ; Mon, 26 Sep 2011 17:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.56.225 with SMTP id d1mr33375225pbq.109.1317082401729; Mon, 26 Sep 2011 17:13:21 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Mon, 26 Sep 2011 17:13:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 19:13:21 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:10:39 -0000 On Mon, Sep 26, 2011 at 6:53 PM, Eric Rescorla wrote: > P.S. Yes, I know this is a big stinking hack. So what, we've done the same sort of thing in SSHv2. I say go for it. Nico -- From mrex@sap.com Mon Sep 26 17:18:53 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAAC11E80AA for ; Mon, 26 Sep 2011 17:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.909 X-Spam-Level: X-Spam-Status: No, score=-8.909 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bjq+KF78bF0 for ; Mon, 26 Sep 2011 17:18:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE611E808A for ; Mon, 26 Sep 2011 17:18:52 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8R0LXRf015832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 02:21:33 +0200 (MEST) From: Martin Rex Message-Id: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 27 Sep 2011 02:21:33 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Sep 26, 11 04:44:18 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] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:18:53 -0000 Eric Rescorla wrote: > > I've been doing some thinking about how to prevent rollback to > TLS 1.0/SSLv3 from TLS 1.1-capable agents. > > Since there's very little deployment of TLS 1.1+, basically anything > we do now will roll out more or less in parallel with TLS 1.1 deployment, > as long as it's backward compatible.The obvious technique here is to > stuff the relevant indicator in the cipher suites list, since we know that > servers ignore unknown entries there. > > I've taken an initial crack at a draft for this: > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt My personal favourite would be to use an OR'ed bitmask, and we could either "waste" a whole 256 cipher suite codepoints (or be more conservative and require the reserved bits below to be all ZERO--requiring only 16 cipher suite code points starting at a block boundary). version_major = 0xYY (assigned/reserved by IANA as { 0xYY, * } ) version_minor = a set of 8 bits indicating TLS version offered by client x80|x40|x20|x10|x08|x04|x02|x01 Value 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 Bit Position | | | | | | | | | | | | | | | | | | | | | | | `- indicates SSLv3 support {0x03,0x00} | | | | | | `----- indicates TLSv1.0 support {0x03,0x01} | | | | | `--------- indicates TLSv1.1 support {0x03,0x02} | | | | `------------- indicates TLSv1.2 support {0x03,0x03} | | | `----------------- (reserved for TLSv1.3) | | `--------------------- (reserved for TLSv1.4) | `------------------------- (reserved for TLSv1.5) `----------------------------- (reserved for TLSv1.6) So a client offering SSLv3, TLSv1.0 an TLSv1.1 would include cipher suite { 0xYY, 0x07 } And a client offering TLSv1.0 and TLSv1.2 (but not SSLv3 and not TLSv1.1) would include cipher suite { 0xYY, 0x82 } -Martin From ekr@rtfm.com Mon Sep 26 17:26:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7165C21F8E33 for ; Mon, 26 Sep 2011 17:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.762 X-Spam-Level: X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+WfpUdbP5Ys for ; Mon, 26 Sep 2011 17:26:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95A4D21F8E31 for ; Mon, 26 Sep 2011 17:26:04 -0700 (PDT) Received: by wyh21 with SMTP id 21so4844323wyh.31 for ; Mon, 26 Sep 2011 17:28:48 -0700 (PDT) Received: by 10.227.178.141 with SMTP id bm13mr3316674wbb.33.1317083327777; Mon, 26 Sep 2011 17:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 17:28:07 -0700 (PDT) In-Reply-To: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> References: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Mon, 26 Sep 2011 17:28:07 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:26:05 -0000 Hmm... What's the advantage of something this complicated/expressive, especially given that there is no way to currently express "I speak TLS 1.2 but not 1.0"? My objective here isn't to replace the TLS version negotiation mechanism but merely to remove the downgrade attack problem. If we get that right, and there is WG interest in revamping the version system, we can do that at some other time. -Ekr On Mon, Sep 26, 2011 at 5:21 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> I've been doing some thinking about how to prevent rollback to >> TLS 1.0/SSLv3 from TLS 1.1-capable agents. >> >> Since there's very little deployment of TLS 1.1+, basically anything >> we do now will roll out more or less in parallel with TLS 1.1 deployment= , >> as long as it's backward compatible.The obvious technique here is to >> stuff the relevant indicator in the cipher suites list, since we know th= at >> servers ignore unknown entries there. >> >> I've taken an initial crack at a draft for this: >> http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-versio= n-cs.txt > > My personal favourite would be to use an OR'ed bitmask, and we could > either "waste" a whole 256 cipher suite codepoints (or be more conservati= ve > and require the reserved bits below to be all ZERO--requiring > only 16 cipher suite code points starting at a block boundary). > > =A0 =A0version_major =A0=3D 0xYY (assigned/reserved by IANA as { 0xYY, * = } ) > =A0 =A0version_minor =A0=3D a set of 8 bits indicating TLS version offere= d by client > > =A0 =A0 x80|x40|x20|x10|x08|x04|x02|x01 =A0 Value > =A0 =A0 =A07 | 6 | 5 | 4 | 3 | 2 | 1 | 0 =A0 =A0Bit Position > > =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 `- =A0indicates SSLv= 3 =A0 support {0x03,0x00} > =A0 =A0 =A0| =A0 | =A0 | =A0 | =A0 | =A0 | =A0 `----- =A0indicates TLSv1.= 0 support {0x03,0x01} > =A0 =A0 =A0| =A0 | =A0 | =A0 | =A0 | =A0 `--------- =A0indicates TLSv1.1 = support {0x03,0x02} > =A0 =A0 =A0| =A0 | =A0 | =A0 | =A0 `------------- =A0indicates TLSv1.2 su= pport {0x03,0x03} > =A0 =A0 =A0| =A0 | =A0 | =A0 `----------------- =A0 =A0(reserved for TLSv= 1.3) > =A0 =A0 =A0| =A0 | =A0 `--------------------- =A0 =A0(reserved for TLSv1.= 4) > =A0 =A0 =A0| =A0 `------------------------- =A0 =A0(reserved for TLSv1.5) > =A0 =A0 =A0`----------------------------- =A0 =A0(reserved for TLSv1.6) > > =A0 =A0So a client offering SSLv3, TLSv1.0 an TLSv1.1 > =A0 =A0would include cipher suite =A0{ 0xYY, 0x07 } > > =A0 =A0And a client offering TLSv1.0 and TLSv1.2 (but not SSLv3 and not T= LSv1.1) > =A0 =A0would include cipher suite =A0{ 0xYY, 0x82 } > > > -Martin > From mrex@sap.com Mon Sep 26 17:30:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA07E21F8E4F for ; Mon, 26 Sep 2011 17:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qEmIceEfhFt for ; Mon, 26 Sep 2011 17:30:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EA06321F8E38 for ; Mon, 26 Sep 2011 17:30:27 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8R0XA9Z002453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 02:33:10 +0200 (MEST) From: Martin Rex Message-Id: <201109270033.p8R0XAL1012920@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 27 Sep 2011 02:33:10 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Sep 26, 11 04:53:22 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] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:30:31 -0000 Eric Rescorla wrote: > > P.S. Yes, I know this is a big stinking hack. We've been seeing a significant delay in adoption of TLSv1.1. So while it might smell like a dirty hack to some, I think it is a reasonable approach to ease the transition pain for the installed base. As it turned out, the TLS cipher suites were the only protocol extensibility that had been really interop tested from the beginning, probably because the list of cipher suites was already quite long when Netscape brought SSLv3 to the IETF for standardization and most new implementors started interop testing with much fewer cipher suites in their initial implementations. If you look at slowly IPv6 adoption is progressing, it looks like they do not have enough "dirty hacks" in place yet. :-] -Martin From ekr@rtfm.com Mon Sep 26 17:33:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EE521F8CF3 for ; Mon, 26 Sep 2011 17:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.894 X-Spam-Level: X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouNunyRfdc1g for ; Mon, 26 Sep 2011 17:33:56 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C69D21F8CF1 for ; Mon, 26 Sep 2011 17:33:56 -0700 (PDT) Received: by wyh21 with SMTP id 21so4851648wyh.31 for ; Mon, 26 Sep 2011 17:36:39 -0700 (PDT) Received: by 10.227.112.137 with SMTP id w9mr6938501wbp.3.1317083799660; Mon, 26 Sep 2011 17:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 17:35:57 -0700 (PDT) In-Reply-To: <201109270033.p8R0XAL1012920@fs4113.wdf.sap.corp> References: <201109270033.p8R0XAL1012920@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Mon, 26 Sep 2011 17:35:57 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:33:57 -0000 On Mon, Sep 26, 2011 at 5:33 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> P.S. Yes, I know this is a big stinking hack. > > We've been seeing a significant delay in adoption of TLSv1.1. > So while it might smell like a dirty hack to some, I think it is a > reasonable approach to ease the transition pain for the installed base. > > As it turned out, the TLS cipher suites were the only protocol extensibil= ity > that had been really interop tested from the beginning, probably because = the > list of cipher suites was already quite long when Netscape brought > SSLv3 to the IETF for standardization and most new implementors > started interop testing with much fewer cipher suites in their > initial implementations. > > If you look at slowly IPv6 adoption is progressing, it looks like they > do not have enough "dirty hacks" in place yet. =A0:-] I tend to agree with you here... I was just trying to preempt people telling me that using the cipher suites was ugly, since I wholly agree with that criticism. I just figure it's ugly but neces= sary. Best, -Ekr From mrex@sap.com Mon Sep 26 17:45:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F591F0CAB for ; Mon, 26 Sep 2011 17:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.055 X-Spam-Level: X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEqlQSBeF0Dm for ; Mon, 26 Sep 2011 17:45:20 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 880481F0C86 for ; Mon, 26 Sep 2011 17:45:20 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8R0m4dv003290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 02:48:04 +0200 (MEST) From: Martin Rex Message-Id: <201109270048.p8R0m3pJ013743@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 27 Sep 2011 02:48:03 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Sep 26, 11 05:28: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] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:45:21 -0000 Eric Rescorla wrote: > > Hmm... What's the advantage of something this complicated/expressive, > especially given that there is no way to currently express > "I speak TLS 1.2 but not 1.0"? I know that with "current TLS version negotiation" it is not possible to convey the exact protocol version that a clients supports or may want to talk. The issue with the original scheme is, that in order to offer TLSv1.2, you MUST (de facto) implement *ALL* prior protocol versions. But that currently means that you have to take all existing specs, put them side-by-side and work out the diffs yourself, because successors specs don't show the PDUs and semantics of previous protocol versions side-by-side. > > My objective here isn't to replace the TLS version negotiation mechanism > but merely to remove the downgrade attack problem. If we get that right, > and there is WG interest in revamping the version system, we can do that at > some other time. I don't think that revising the TLS version negotiation yet another time is a sensible idea. If we do it at all, make it right this time. It is really much more important to do the interop testing before implementations of this are shipped, than making it the most simplistic change possible in order to obtain a protected negotiation. -Martin From agl@google.com Mon Sep 26 17:54:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BADB1F0C86 for ; Mon, 26 Sep 2011 17:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFH8LhhQoSnI for ; Mon, 26 Sep 2011 17:54:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7854421F8CEC for ; Mon, 26 Sep 2011 17:54:07 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p8R0ukKU021733 for ; Mon, 26 Sep 2011 17:56:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317085006; bh=SebTVZqCuHpEYWgxq1o5BOEsfNU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TCwojykSS3CetJ0ZcNSTMBNy9SC6yV4ONComON/oIA4jbM26vr92rhcA5a5le+1db MDRaCZPbisiFLosboiTnw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=JVb8Q3vafUk/MSl50mX++EqzdUuYwpR3Lt8nj2tZcjHH2RLg24fUFGGF7QXF4GHm9 RKsYMiSWBopAQMyK0IIgA== Received: from iadx2 (iadx2.prod.google.com [10.12.150.2]) by hpaq14.eem.corp.google.com with ESMTP id p8R0ueTH020640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 26 Sep 2011 17:56:44 -0700 Received: by iadx2 with SMTP id x2so6015547iad.20 for ; Mon, 26 Sep 2011 17:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6qigi/sMn4evp19YQAZva32fKnzq8vF+XvUCRTxeI7w=; b=cQIU0zibWkErpeTDd0Bxctp2g9iaNMPOkn5kqZ9dcN3TflScWEo8OG+Iodl5GlxwlB 6jq9q1+qBTFQ3VK9ymnw== Received: by 10.231.28.205 with SMTP id n13mr2861848ibc.47.1317085004674; Mon, 26 Sep 2011 17:56:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.28.205 with SMTP id n13mr2861826ibc.47.1317085003513; Mon, 26 Sep 2011 17:56:43 -0700 (PDT) Received: by 10.231.19.137 with HTTP; Mon, 26 Sep 2011 17:56:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 20:56:43 -0400 Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 00:54:08 -0000 On Mon, Sep 26, 2011 at 7:44 PM, Eric Rescorla wrote: > I've taken an initial crack at a draft for this: > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt In Table 1 you list TLS 1.1 twice. It has been suggested by Yngve that the existing SSLv3, renego SCSV be used to indicate TLS 1.0 support. That's something that I suspect we will try. > If the SCSV value is present and is not equal to ClientHello.client_version, then the server MUST terminate the handshake with a fatal "handshake_failure" alert. This doesn't really make the deployment of new TLS versions that much easier. The client would still have to try 1.2, 1.1, 1.0 etc. What would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the client as if it has advertised 1.2. Cheers AGL From ekr@rtfm.com Mon Sep 26 18:12:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5821F8D72 for ; Mon, 26 Sep 2011 18:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.895 X-Spam-Level: X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af+g0AGWOVJj for ; Mon, 26 Sep 2011 18:12:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D25FF21F8D6C for ; Mon, 26 Sep 2011 18:12:25 -0700 (PDT) Received: by wyh21 with SMTP id 21so4884710wyh.31 for ; Mon, 26 Sep 2011 18:15:09 -0700 (PDT) Received: by 10.227.178.141 with SMTP id bm13mr3362396wbb.33.1317086109216; Mon, 26 Sep 2011 18:15:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 18:14:29 -0700 (PDT) In-Reply-To: <201109270048.p8R0m3pJ013743@fs4113.wdf.sap.corp> References: <201109270048.p8R0m3pJ013743@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Mon, 26 Sep 2011 18:14:29 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:12:26 -0000 On Mon, Sep 26, 2011 at 5:48 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> Hmm... What's the advantage of something this complicated/expressive, >> especially given that there is no way to currently express >> "I speak TLS 1.2 but not 1.0"? > > I know that with "current TLS version negotiation" it is not possible > to convey the exact protocol version that a clients supports or may > want to talk. > > The issue with the original scheme is, that in order to offer TLSv1.2, > you MUST (de facto) implement *ALL* prior protocol versions. > But that currently means that you have to take all existing specs, > put them side-by-side and work out the diffs yourself, because > successors specs don't show the PDUs and semantics of previous > protocol versions side-by-side. I don't think I understand this: if you have a client which only wishes to support TLS 1.2, what it currently does is to offer TLS 1.2 in the ClientHello and then if the server selects a lower version in the ServerHello, the client generates an error. In an environment where the client could indicate any combination of versions, the impact of implementing TLS 1.2 only would be that a server which did not support TLS 1.2 would generate an error instead of a ClientHello. Since servers are supposed to select the highest common version, I'm not sure I see serious difference between these two. >> My objective here isn't to replace the TLS version negotiation mechanism >> but merely to remove the downgrade attack problem. If we get that right, >> and there is WG interest in revamping the version system, we can do that= at >> some other time. > > I don't think that revising the TLS version negotiation yet another > time is a sensible idea. =A0If we do it at all, make it right this > time. I'm not sold that it's that lacking, other than the fact that people have implemented it wrong. -Ekr From ekr@rtfm.com Mon Sep 26 18:17:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802F621F87FC for ; Mon, 26 Sep 2011 18:17:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ugXHnb3NwB for ; Mon, 26 Sep 2011 18:17:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF121F86EE for ; Mon, 26 Sep 2011 18:17:04 -0700 (PDT) Received: by wyh21 with SMTP id 21so4888709wyh.31 for ; Mon, 26 Sep 2011 18:19:48 -0700 (PDT) Received: by 10.227.178.141 with SMTP id bm13mr3367184wbb.33.1317086387247; Mon, 26 Sep 2011 18:19:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 18:19:07 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 26 Sep 2011 18:19:07 -0700 Message-ID: To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:17:05 -0000 On Mon, Sep 26, 2011 at 5:56 PM, Adam Langley wrote: > On Mon, Sep 26, 2011 at 7:44 PM, Eric Rescorla wrote: >> I've taken an initial crack at a draft for this: >> http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > > In Table 1 you list TLS 1.1 twice. My bad. >> If the SCSV value is present and is not equal to ClientHello.client_version, then the server MUST terminate the handshake with a fatal "handshake_failure" alert. > > This doesn't really make the deployment of new TLS versions that much > easier. The client would still have to try 1.2, 1.1, 1.0 etc. What > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the > client as if it has advertised 1.2. That's certainly a possibility, but now we're actually substituting the negotiation mechanism with one based on smuggling it in ciphersuites, which is pretty gross. Moreover, unless I'm missing something, this leaves the client unable to offer extensions (since they often cause breakage as well) unless it has fallback, at which point why not use fallback for version logic as well? I see your point about trying sequentially, but I don't think the situation is that dire. It's probably reasonable to offer TLS 1.1 or 1.2 and assume that TLS 1.1/1.2 stacks do TLS version negotiation properly. If that fails, fall back aggressively to SSLv3 or TLS 1.0 with nothing offensive like extensions. Or am I missing something? -Ekr From mrex@sap.com Mon Sep 26 18:19:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515851F0C47 for ; Mon, 26 Sep 2011 18:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZkr5Kz4wn5l for ; Mon, 26 Sep 2011 18:19:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1FB21F8E21 for ; Mon, 26 Sep 2011 18:19:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8R1MOXt020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 03:22:24 +0200 (MEST) From: Martin Rex Message-Id: <201109270122.p8R1MOao015930@fs4113.wdf.sap.corp> To: agl@google.com (Adam Langley) Date: Tue, 27 Sep 2011 03:22:24 +0200 (MEST) In-Reply-To: from "Adam Langley" at Sep 26, 11 08:56:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:19:44 -0000 Adam Langley wrote: > > On Mon, Sep 26, 2011 at 7:44 PM, Eric Rescorla wrote: > > I've taken an initial crack at a draft for this: > > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > > In Table 1 you list TLS 1.1 twice. 2nd column in EKRs draft in front of [RFC5246]? probably simple typo. And while in theory I do not see a need for a SSLv3 SCSV in EKRs proposal, it would allow testing the processing of this SCSV even before implementing TLSv1.2 -- because to test with some amount of certainty you need your code to support at least two different versions. > > It has been suggested by Yngve that the existing SSLv3, renego SCSV be > used to indicate TLS 1.0 support. That's something that I suspect we > will try. I'm confused. SSLv3-only servers (or TLS Servers limited to SSLv3 for whatever administrative reason) are explicitly allowed to support TLS renegotiation! If your client creates and persists longs lists of server properties so that it may connect in the future without having to go through a TLS handshake failure and app-level reconnect fallback, then this may be of help. The idea behind doing TLS version proposal through a TLS cipher suite to allow simple TLS clients, that neither persist server feature characteristics nor contain a reconnect fallback, to succeed the TLS handshake and use TLSv1.1 without having to worry about handshake failures from version-intolerant Servers (independent of whether they choke on ClientHello.client_version > TLSv1.0 or whether they do an incorrect RSA premaster secret client_version check. > > > If the SCSV value is present and is not equal to > > ClientHello.client_version, then the server MUST terminate > > the handshake with a fatal "handshake_failure" alert. > > This doesn't really make the deployment of new TLS versions that much > easier. Correct, this requirement in EKRs proposal is quite counter-productive to the problem and needs to be removed. I would actually prefer not to see any "MUST abort" in that document... > > The client would still have to try 1.2, 1.1, 1.0 etc. What > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the > client as if it has advertised 1.2. Correct. The ClientHello.client_version = { 0x03, 0x01 } is sent to keep the potentially version intolerant installed base working, the TLS 1.1 or TLS 1.2 SCSV is sent to negotiate 1.1 or 1.2 with peers supporting this scheme in spite of the conservative ClientHello.client_version. -Martin From mrex@sap.com Mon Sep 26 18:33:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0826F21F8EA3 for ; Mon, 26 Sep 2011 18:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.057 X-Spam-Level: X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18OCMinGIEQv for ; Mon, 26 Sep 2011 18:33:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4711821F8EA1 for ; Mon, 26 Sep 2011 18:33:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8R1Zq40007511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 03:35:57 +0200 (MEST) From: Martin Rex Message-Id: <201109270135.p8R1Zq7h016386@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 27 Sep 2011 03:35:52 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Sep 26, 11 06:19: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] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:33:17 -0000 Eric Rescorla wrote: > > > > > If the SCSV value is present and is not equal to > > > ClientHello.client_version, then the server MUST terminate > > > the handshake with a fatal "handshake_failure" alert. > > > > This doesn't really make the deployment of new TLS versions that much > > easier. The client would still have to try 1.2, 1.1, 1.0 etc. What > > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the > > client as if it has advertised 1.2. > > That's certainly a possibility, but now we're actually substituting > the negotiation mechanism with one based on smuggling it in ciphersuites, > which is pretty gross. Now I'm somewhat puzzled. Was your motivation to propose this only to ensure that a TLSv1.0, SSLv3 or SSL Version 2 CLIENT-HELLO results in a fatal handshake failure when both peers support higher than TLSv1.0? I'm strongly opposed to that idea. What I'm looking for is a protocol enhancements that will **IMPROVE** TLS interop by having more TLS handshakes succeed. > > Moreover, unless I'm missing something, this leaves the client unable to offer > extensions (since they often cause breakage as well) unless it has fallback, > at which point why not use fallback for version logic as well? No problem, TLSv1.1 and TLSv1.2 work just fine without extensions. And if that is really an issue, an alternative would be to perform a renegotiation directly after the handshake succeeded -- with the added bonus that it incurs no handshake failure -- meaning that it could be performed entirely within TLS and without involvement of the calling application. A handshake failure is a significant problem, since it always requires the involvement of the application and a new network connection. -Martin From agl@google.com Mon Sep 26 18:35:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953B921F8EB1 for ; Mon, 26 Sep 2011 18:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnJUwfi69Lvc for ; Mon, 26 Sep 2011 18:35:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C1DE421F8EB0 for ; Mon, 26 Sep 2011 18:35:42 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p8R1cMcZ008309 for ; Mon, 26 Sep 2011 18:38:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317087502; bh=uuKIuxluaz58nQO9Tr5IEvfKGWY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Z3bKNEn+x/WVJnYgebqy6F7Xjwp2+CPjRuNRpTLXQa2V5FTW9Z8oZo1kG1fpFks3j tIurFvvH4ZqYtEuGrDf6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=pv55IhvfaXA8nKS9AniY8vM6c/DMEKGrVE4jfnFey5heOA/L5LwVRt5r+15WkVkRT BfPun79yFjgVpl7wVfW+Q== Received: from iagf6 (iagf6.prod.google.com [10.12.208.6]) by hpaq1.eem.corp.google.com with ESMTP id p8R1bsPb016175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 26 Sep 2011 18:38:20 -0700 Received: by iagf6 with SMTP id f6so7816177iag.18 for ; Mon, 26 Sep 2011 18:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2cV1nLYfYIaEW7FCmKFrSlebkiTwSndVN3dupIXuSO4=; b=rnj/XztECvOs79DS+oHwNMSVfWzhPQoTUVGXQfh2zFMV3T85VeV57QCCXPI1YrWrjP 5rS0vUfcsEo0zouvsjng== Received: by 10.231.28.205 with SMTP id n13mr2911023ibc.47.1317087500485; Mon, 26 Sep 2011 18:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.28.205 with SMTP id n13mr2911018ibc.47.1317087500316; Mon, 26 Sep 2011 18:38:20 -0700 (PDT) Received: by 10.231.19.137 with HTTP; Mon, 26 Sep 2011 18:38:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 21:38:20 -0400 Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:35:43 -0000 On Mon, Sep 26, 2011 at 9:19 PM, Eric Rescorla wrote: > That's certainly a possibility, but now we're actually substituting > the negotiation > mechanism with one based on smuggling it in ciphersuites, which is pretty gross. > Moreover, unless I'm missing something, this leaves the client unable to offer > extensions (since they often cause breakage as well) unless it has fallback, > at which point why not use fallback for version logic as well? What we want is the version negotiation that we're supposed to have. But it broke :( Let's say that NSS does TLS 1.2. We are probably only going to have one level to fallback: to SSLv3, no compression. So servers which currently do 1.0 or 1.1, but which are intolerant to a 1.2 client are going to get SSLv3 instead. The last numbers that I saw from Yngve were that these are ~2% of the Internet. Not the end of the world, but we can avoid it if we advertise 1.0 in the version and 1.2 with SCSV. Depends if the WG can stomach it :) Cheers AGL From marsh@extendedsubset.com Mon Sep 26 18:36:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BF521F8EB0 for ; Mon, 26 Sep 2011 18:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599, MANGLED_SAVELE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCmG4oo5SX7H for ; Mon, 26 Sep 2011 18:36:26 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22121F8EAE for ; Mon, 26 Sep 2011 18:36:26 -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 1R8Mda-000HTd-5U; Tue, 27 Sep 2011 01:39:10 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1E2516067; Tue, 27 Sep 2011 01:39:07 +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: U2FsdGVkX18K+X2J4tc+4psa3ymC9rmrqBGMPvzFhnw= Message-ID: <4E81293A.4000402@extendedsubset.com> Date: Mon, 26 Sep 2011 20:39:06 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: mrex@sap.com References: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> In-Reply-To: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:36:27 -0000 I agree that the current semantics are starting to feel a bit silly. Support for TLS 1.2 also implies a willingness to speak SSLv3? Are we expecting to continue this forever? On 09/26/2011 07:21 PM, Martin Rex wrote: > > My personal favourite would be to use an OR'ed bitmask, and we could > either "waste" a whole 256 cipher suite codepoints (or be more conservative > and require the reserved bits below to be all ZERO--requiring > only 16 cipher suite code points starting at a block boundary). > > version_major = 0xYY (assigned/reserved by IANA as { 0xYY, * } ) > version_minor = a set of 8 bits indicating TLS version offered by client > > x80|x40|x20|x10|x08|x04|x02|x01 Value > 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 Bit Position > > | | | | | | | | > | | | | | | | | > | | | | | | | `- indicates SSLv3 support {0x03,0x00} > | | | | | | `----- indicates TLSv1.0 support {0x03,0x01} > | | | | | `--------- indicates TLSv1.1 support {0x03,0x02} > | | | | `------------- indicates TLSv1.2 support {0x03,0x03} > | | | `----------------- (reserved for TLSv1.3) > | | `--------------------- (reserved for TLSv1.4) > | `------------------------- (reserved for TLSv1.5) > `----------------------------- (reserved for TLSv1.6) But the current cipher suite negotiation is already a set. Why not just have one cipher suite value for each version and burn only 4 or so code points rather than 256? On 09/26/2011 08:14 PM, Eric Rescorla wrote: > In an environment where the client could indicate any combination of > versions, the impact of implementing TLS 1.2 only would be that a > server which did not support TLS 1.2 would generate an error instead > of a ClientHello. [ServerHello?] > > Since servers are supposed to select the highest common version, I'm > not sure I see serious difference between these two. The difference is that somebody will look at Wireshark and instead of seeing random disconnects and thinking they're the subject of some low-level DoS attack, they'll see a bright yellow line that reads: "TLS Alert: Endpoints support no common protocol version." - Marsh From n.mavrogiannopoulos@gmail.com Mon Sep 26 23:58:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58E21F8E0F for ; Mon, 26 Sep 2011 23:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TTbW1VrOeVW for ; Mon, 26 Sep 2011 23:58:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 842C521F8E0D for ; Mon, 26 Sep 2011 23:58:18 -0700 (PDT) Received: by wyh21 with SMTP id 21so5216005wyh.31 for ; Tue, 27 Sep 2011 00:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YFK9xlGLV6S2cE1yIGCNrCZk0IGbFvTCZCwmZthWalg=; b=A45KqBAnnfQIfxeEU6l33slkCuFszX0ny91i3frsZrt2jFK4nd79+pV3uZgD71uLVg qyl2JFh6egR3zjNox5oonMojXiG4l8W4iO5h2ZwECqW36TRHLQVK/b+c6WQpkQkuwaZo 2URJTYK12RXCt3JrNgLTwNs8LKe0trbyHUzK8= Received: by 10.227.175.77 with SMTP id w13mr8151127wbz.53.1317106862507; Tue, 27 Sep 2011 00:01:02 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be. [94.225.167.75]) by mx.google.com with ESMTPS id p2sm34572629wbo.17.2011.09.27.00.01.00 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 00:01:01 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E8174BA.8060203@gnutls.org> Date: Tue, 27 Sep 2011 09:01:14 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 06:58:19 -0000 On 09/27/2011 01:32 AM, Bill Frantz wrote: > I would add on this topic: > Browsers should refuse to display their highest security UI indicators > if they negotiate a version of TLS with known flaws. This seems like the best strategy to force servers to upgrade. regards, Nikos From juhovh@iki.fi Tue Sep 27 00:01:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8521F8E22 for ; Tue, 27 Sep 2011 00:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0BTbYKarMxT for ; Tue, 27 Sep 2011 00:01:01 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8E21F8E20 for ; Tue, 27 Sep 2011 00:01:01 -0700 (PDT) Received: from mail.visino.fi (88.192.37.90) by jenni1.inet.fi (8.5.133) id 4E7C5E0F002B523C; Tue, 27 Sep 2011 10:03:43 +0300 Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 2B7781FEE1; Tue, 27 Sep 2011 10:03:41 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4E81293A.4000402@extendedsubset.com> Date: Tue, 27 Sep 2011 10:03:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F31D195-9533-4580-8681-8E8FF6610AC3@iki.fi> References: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> <4E81293A.4000402@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 07:01:02 -0000 On Sep 27, 2011, at 4:39 AM, Marsh Ray wrote: > I agree that the current semantics are starting to feel a bit silly. = Support for TLS 1.2 also implies a willingness to speak SSLv3? > Are we expecting to continue this forever? How come support for TLS 1.2 also implies a willingness to speak SSLv3? = I don't see that in the specification. > On 09/26/2011 08:14 PM, Eric Rescorla wrote: > > In an environment where the client could indicate any combination of > > versions, the impact of implementing TLS 1.2 only would be that a > > server which did not support TLS 1.2 would generate an error instead > > of a ClientHello. [ServerHello?] > > > > Since servers are supposed to select the highest common version, I'm > > not sure I see serious difference between these two. >=20 > The difference is that somebody will look at Wireshark and instead of = seeing random disconnects and thinking they're the subject of some = low-level DoS attack, they'll see a bright yellow line that reads: > "TLS Alert: Endpoints support no common protocol version." There is already a protocol_version alert, which is supposed to have = exactly this meaning. If the client sends a lower version than the = lowest supported server version in ClientHello, server replies with = protocol_version alert. If the server sends a lower version than the = lowest supported client version in ServerHello, client replies with = protocol_version alert. Only problem here is that the version = negotiation is broken in implementations, not that it doesn't work in = theory... The problem I believe Martin was trying to point out is a hypothetical = case where a client for example supports TLS 1.1, TLS 1.2 and SSLv3 for = backwards compatibility, but not TLS 1.0. When it connects to a server = which supports SSLv3 and TLS 1.0 only, the server will most likely reply = with TLS 1.0 in ServerHello. Now the client can only reply with = protocol_version to indicate no common protocol version was supported, = even though in fact SSLv3 handshake would have succeeded. Only way to = fix this properly would be to explicitly list all supported versions in = the ClientHello. The suggestion brought up by Eric could make this possibly with only = slight modifications, but then it would effectively override the current = version negotiation. I can easily see a scenario where all = implementations send TLS 1.0 in ClientHello and send all higher = supported versions as cipher suites. That would be ugly, and I hate = abusing the cipher suites for renegotiation and now this, but I have to = admit it would solve a lot of problems... About the current proposal by Eric I have to agree with Martin, it is a = hack that only increases handshake failures without helping in any way = with the current version negotiation problems. Implementing a proposal = like that doesn't make much sense to me. Juho From n.mavrogiannopoulos@gmail.com Tue Sep 27 00:04:58 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D4621F8E20 for ; Tue, 27 Sep 2011 00:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH-taj3WKFRz for ; Tue, 27 Sep 2011 00:04:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39A21F8DFE for ; Tue, 27 Sep 2011 00:04:56 -0700 (PDT) Received: by wyh21 with SMTP id 21so5223654wyh.31 for ; Tue, 27 Sep 2011 00:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pKUiSe87FTfut2IIsL5MbWtVrwBa0U5nXGelppdt5nk=; b=KBSX9z1wibP52EShIO2r4NRSM05m7yrMy/HtVevuPkoukHWHaZCR0edGoxujGkhbVl lqxx7zRPLcU7yNmvOSNfPx1ZxrgPHxPp5Depk516CMIY8uAs1otHw5wPzS/+Y+4sHeb7 qy8+rZRP525liVfqjdhfx2J38Iw2wLKB9QSi0= Received: by 10.227.35.196 with SMTP id q4mr2180782wbd.113.1317107261299; Tue, 27 Sep 2011 00:07:41 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be. [94.225.167.75]) by mx.google.com with ESMTPS id l18sm30888315wbo.23.2011.09.27.00.07.40 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 00:07:40 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E81764A.7050402@gnutls.org> Date: Tue, 27 Sep 2011 09:07:54 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 07:04:58 -0000 On 09/27/2011 01:44 AM, Eric Rescorla wrote: > I've been doing some thinking about how to prevent rollback to > TLS 1.0/SSLv3 from TLS 1.1-capable agents. > > Since there's very little deployment of TLS 1.1+, basically anything > we do now will roll out more or less in parallel with TLS 1.1 deployment, > as long as it's backward compatible.The obvious technique here is to > stuff the relevant indicator in the cipher suites list, since we know that > servers ignore unknown entries there. How about servers that fail on unknown ciphersuites? (they used to exist). If such a thing is proposed there will be no incentive at all to fix the broken servers. I see Bill Frantz solution as a pragmatic one that does not break the protocol (a hack over hack makes the protocol so complicated that in a few years we'll need a clean slate redesign of TLS. Complexity adds security issues rarely solves them.). regards, Nikos From juhovh@iki.fi Tue Sep 27 00:07:53 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7343E21F8D1B for ; Tue, 27 Sep 2011 00:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVl96VhNtLLH for ; Tue, 27 Sep 2011 00:07:53 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id BA75221F8B67 for ; Tue, 27 Sep 2011 00:07:52 -0700 (PDT) Received: from mail.visino.fi (88.192.37.90) by jenni1.inet.fi (8.5.133) id 4E7C5E0F002B708D; Tue, 27 Sep 2011 10:10:28 +0300 Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 31ABF1FEE1; Tue, 27 Sep 2011 10:10:26 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4E8174BA.8060203@gnutls.org> Date: Tue, 27 Sep 2011 10:10:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8174BA.8060203@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 07:07:53 -0000 On Sep 27, 2011, at 10:01 AM, Nikos Mavrogiannopoulos wrote: > On 09/27/2011 01:32 AM, Bill Frantz wrote: >=20 >> I would add on this topic: >> Browsers should refuse to display their highest security UI = indicators >> if they negotiate a version of TLS with known flaws. >=20 > This seems like the best strategy to force servers to upgrade. I agree completely. If the browser vendors just agree to this, SSLv3 and = TLSv1.0 could be phased out gracefully leaving us with TLS 1.1 and TLS = 1.2 only. Since with two versions there cannot be any unsupported = versions in between, it would effectively resolve the mentioned version = negotiation problem in current TLS for the time being. (until new TLS = versions come up) Juho From ynir@checkpoint.com Tue Sep 27 01:23:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F1721F8C67 for ; Tue, 27 Sep 2011 01:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBd0JOgAi-SP for ; Tue, 27 Sep 2011 01:23:23 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15A5021F8C60 for ; Tue, 27 Sep 2011 01:23:22 -0700 (PDT) X-CheckPoint: {4E8195A8-3-1B221DC2-FFFF} 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 p8R8Q3M7016692; Tue, 27 Sep 2011 11:26:03 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 27 Sep 2011 11:26:03 +0300 From: Yoav Nir To: Marsh Ray , "mrex@sap.com" Date: Tue, 27 Sep 2011 11:26:04 +0300 Thread-Topic: [TLS] One approach to rollback protection Thread-Index: Acx87xhMYuDzidUXRPOz04Sp7bF7GA== Message-ID: In-Reply-To: <4E81293A.4000402@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 08:23:24 -0000 On 9/27/11 4:39 AM, "Marsh Ray" wrote: > >I agree that the current semantics are starting to feel a bit silly. >Support for TLS 1.2 also implies a willingness to speak SSLv3? >Are we expecting to continue this forever? You don't have to speak SSLv3, but current semantics do say that you advertise a range. Yes, you are supposed to support the version in the record header, the version in the ClientHello, and everything in between, so you could probably do TLS 1.0 - TLS 1.2, and still interoperate with most of the servers in the world. You could also do 1.1-1.2, but then you're limited to an Internet with about 360 servers. From Nilesh.Tayade@netscout.com Tue Sep 27 01:50:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6E21F8C97 for ; Tue, 27 Sep 2011 01:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwp0iJPws6nC for ; Tue, 27 Sep 2011 01:50:29 -0700 (PDT) Received: from exprod6ob110.obsmtp.com (exprod6ob110.obsmtp.com [64.18.1.24]) by ietfa.amsl.com (Postfix) with SMTP id 2DECF21F8C81 for ; Tue, 27 Sep 2011 01:50:29 -0700 (PDT) Received: from nsmailfe2k3.netscout.com ([12.187.89.175]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKToGO8tHP7x2Ma3u3CGGpTyHy8JETFX8d@postini.com; Tue, 27 Sep 2011 01:53:13 PDT Received: from nsmail.netscout.com ([192.168.39.90]) by nsmailfe2k3.netscout.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Sep 2011 04:53:05 -0400 Received: from [172.16.32.23] ([172.16.32.23]) by nsmail.netscout.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 04:53:05 -0400 Message-ID: <4E818EF3.4090206@netscout.com> Date: Tue, 27 Sep 2011 14:23:07 +0530 From: nilesh Organization: NetScout User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2011 08:53:05.0343 (UTC) FILETIME=[DF1384F0:01CC7CF2] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.800.1017-18410.004 X-TM-AS-Result: No--14.394800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Mailman-Approved-At: Tue, 27 Sep 2011 06:51:30 -0700 Subject: [TLS] Query regarding generating client_write_key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 08:51:44 -0000 Hi, I am new to the TLS/Cryptography and started working on decrypting the packets over SSL/TLS. I have followed the RFC2246, 5246. To start decoding the packets, I need to have symmetric keys (client_write_key/server_write_key). I have the key_block, IV and MAC. As per the rfc: client_write_key = PRF{key_block[32..36], client_random, server_random, some_string}[0..31]; And I have started writing PRF (pseudo-random function) somewhat like: /* input : has 5bytes data i.e. key_block[32..36]; salt1 == client_random, salt2 == server_random, salt = 'A'. */ for (i = 0; i < 2; i++) { MD5_Init(&md5); MD5_Update(&md5, (unsigned char *) &input[0], 3); // MD5_Update(&md5, shasig, 20); MD5_Final((unsigned char *)&md, &md5); SHA1_Init(&sha); SHA1_Update(&sha, pad, i + 1); SHA1_Update(&sha, (unsigned char *) &input[2], 3); SHA1_Update(&sha, salt1, 32); SHA1_Update(&sha, salt2, 32); SHA1_Final(shasig, &sha); } Now, we need to XOR the md and shasig to get the bytes in client_write_key. Queries: 1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be 20bytes. But the key we expect should be 32bytes (iterated the MD5/SHA1 twice for that). How could this be achieved? 2. Any suggestions on if the PRF() is designed somewhere? Pointers on how it could be designed? I tried several ways, but getting the wrong key. Could someone please advice? -- Thanks, Nilesh From simon@josefsson.org Tue Sep 27 07:02:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0021F8C64 for ; Tue, 27 Sep 2011 07:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7GiNjImmDoG for ; Tue, 27 Sep 2011 07:02:53 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id BB33621F8C5D for ; Tue, 27 Sep 2011 07:02:52 -0700 (PDT) Received: from latte.josefsson.org (c-4f92e255.46-3-64736c14.cust.bredbandsbolaget.se [85.226.146.79]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8RE5Q34010657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Sep 2011 16:05:28 +0200 From: Simon Josefsson To: nilesh References: <4E818EF3.4090206@netscout.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110927:nilesh.tayade@netscout.com::DZ/kU5jjuZ0eHZ08:6xtu X-Hashcash: 1:22:110927:tls@ietf.org::aZMTu6ogopu9naW9:JYIS Date: Tue, 27 Sep 2011 16:05:21 +0200 In-Reply-To: <4E818EF3.4090206@netscout.com> (nilesh's message of "Tue, 27 Sep 2011 14:23:07 +0530") Message-ID: <87ty7yt71a.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Query regarding generating client_write_key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 14:02:54 -0000 nilesh writes: > Hi, > > I am new to the TLS/Cryptography and started working on decrypting the > packets over SSL/TLS. > I have followed the RFC2246, 5246. ... > Queries: > 1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be > 20bytes. > But the key we expect should be 32bytes (iterated the MD5/SHA1 twice > for that). How could this be achieved? > 2. Any suggestions on if the PRF() is designed somewhere? Pointers on > how it could be designed? > > I tried several ways, but getting the wrong key. Could someone please > advice? Did you read section 5 of RFC 5246? It explains how the PRF function works. /Simon From dan.winship@gmail.com Tue Sep 27 07:48:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2442321F8514 for ; Tue, 27 Sep 2011 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzbdYzatx3sB for ; Tue, 27 Sep 2011 07:48:29 -0700 (PDT) Received: from mysterion.org (mysterion.org [173.230.128.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C221F8509 for ; Tue, 27 Sep 2011 07:48:29 -0700 (PDT) Received: from desktop.home.mysterion.org (c-76-17-116-213.hsd1.ga.comcast.net [76.17.116.213]) by mysterion.org (Postfix) with ESMTPSA id 3246134E5C; Tue, 27 Sep 2011 10:51:14 -0400 (EDT) Message-ID: <4E81E2E1.3020604@gmail.com> Date: Tue, 27 Sep 2011 10:51:13 -0400 From: Dan Winship User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 14:48:30 -0000 On 09/26/2011 07:44 PM, Eric Rescorla wrote: > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > The natural defense against this attack is to have a "maximum > version" indicator which the client can safely send even to downrev > servers but which upgraded servers can check and will thus allow > downgrade detection. You don't even need to indicate maximum version. The client just needs to indicate "I've downgraded". Clients will never downgrade against a server that implements version negotiation correctly, so if a compliant server sees that flag, it knows there's an attack in progress. -- Dan From n.mavrogiannopoulos@gmail.com Tue Sep 27 08:10:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617BB21F8E5C for ; Tue, 27 Sep 2011 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3A3V7OsUY1G for ; Tue, 27 Sep 2011 08:10:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5DB221F8E5A for ; Tue, 27 Sep 2011 08:10:43 -0700 (PDT) Received: by wwf22 with SMTP id 22so4902634wwf.13 for ; Tue, 27 Sep 2011 08:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4aaw6eYdxn0CiOa0C3b57AAwmeelvBYlproJ+ulA+tI=; b=M24Bv+20cbR2vR3F7LA+wGDuM31S3yCaYtX991fLNv1cunoxVz+atMlHzx3A+OBXwP LIvoiS7Nj27YobzZQ4siKtjPq+JuYaxn+Fjj8NvvPfwlC8BU1bO///BFNET7E7mrrOxq aha1aGHz9IxaRl1JBdpGjgPfPcX2drHE5vD6k= Received: by 10.227.10.146 with SMTP id p18mr4856533wbp.69.1317136400843; Tue, 27 Sep 2011 08:13:20 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be. [94.225.167.75]) by mx.google.com with ESMTPS id fq9sm36167224wbb.15.2011.09.27.08.13.19 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:13:20 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E81E81E.2090404@gnutls.org> Date: Tue, 27 Sep 2011 17:13:34 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: tls@ietf.org References: <4E81E2E1.3020604@gmail.com> In-Reply-To: <4E81E2E1.3020604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:10:45 -0000 On 09/27/2011 04:51 PM, Dan Winship wrote: > On 09/26/2011 07:44 PM, Eric Rescorla wrote: >> http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > >> The natural defense against this attack is to have a "maximum >> version" indicator which the client can safely send even to downrev >> servers but which upgraded servers can check and will thus allow >> downgrade detection. > > You don't even need to indicate maximum version. The client just needs > to indicate "I've downgraded". Clients will never downgrade against a > server that implements version negotiation correctly, so if a compliant > server sees that flag, it knows there's an attack in progress. The problem is that many servers support TLS 1.0 but they are so buggy (e.g. fail when seeing extensions or fail if padding in record packets exceeds the cipher block size) that clients downgrade in order to talk to them. In that case the server would see that as an attack. Adding such a protection could add more compatibility issues. I think the goal should be to eliminate the need for downgrade and use the protocol negotiation of TLS. regards, Nikos From mbadra@gmail.com Tue Sep 27 08:37:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E44A21F8B33 for ; Tue, 27 Sep 2011 08:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHDqCJzzMUum for ; Tue, 27 Sep 2011 08:37:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF4E621F8B32 for ; Tue, 27 Sep 2011 08:37:36 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5393617vcb.31 for ; Tue, 27 Sep 2011 08:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XKB9TEeQ2VbyVA2XWjtBrBcRERXjuhI3y127YyBbI+k=; b=oUfALxMmkQsNcPXkaoBRvE/sQCfP14jYDk9VGIUdI3sqQZ5PLzjDt9clw9DTLoIlu3 W/67YHipIt9ZXPFipsKhVnS8/7fMUHNPeb90D2ogg+LqLjKgqgB0I3rO42PlRY6cUxmL h4nOhIworj6hi8eUxr35rPDFnM1+ImIbzmjNM= MIME-Version: 1.0 Received: by 10.220.189.137 with SMTP id de9mr2089439vcb.171.1317138020182; Tue, 27 Sep 2011 08:40:20 -0700 (PDT) Sender: mbadra@gmail.com Received: by 10.220.176.198 with HTTP; Tue, 27 Sep 2011 08:40:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 17:40:20 +0200 X-Google-Sender-Auth: kiTM8Ud_wsAMwoHSBE5Z0YfiVPU Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=90e6ba53aa32d02b5204adee17c8 Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:37:37 -0000 --90e6ba53aa32d02b5204adee17c8 Content-Type: text/plain; charset=ISO-8859-1 Hi, do the current TLS servers parse all the cipher suites received in the ClientHello? Best regards Badra On Tue, Sep 27, 2011 at 1:44 AM, Eric Rescorla wrote: > I've been doing some thinking about how to prevent rollback to > TLS 1.0/SSLv3 from TLS 1.1-capable agents. > > Since there's very little deployment of TLS 1.1+, basically anything > we do now will roll out more or less in parallel with TLS 1.1 deployment, > as long as it's backward compatible.The obvious technique here is to > stuff the relevant indicator in the cipher suites list, since we know that > servers ignore unknown entries there. > > I've taken an initial crack at a draft for this: > > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --90e6ba53aa32d02b5204adee17c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

do the current TLS servers parse al= l the cipher suites received in the ClientHello?

Best regards
<= div>Badra

On Tue, Sep 27, 2011 at = 1:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
I've been doing some thinking about how= to prevent rollback to
TLS 1.0/SSLv3 from TLS 1.1-capable agents.

Since there's very little deployment of TLS 1.1+, basically anything we do now will roll out more or less in parallel with TLS 1.1 deployment, as long as it's backward compatible.The obvious technique here is to stuff the relevant indicator in the cipher suites list, since we know that<= br> servers ignore unknown entries there.

I've taken an initial crack at a draft for this:
http://svn.resiprocate.org/rep/ietf-dra= fts/ekr/draft-rescorla-tls-version-cs.txt

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

--90e6ba53aa32d02b5204adee17c8-- From matt@mattmccutchen.net Tue Sep 27 08:48:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD5321F8DC8 for ; Tue, 27 Sep 2011 08:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGdCMU9MnN63 for ; Tue, 27 Sep 2011 08:48:20 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id D2E4D21F8D97 for ; Tue, 27 Sep 2011 08:48:20 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 8CF9F51C063 for ; Tue, 27 Sep 2011 08:51:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=fsi6tmeUAf4ItOJxeLnOnuy408djgyrAsdjztxD37c2 3p1Cb2Dpm7ORHob74Q7ykimxu2h4DDfdVuZra3MTjRPG1YkIBBpQ8jfrjXiV+Jmm +g+X1x+55+gO7teqSHFvLVB14lDP31Hc9GtuS8ANLoQeROHJfMTmAPysw0M+RpVM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=DJij+Gm5DFMCsSj72IeA+7KkqGk=; b=QhBkM+dWTQ kaDCs4rYOkPvhtEWTacVu/I/5dr9CYiBWIBP7e47KNXFgKs7XJ/zmBFGXNxVENOi 6iJKTbXt06izP0TSBVnpoAzp0F7J7tAterpTdsqFILeqyhqdqZe0MWbXRPGhjirt 79Qfe09f6bzI++r6kpYarY1a/Hg6TGjss= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 69D4F51C073 for ; Tue, 27 Sep 2011 08:51:06 -0700 (PDT) From: Matt McCutchen To: tls@ietf.org Date: Tue, 27 Sep 2011 08:51:06 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317138667.2975.4.camel@localhost> Mime-Version: 1.0 Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:48:21 -0000 On Mon, 2011-09-26 at 18:19 -0700, Eric Rescorla wrote: > On Mon, Sep 26, 2011 at 5:56 PM, Adam Langley wrote: > > This doesn't really make the deployment of new TLS versions that much > > easier. The client would still have to try 1.2, 1.1, 1.0 etc. What > > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the > > client as if it has advertised 1.2. > > That's certainly a possibility, but now we're actually substituting > the negotiation > mechanism with one based on smuggling it in ciphersuites, which is pretty gross. You've already indicated your willingness to take hacks for better functionality. > Moreover, unless I'm missing something, this leaves the client unable to offer > extensions (since they often cause breakage as well) unless it has fallback, > at which point why not use fallback for version logic as well? > > I see your point about trying sequentially, but I don't think the > situation is that > dire. It's probably reasonable to offer TLS 1.1 or 1.2 and assume that > TLS 1.1/1.2 > stacks do TLS version negotiation properly. If that fails, fall back > aggressively > to SSLv3 or TLS 1.0 with nothing offensive like extensions. > > Or am I missing something? To clarify Adam's response: there are servers that tolerate TLS 1.0 + extensions but not TLS 1.2, and clients would like to use TLS 1.0 against such servers. They can achieve this on a first connection with TLS 1.0 version + extensions + TLS 1.2 SCSV. Without Adam's proposed behavior, clients would need two stages of fallback in order to both use TLS 1.0 with "semitolerant" servers and successfully connect to completely intolerant servers. -- Matt From internet-drafts@ietf.org Tue Sep 27 12:50:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1078721F8FFB; Tue, 27 Sep 2011 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8YVvRUVqPGm; Tue, 27 Sep 2011 12:50:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8966E21F8F7C; Tue, 27 Sep 2011 12:50:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110927195049.10433.56399.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2011 12:50:49 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-dtls-heartbeat-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 19:50:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : Transport Layer Security (TLS) and Datagram Transport La= yer Security (DTLS) Heartbeat Extension Author(s) : Robin Seggelmann Michael Tuexen Michael Williams Filename : draft-ietf-tls-dtls-heartbeat-03.txt Pages : 9 Date : 2011-09-27 This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path maximum transmission unit (PMTU) discovery for DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-03.txt From mrex@sap.com Tue Sep 27 13:30:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EE221F9032 for ; Tue, 27 Sep 2011 13:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdUBI0z24uib for ; Tue, 27 Sep 2011 13:30:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7141921F9031 for ; Tue, 27 Sep 2011 13:30:00 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8RKWdRL026772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 22:32:44 +0200 (MEST) From: Martin Rex Message-Id: <201109272032.p8RKWcOE019726@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 27 Sep 2011 22:32:38 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Sep 26, 11 05:28: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] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 20:30:01 -0000 Eric Rescorla wrote: > > I wrote: > > > > [ciphersuite minor value composed of bitmask] > > Hmm... What's the advantage of something this complicated/expressive, > especially given that there is no way to currently express > "I speak TLS 1.2 but not 1.0"? Having slept over my own proposal (and considering the lack of interop of the original TLS version negotiation demonstrated by the installed base), I would be fine with a small set of simple cipher suite values, starting with TLSv1.0. My primary interests are - reducing the amount of failed TLS handshakes - allow TLS clients without reconnect fallback to propose TLSv1.1 or higher without risk of new interop failures with version intolerant servers or bugs related to RSA premaster secret client_version checks, such as the bug in Win7/Win2008R2 renego. - get protection for the TLS version negotiation for free (for peers that implement this) Our implementation is unconditionally including the rfc5746 renego SCSV in every ClientHello, so I don't see an interop issue with this. Even sending TLS extension (which we do not) seems to be not much of a problem these days. But the number of interop problems that we have noticed ourselves in TLS version negotiation, including incorrect RSA premaster secret client_version checks, is very disappointing. The changes necessary to add TLSv1.1 support to our implementation looks pretty marginal, because it is essentially only the explicit random IVs for TLS cipher suites with block ciphers in CBC mode (plus removing the CBC-padding oracle, but already did that for all protocol versions). But I would really like see a more robust TLSv1.1 negotiation being standardized, because I don't see sending ClientHello.client_version = { 0x03, 0x02 } as a viable option due to the known interop problems for some more years. -Martin From Michael.Tuexen@lurchi.franken.de Tue Sep 27 13:47:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE0921F8C08 for ; Tue, 27 Sep 2011 13:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhrTDBxtCjrj for ; Tue, 27 Sep 2011 13:47:41 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id EE22821F8BD5 for ; Tue, 27 Sep 2011 13:47:40 -0700 (PDT) Received: from [192.168.1.100] (p5481CB9E.dip.t-dialin.net [84.129.203.158]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 260F71C0C0BD6; Tue, 27 Sep 2011 22:50:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 27 Sep 2011 22:50:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F2D6AFB-3F1E-4B6F-A815-7EF1E50DDBA4@lurchi.franken.de> References: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> To: Joe Salowey X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 20:47:42 -0000 On Sep 27, 2011, at 12:10 AM, Joe Salowey wrote: > Working group last call has completed and there were a few minor = revisions suggested. Authors, please submit a revised draft to be = submitted to the IESG. Done. The changes based on comments on the list between the -02 and -03 = version are: * Grammar / spelling. * Some general clarifications in the text. * Clarification of the formulas regarding the padding length * Registry policies changed from Specification Required to Expert Review * Reference to RFC4347 replaced by draft-ietf-tls-rfc4347-bis-06 Robin has updated the patch for OpenSSL which is available at http://sctp.fh-muenster.de/dtls-patches.html to this latest version. While doing that one additional detail was = addressed: When using a reliable transport protocol, TLS/DTLS does not run timers. So it does not make sense to introduce one just for this extension. Therefore the last sentence of section 3 was changed from If no corresponding HeartbeatResponse message has been received after a = user configured amount of time, the DTLS/TLS connection SHOULD be terminated. to If no corresponding HeartbeatResponse message has been received after = some amount of time, the DTLS/TLS connection MAY be terminated by the user. In the OpenSSL implementation a function is provided to figure out if a = HB is in-fight. So the application can check if a HB-Response has been received anytime = it wants and can take the appropriate action. Best regards Michael > Thanks, >=20 > Joe > On Aug 21, 2011, at 10:07 PM, Joe Salowey wrote: >=20 >> This announcement is for the working group last call of = draft-ietf-tls-dtls-heartbeat-02. Please send comments to the list by = September 09, 2011. =20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From joshua.davies.tx@gmail.com Wed Sep 28 09:30:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660931F0C86 for ; Wed, 28 Sep 2011 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktpU0B8aP0dt for ; Wed, 28 Sep 2011 09:30:24 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD871F0C85 for ; Wed, 28 Sep 2011 09:30:24 -0700 (PDT) Received: by yic13 with SMTP id 13so7784225yic.31 for ; Wed, 28 Sep 2011 09:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9GdOPvatwbYUGNCGFdhhlRYLbChVoShIaJOCGYsiGJo=; b=VQuIdnClfc/avXyp2Q0iu8KY2QzOfqTbzgHM6wXDeky/uO38MFehBMmuFn+bglYyur Pf2FEQLTP8m8LbnZQGwBe3jOcJjUXDEanRoNZsRKPlJ1TSr3fs4jo4SZh8CxAHTikPgJ 70ZoorQKLfaJ8/PvflxL4goBrL72evyQbbMUk= MIME-Version: 1.0 Received: by 10.68.27.102 with SMTP id s6mr44998115pbg.43.1317227592139; Wed, 28 Sep 2011 09:33:12 -0700 (PDT) Received: by 10.142.88.9 with HTTP; Wed, 28 Sep 2011 09:33:12 -0700 (PDT) In-Reply-To: <4E818EF3.4090206@netscout.com> References: <4E818EF3.4090206@netscout.com> Date: Wed, 28 Sep 2011 11:33:12 -0500 Message-ID: From: Joshua Davies To: nilesh Content-Type: multipart/alternative; boundary=bcaec520f1c7b7c2be04ae02f265 Cc: tls@ietf.org Subject: Re: [TLS] Query regarding generating client_write_key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 16:30:25 -0000 --bcaec520f1c7b7c2be04ae02f265 Content-Type: text/plain; charset=ISO-8859-1 Are you implementing TLS 1.0/1.1 or TLS 1.2? The PRF changed in 1.2. The PRF is by far the most complex part of the implementation - if you really want to understand it, I'd recommend chapter 6 of my book ; ) However, you can download the companion source code for free from http://media.wiley.com/product_ancillary/16/04709204/DOWNLOAD/920411%20implementing_ssl_gcc.zip; take a look at the ch06/prf.c file. It was written to be as straightforward and self contained as possible, and it includes a standalone main routine that you can use to pass in arbitrary secrets/seeds/labels and see exactly what the PRF function generates. On Tue, Sep 27, 2011 at 3:53 AM, nilesh wrote: > Hi, > > I am new to the TLS/Cryptography and started working on decrypting the > packets over SSL/TLS. > I have followed the RFC2246, 5246. > > To start decoding the packets, I need to have symmetric keys > (client_write_key/server_**write_key). > I have the key_block, IV and MAC. As per the rfc: > > client_write_key = PRF{key_block[32..36], client_random, server_random, > some_string}[0..31]; > And I have started writing PRF (pseudo-random function) somewhat like: > > > /* > input : has 5bytes data i.e. key_block[32..36]; > salt1 == client_random, salt2 == server_random, salt = 'A'. > */ > for (i = 0; i < 2; i++) > { > MD5_Init(&md5); > MD5_Update(&md5, (unsigned char *) &input[0], 3); > // MD5_Update(&md5, shasig, 20); > MD5_Final((unsigned char *)&md, &md5); > > SHA1_Init(&sha); > SHA1_Update(&sha, pad, i + 1); > SHA1_Update(&sha, (unsigned char *) &input[2], 3); > SHA1_Update(&sha, salt1, 32); > SHA1_Update(&sha, salt2, 32); > SHA1_Final(shasig, &sha); > } > > > Now, we need to XOR the md and shasig to get the bytes in client_write_key. > > Queries: > 1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be > 20bytes. > But the key we expect should be 32bytes (iterated the MD5/SHA1 twice for > that). How could this be achieved? > 2. Any suggestions on if the PRF() is designed somewhere? Pointers on how > it could be designed? > > I tried several ways, but getting the wrong key. Could someone please > advice? > > -- > Thanks, > Nilesh > ______________________________**_________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/**listinfo/tls > --bcaec520f1c7b7c2be04ae02f265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are you implementing TLS 1.0/1.1 or TLS 1.2? =A0The PRF changed in 1.2.
The PRF is by far the most complex part of the implementati= on - if you really want to understand it, I'd recommend chapter 6 of my= book ; ) =A0However, you can download the companion source code for free f= rom=A0http://media.wiley.com/product_ancil= lary/16/04709204/DOWNLOAD/920411%20implementing_ssl_gcc.zip; take a loo= k at the ch06/prf.c file. =A0It was written to be as straightforward and se= lf contained as possible, and it includes a standalone main routine that yo= u can use to pass in arbitrary secrets/seeds/labels and see exactly what th= e PRF function generates.

On Tue, Sep 27, 2011 at 3:53 AM, nilesh= <nilesh= .tayade@netscout.com> wrote:
Hi,

I am new to the TLS/Cryptography and started working on decrypting the pack= ets over SSL/TLS.
I have followed the RFC2246, 5246.

To start decoding the packets, I need to have symmetric keys (client_write_= key/server_write_key).
I have the key_block, IV and MAC. As per the rfc:

client_write_key =3D PRF{key_block[32..36], client_random, server_random, s= ome_string}[0..31];
And I have started writing PRF (pseudo-random function) somewhat like:

<snip>
/*
=A0input : has 5bytes data i.e. key_block[32..36];
=A0salt1 =3D=3D client_random, salt2 =3D=3D server_random, salt =3D 'A&= #39;.
*/
for (i =3D 0; i < 2; i++)
{
=A0 =A0 =A0 =A0MD5_Init(&md5);
=A0 =A0 =A0 =A0MD5_Update(&md5, (unsigned char *) &input[0], 3); =A0 =A0 =A0 =A0// MD5_Update(&md5, shasig, 20);
=A0 =A0 =A0 =A0MD5_Final((unsigned char *)&md, &md5);
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0SHA1_Init(&sha);
=A0 =A0 =A0 =A0SHA1_Update(&sha, pad, i + 1);
=A0 =A0 =A0 =A0SHA1_Update(&sha, (unsigned char *) &input[2], 3);<= br> =A0 =A0 =A0 =A0SHA1_Update(&sha, salt1, 32);
=A0 =A0 =A0 =A0SHA1_Update(&sha, salt2, 32);
=A0 =A0 =A0 =A0SHA1_Final(shasig, &sha);
}
</snip>

Now, we need to XOR the md and shasig to get the bytes in client_write_key.=

Queries:
1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be 20by= tes.
But the key we expect should be 32bytes (iterated the MD5/SHA1 twice for th= at). How could this be achieved?
2. Any suggestions on if the PRF() is designed somewhere? Pointers on how i= t could be designed?

I tried several ways, but getting the wrong key. Could someone please advic= e?

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

--bcaec520f1c7b7c2be04ae02f265-- From nico@cryptonector.com Wed Sep 28 13:08:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48311E811A for ; Wed, 28 Sep 2011 13:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBW9BM-co4d0 for ; Wed, 28 Sep 2011 13:08:02 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id E170A11E8107 for ; Wed, 28 Sep 2011 13:08:01 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 7B531B8079 for ; Wed, 28 Sep 2011 13:10:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=lBv+SZo+B9RA+ykGHuBgw15ii5bCmwmRdh3K0SHdPJa2 W+hfxRt8O8GM1UyMw0J/c6kR9q6D8wSaelRmvuWwDbkQwvlzbjqLK/1cK4egabBw ZZFdwNtdHcHmWy+m9zwob9PIZSZyVeSglJKuK1QawWwWKFzHUMhBTA5rel0svAM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=E7m7v1iBMTmYe+HHoMGwWQSlUwQ=; b=NGyFmV31bV7 c24rbn3kKG7/jsPP14L+nZj1WwO1WCn/m3nbEd4L3sOPG+R4eqbTjtozakH3DQk7 CyHmIDbFkUOVr0yJY/cmoORwW2UqW4TW6VhXMbBvnzl+EAPdeaE9e2Fp2a3os7gu ACTFyFOekcx5gAGqWqG3OC1bxe7mn1Bw= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 663CDB8057 for ; Wed, 28 Sep 2011 13:10:12 -0700 (PDT) Received: by pzk37 with SMTP id 37so22327343pzk.9 for ; Wed, 28 Sep 2011 13:10:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr34640166pbq.7.1317240611786; Wed, 28 Sep 2011 13:10:11 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Wed, 28 Sep 2011 13:10:11 -0700 (PDT) Date: Wed, 28 Sep 2011 15:10:11 -0500 Message-ID: From: Nico Williams To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 20:08:02 -0000 A while back Dirk Balfanz proposed something he called "origin bound certificates" and "channel bound cookies". A lighter-weight alternative (i.e., involving no protocol changes) would be nice. Mine: use TLS session IDs as the channel binding. Suppose you have a server with a TLS stack that generates nice, large, [pseudo-]random TLS session IDs, and that supports session resumption (preferably with session tickets). Now have the app's login page bind the TLS session ID into the cookies it generates for the user's application session. So, if a cookie consists of E(app_service_key, username || app_session_data) now make it E(app_service_key, username || app_session_data || tls_session_id). Similarly for other cookie construction techniques. And, critically, change the cookie validation code to check that the TLS session ID of the connection over which a request was received matches the cookie's binding. This is a pure server-side fix for cookie theft attacks, including BEAST. Pre-requisites for this concept to be workable: - client support for TLS session resumption (preferably also with support for session tickets); - server (concentrator!) support for session resumption (preferably also with ...); - TLS session lifetimes matched to cookie lifetimes; - TLS session IDs must be exposed up the TLS and HTTP server-side stack (including any concentrators); - TLS servers that generate large session IDs (32 bytes is the max) using a suitable [P]RNG. Advantages: - purely server-side solution; - does minimal violence to web applications (only cookie generation and validation are affected); - can be deployed at any rate; - no standards-work is required because no protocols are modified (except, perhaps, in the form of a BCP that we might want to issue describing this, and maybe a new header by which the server can advertise that it's channel binding cookies); - some web server frameworks will probably be able to implement channel bound cookies transparently to the server application; - RFC5056-compliant. :) Disadvantages: - not all server stacks will meet the requirements listed above on day 1; - we may need a method for detecting clients that don't support session resumption, if there exist such clients (which I'm sure is true); however, if such detection can be done from, say, the user-agent string sent in an HTTPS request (say, the login form POST), at least we won't have a downgrade attack. Can this work? Or is my feverish imagination misleading me? I think it can work. Yes, there's a concern over collisions in the session ID space, but it's up to 256-bits. It suffices that attackers not have any way to force a TLS session's ID to match another's. So I don't think this is a concern. It'd be nice, too, if the server could advertise to the user-agent that its cookies are channel bound, so the user-agent can apply policy requiring channel bound cookies if it wishes. Nico -- From ynir@checkpoint.com Wed Sep 28 13:58:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B534D1F0D16 for ; Wed, 28 Sep 2011 13:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52kq6uDJBNqp for ; Wed, 28 Sep 2011 13:58:29 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7E1F0D0E for ; Wed, 28 Sep 2011 13:58:27 -0700 (PDT) X-CheckPoint: {4E839821-24-1B221DC2-FFFF} 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 p8SL1CQD003354; Thu, 29 Sep 2011 00:01:12 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 29 Sep 2011 00:01:12 +0300 From: Yoav Nir To: Nico Williams Date: Thu, 29 Sep 2011 00:01:09 +0300 Thread-Topic: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs Thread-Index: Acx+Ib/6j8gGioItRWuzT2PqfUdJcw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 20:58:29 -0000 Hi Nico On Sep 28, 2011, at 11:10 PM, Nico Williams wrote: > - TLS session IDs must be exposed up the TLS and HTTP server-side > stack (including any concentrators); If the server-side HTTP stack has that, why would such an application even = need cookies? Cookies are generally keys to a saved server-side state. If y= ou have access to the TLS session ID, you might as well use that as the key= to the saved server-side state. Yoav= From nico@cryptonector.com Wed Sep 28 14:02:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77B91F0CD2 for ; Wed, 28 Sep 2011 14:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csvx9p4Yjylg for ; Wed, 28 Sep 2011 14:02:17 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3241F0C8B for ; Wed, 28 Sep 2011 14:02:17 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id A0211318070 for ; Wed, 28 Sep 2011 14:05:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=EFIOIpejq9cSJPhh341aIR3au6/PranrjOXV8ruPSSRT qNvDBVAVkmd9wmMYFOtwbRKMoZiFZoWRcHDxh3CpxpkqSIrrV7bVj7iA3ZGL7hnw eI8K3oNPwqov+uB176AJHjB97twgwmCjWYP8YfDkIld1U+MprL+/9pCRy4dzke8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fAqnI0Ak24P+1qHZZ864aDUYaDA=; b=EuB2kgPnfws p5Leop0007jpGtG4iFtB1jLJoK+fIlpP7b676ZtY9WxGotjL2VL15TfXjdBAWzyb h+693BYp+ZQyKxoCfhCrUyZFyPVrbjihucrL8887prKoHqkP4cglB/+oF6aOVZmr dgtffmlBXfaXHCoxwEi7YRxc3vdGIvAQ= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 8278231806D for ; Wed, 28 Sep 2011 14:05:06 -0700 (PDT) Received: by pzk37 with SMTP id 37so22431585pzk.9 for ; Wed, 28 Sep 2011 14:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.56.225 with SMTP id d1mr47298015pbq.109.1317243906176; Wed, 28 Sep 2011 14:05:06 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Wed, 28 Sep 2011 14:05:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 16:05:06 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:02:18 -0000 On Wed, Sep 28, 2011 at 4:01 PM, Yoav Nir wrote: > If the server-side HTTP stack has that, why would such an application eve= n need cookies? Cookies are generally keys to a saved server-side state. If= you have access to the TLS session ID, you might as well use that as the k= ey to the saved server-side state. This is true. And if that's the end state, so much the better. But so much of the web depends on cookies that an incremental solution that doesn't do much violence to the stack would be nice. Nico -- From mike-list@pobox.com Wed Sep 28 14:08:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065AE1F0C7A for ; Wed, 28 Sep 2011 14:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPAIfd78uf-e for ; Wed, 28 Sep 2011 14:08:02 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1671F1F0C73 for ; Wed, 28 Sep 2011 14:08:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 52B4978FB; Wed, 28 Sep 2011 17:10:49 -0400 (EDT) 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=vmG30h8YidFl IiBNR9c1HZvRcT4=; b=QqNw90ERf1iiiHmsyBi2kSb6z1fseRiPdKYJZ6y16BJ3 Wk3YCx0DKLhw4LScZV6AUcj+eQNXI21ZHzhTwuzVUoelPox6wpmsoh631Chs5p/K PE493mZGO48yqpCAmiOQYEDAlmKTwxpGAGZ0wFTfxWT7SgjRINQ1fyhkM5K/fwE= 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=lzuTpN lszdVjQQm4hb2i/mg1JKfzeajTdkkz7YsVPM1EvgZDaLAj1kRswVOnQYPX8K17+P m9blIL1XTpoD1e0DlHCPY2OPsyqJNczVbntzbZfnwGDq3YXIVaX0Q2SEhcvIGADN h56K3cWdWwViFzvLlCcVsouJu70rOjQpYgNas= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4B94678FA; Wed, 28 Sep 2011 17:10:49 -0400 (EDT) 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 9709E78F9; Wed, 28 Sep 2011 17:10:48 -0400 (EDT) Message-ID: <4E838D57.4050303@pobox.com> Date: Wed, 28 Sep 2011 14:10:47 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 56D39DC8-EA16-11E0-9521-65B1DE995924-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:08:09 -0000 I haven't gone through this in detail, but one problem I see is that it is the client that chooses the session ID for a resumed session when a session ticket is used. In fact the first (full) handshake doesn't even have a session ID! Of course the server can stick whatever identifiers it wants in the ticket (since it is opaque to the client), so this might not be a big deal. Mike Nico Williams wrote: > A while back Dirk Balfanz proposed something he called "origin bound > certificates" and "channel bound cookies". A lighter-weight > alternative (i.e., involving no protocol changes) would be nice. > Mine: use TLS session IDs as the channel binding. > > Suppose you have a server with a TLS stack that generates nice, large, > [pseudo-]random TLS session IDs, and that supports session resumption > (preferably with session tickets). Now have the app's login page bind > the TLS session ID into the cookies it generates for the user's > application session. > > So, if a cookie consists of E(app_service_key, username || > app_session_data) now make it E(app_service_key, username || > app_session_data || tls_session_id). Similarly for other cookie > construction techniques. > > And, critically, change the cookie validation code to check that the > TLS session ID of the connection over which a request was received > matches the cookie's binding. > > This is a pure server-side fix for cookie theft attacks, including BEAST. > > Pre-requisites for this concept to be workable: > > - client support for TLS session resumption (preferably also with > support for session tickets); > - server (concentrator!) support for session resumption (preferably > also with ...); > - TLS session lifetimes matched to cookie lifetimes; > - TLS session IDs must be exposed up the TLS and HTTP server-side > stack (including any concentrators); > - TLS servers that generate large session IDs (32 bytes is the max) > using a suitable [P]RNG. > > Advantages: > > - purely server-side solution; > - does minimal violence to web applications (only cookie generation > and validation are affected); > - can be deployed at any rate; > - no standards-work is required because no protocols are modified > (except, perhaps, in the form of a BCP that we might want to issue > describing this, and maybe a new header by which the server can > advertise that it's channel binding cookies); > - some web server frameworks will probably be able to implement > channel bound cookies transparently to the server application; > - RFC5056-compliant. :) > > Disadvantages: > > - not all server stacks will meet the requirements listed above on day 1; > - we may need a method for detecting clients that don't support > session resumption, if there exist such clients (which I'm sure is > true); however, if such detection can be done from, say, the > user-agent string sent in an HTTPS request (say, the login form POST), > at least we won't have a downgrade attack. > > Can this work? Or is my feverish imagination misleading me? I think > it can work. > > Yes, there's a concern over collisions in the session ID space, but > it's up to 256-bits. It suffices that attackers not have any way to > force a TLS session's ID to match another's. So I don't think this is > a concern. > > It'd be nice, too, if the server could advertise to the user-agent > that its cookies are channel bound, so the user-agent can apply policy > requiring channel bound cookies if it wishes. > > Nico From yngve@opera.com Wed Sep 28 14:14:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ADE21F8DD9 for ; Wed, 28 Sep 2011 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2bjM39N+JBp for ; Wed, 28 Sep 2011 14:14:56 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0921F8DD8 for ; Wed, 28 Sep 2011 14:14:55 -0700 (PDT) Received: from lessa-ii.oslo.os (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 p8SLHccX026190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Sep 2011 21:17:41 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "Eric Rescorla" References: Date: Wed, 28 Sep 2011 23:17:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: User-Agent: Opera Mail/10.62 (Win32) Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:14:56 -0000 Hi, I am not sure I like this proposal, for several reasons: - It does not protect against downgrades when connecting to older servers. (rather impossible to do that, of course) - As noted, it is not protected against a compromised handshake integrity function of an older version, but I guess the handshake version could be changed in such a case. - Forward compatibility. How does a X-year old server that support TLS 1.2 understand that that new cipher suite code point is not some new cipher it does not support, but an indication that the client support TLS 1.5? The codepoints would have to not just be predictable, but the codepoints would also have to work for TLS NG using protocol version 4.1. How far ahead do we reserve codepoints, how much of the ciphersuite codepoint space will this eat up? Or do we assume that any TLS 1.2+ server is version and extension tolerant, so TLS 1.2 is the highest version we will ever need to assign a code point for? - There is no way (at least in the draft) for the client to know that the server understands the SCSV, and processed it correctly. And I can see no possibility expect requiring the server to return a special extension signaling that, similar to the requirement for the Renego SCSV. - How easy would it be for a server or client implementor to get it wrong? - How does the server tell the client that it should always negotiated with the highest supported version when connecting? The server may send a fatal error, but it does not really tell the client what is wrong, or that it should be trying its highest supported version. IMO The best way to stop version rollbacks occurring is to not allow them, at all. Unfortunately, however, for a time it will still be necessary, for interoperability reasons, to allow fallbacks if the server is intolerant. That means finding, or declaring, that certain indications from the server, protected by the handshake hash, means that the server will not willingly require rollback to an older version. This could be either a new extension (which runs up against the extension intolerance problem, and the possibility of an attacker faking the intolerance) or we could use an existing extension to indicate this. As I have mentioned earlier, I think the second option is best, and that I think it already exists in the form of the Renego Indication (RI) Extension. My suggestion is that when a client detects that a server have the RI extension, it MUST only use the highest configured version when connecting to that server. If a server not known to have RI triggers a fallback, and turns out to have RI support, it should immediately start using the highest supported version, and not fall back to an older version if the negotiation fails. Sure, this is a bit of a hack, too, but it is one that can be deployed quickly (60+% of servers already support RI) without any further server updates, it need only be implemented client side, and the current server failure rate is less than 0.1% of all tested servers when signalling TLS 1.1, TLS 1.2, or extensions (which is the major part of the failures), totaling only a few hundred sites in my sample (and I think these will be straightened out in short order once they start failing in all clients). Any server that would implement a check for these SCSVs would (or should) also already: - Be extension tolerant - Be version tolerant - Implement the RI extension If the RI is used as an indication of tolerance then the only way an attacker would be able to force a downgrade would be if he is able to fake the Finished message, a problem that this document admits also exists for the SCSV suggestion. I therefore think using RI as an indicator will be a better solution (there is no perfect solution, unfortunately) On Tue, 27 Sep 2011 01:44:18 +0200, Eric Rescorla wrote: > I've been doing some thinking about how to prevent rollback to > TLS 1.0/SSLv3 from TLS 1.1-capable agents. > > Since there's very little deployment of TLS 1.1+, basically anything > we do now will roll out more or less in parallel with TLS 1.1 deployment, > as long as it's backward compatible.The obvious technique here is to > stuff the relevant indicator in the cipher suites list, since we know > that > servers ignore unknown entries there. > > I've taken an initial crack at a draft for this: > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From marsh@extendedsubset.com Wed Sep 28 14:17:55 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664CA21F8E11 for ; Wed, 28 Sep 2011 14:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My0biCZKjHHS for ; Wed, 28 Sep 2011 14:17:54 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68D5421F8E0C for ; Wed, 28 Sep 2011 14:17:54 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1R91YY-000NkF-Jy; Wed, 28 Sep 2011 21:20:42 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C15446067; Wed, 28 Sep 2011 21:20:39 +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: U2FsdGVkX19WGKYwwHbW9kBCTiAN2RaOqnKH0tx+7aA= Message-ID: <4E838FA6.6090203@extendedsubset.com> Date: Wed, 28 Sep 2011 16:20:38 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:17:55 -0000 On 09/28/2011 04:01 PM, Yoav Nir wrote: > > If the server-side HTTP stack has that, why would such an application > even need cookies? Cookies are generally keys to a saved server-side > state. If you have access to the TLS session ID, you might as well > use that as the key to the saved server-side state. It seems that most web apps are developed using some type of framework. These frameworks are often optimized for the plain-HTTP case. Often HTTPS, and the certs, etc. aren't brought in until somewhat late in the development process. Apps get developed using cookies, then (occasionally) deployed with TLS as an encrypted tunnel for security. So we end up with all these insufficiently-bound channels needing channel binding. When apps are developed with using TLS from the beginning, the result ends up looking much more integrated. But we also need to look for solutions that benefit all the other apps out there. - Marsh From mrex@sap.com Wed Sep 28 15:54:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF225E8004 for ; Wed, 28 Sep 2011 15:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3DaBsvPaS7I for ; Wed, 28 Sep 2011 15:54:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0012B5E8003 for ; Wed, 28 Sep 2011 15:54:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8SMv6GT009969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 00:57:06 +0200 (MEST) From: Martin Rex Message-Id: <201109282257.p8SMv5P1019589@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 29 Sep 2011 00:57:05 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Sep 28, 11 11:17: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 Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 22:54:20 -0000 Yngve N. Pettersen wrote: > > I am not sure I like this proposal, I'm very interested in a modified (=interop-improving) version of this proposal. > for several reasons: > > - It does not protect against downgrades when connecting to older servers. > (rather impossible to do that, of course) This is no reason for, but also not an issue against it. > > - As noted, it is not protected against a compromised handshake integrity > function of an older version, but I guess the handshake version could be > changed in such a case. The existing TLS version negotiation can not protect against that either, so this is not an issue against the proposal. > > - Forward compatibility. How does a X-year old server that support TLS 1.2 > understand that that new cipher suite code point is not some new cipher it > does not support, but an indication that the client support TLS 1.5? The > codepoints would have to not just be predictable, but the codepoints would > also have to work for TLS NG using protocol version 4.1. How far ahead do > we reserve codepoints, how much of the ciphersuite codepoint space will > this eat up? Or do we assume that any TLS 1.2+ server is version and > extension tolerant, so TLS 1.2 is the highest version we will ever need to > assign a code point for? I do _not_ want to retire the original TLS version negotiation, just like to see an alternative "hinting" being standardized to accomodate a ~10 year transition period to get over TLS version-related interop problems that exist in today's installed base. The one thing that I want to see *RETIRED* by this proposal (and all future updates/version of the TLS protocol) is client_version check on the RSA premaster secret, because of the bugs in the installed base. Assuming that the TLS WG produces at most 1 new TLS protocol version every 2 years, and a 10 year transition period, SCSV values for TLSv1.0 -> TLSv1.2 -> TLSv1.7 ought to be sufficient. > > - There is no way (at least in the draft) for the client to know that the > server understands the SCSV, and processed it correctly. And I can see no > possibility expect requiring the server to return a special extension > signaling that, similar to the requirement for the Renego SCSV. The natural place for the server response is ServerHello.server_version, an element that exists in that PDU even in SSLv3. Whether the server supports the SCSV is only interesting when the SCSV is higher than ClientHello.client_version AND the server supports a protocol version higher than ClientHello.client_version--and that situation can be easily determined from the ServerHello.server_version value. > > - How easy would it be for a server or client implementor to get it wrong? Looking at the varying interpretations of what value the client_version in RSA premaster secret should be checked against and the age of the implementations that got this wrong -- EASY, I assume. But if you take that as a measure, we would have to shut down the IETF. If there is any hope at all (and I defy to give up that hope), let's try to be clearer than the existing spec on _all_ details of the version negotiation ("nanny spec"), and see how it works out. Compared to rfc5746 renego, this proposal is "simple" on my scorecard. > > - How does the server tell the client that it should always negotiated > with the highest supported version when connecting? The server may send a > fatal error, but it does not really tell the client what is wrong, or that > it should be trying its highest supported version. The server does not do that. The idea behind this proposal is that the client can propose his highest supported (or actually the highest the client is able and willing to use) TLS protocol version with no ill side effects on the initial ClientHello. There are _no_ requirements to persist any knowledge for future connections. That is quite similar to the idea behind the rfc5746 renego SCSV. Whether and when a TLS client sends version higher than TLSv1.0 in ClientHello.client_version is entirely up to the client. We are _not_ suggesting to clients to change what they are currently doing here. In addition, I do _not_ know which of these ClientHellos is best: 1. no TLSext, Record.version = 0x03,0x00, ClientHello.version = 0x03,0x00 2. no TLSext, Record.version = 0x03,0x00, ClientHello.version = 0x03,0x01 3. no TLSext, Record.version = 0x03,0x01, ClientHello.version = 0x03,0x01 4. SSL version 2 CLIENT-HELLO.version = 0x03,0x00 5. SSL version 2 CLIENT-HELLO.version = 0x03,0x01 And would personally not recommend one over the other for clients that have no reconnect fallback facility. > > IMO The best way to stop version rollbacks occurring is to not allow them, > at all. Unfortunately, however, for a time it will still be necessary, for > interoperability reasons, to allow fallbacks if the server is intolerant. > > That means finding, or declaring, that certain indications from the > server, protected by the handshake hash, means that the server will not > willingly require rollback to an older version. What I am seeing is that an increasing number of TLS clients *IS* using reconnect fallbacks (all modern Browsers seem to do it), and the reasons why they need to do them. TLS version intolerance and non-conforming RSA premaster secret client_version checks is a significant problem. TLS extension intolerance is another, but for TLS clients that do not send TLS extensions at all, this does not matter at all. > > This could be either a new extension (which runs up against the extension > intolerance problem, and the possibility of an attacker faking the > intolerance) or we could use an existing extension to indicate this. Using a TLS extension uses not only more bytes on the wire and is harder to implement, it can not be used in any of the 5 cases above, so it is not a practical alternative. > > As I have mentioned earlier, I think the second option is best, and that I > think it already exists in the form of the Renego Indication (RI) > Extension. > > My suggestion is that when a client detects that a server have the RI > extension, it MUST only use the highest configured version when connecting > to that server. If a server not known to have RI triggers a fallback, and > turns out to have RI support, it should immediately start using the > highest supported version, and not fall back to an older version if the > negotiation fails. I strongly disagree. A negotiation that will make the handshake fail or require two handshakes instead of making the handshake succeed with the desired result is not a negotiation, but a dirty hack -- even if it uses elements of protocol PDUs "appropriately" and exactly as the original design intended. TLS extension RI can not be used to repair the TLS version negotiation which happens on the server side while parsing ClientHello and creating ServerHello. For this to work, the client must convey the TLS versions it supports within ClientHello, in a fashion that upsets close to zero of the installed base of servers and in a place that exists in all PDUs to which the existing TLS clients with reconnect fallbacks are willing to fallback to in case of unexpected connection closures by the server. Only in the latter case that band aid will be able to protect the TLS version negotiation. -Martin From nico@cryptonector.com Wed Sep 28 16:03:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1611E8120 for ; Wed, 28 Sep 2011 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoPlyI6CAVfO for ; Wed, 28 Sep 2011 16:03:23 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 69FCF11E8091 for ; Wed, 28 Sep 2011 16:03:23 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 01C5059806A for ; Wed, 28 Sep 2011 16:06:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xQgpw3++kAJEzWwbDmZgyrGKPyugVa7KTX+VrA0/klDp InEKb3Umd2J3n6VnzfWXX3VT3frDd+sQre65Wr3EI4PDy6iEaM/m7hPMKns1lI+G WOMxu/JTNjS3lT4OxkW1TkjWKMO8VDNuINZgswxVhiv3CVfuWOXuAnn5E7zGqE8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fKatTTgAg0FS2A3njBhDrpeV7h0=; b=VEK9QfQzQu8 +9v3XCvtIny6DEroQnabUUEKoa6ZH4SkYUv3O3ee/Bl9yH4iykUZCelqN+f4cq6c Wc3Z3mGLuBdQwM+QGzSpLJX3RYPGsD6rFMD3XmqPMKWcN1Q2UMXHL9WBImTCUaIH /7hpWwPIgqjTDblz4ZOAhs24lf6abRPo= Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 83CEA598085 for ; Wed, 28 Sep 2011 16:05:46 -0700 (PDT) Received: by fxd18 with SMTP id 18so1234986fxd.31 for ; Wed, 28 Sep 2011 16:05:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.103 with SMTP id d7mr21703944pbm.24.1317251143859; Wed, 28 Sep 2011 16:05:43 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Wed, 28 Sep 2011 16:05:43 -0700 (PDT) In-Reply-To: <4E838D57.4050303@pobox.com> References: <4E838D57.4050303@pobox.com> Date: Wed, 28 Sep 2011 18:05:43 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 23:03:24 -0000 On Wed, Sep 28, 2011 at 4:10 PM, Michael D'Errico wro= te: > I haven't gone through this in detail, but one problem I see is > that it is the client that chooses the session ID for a resumed > session when a session ticket is used. =C2=A0In fact the first (full) > handshake doesn't even have a session ID! > > Of course the server can stick whatever identifiers it wants in > the ticket (since it is opaque to the client), so this might not > be a big deal. At first glance this is a real problem, but in fact, it makes no sense for the TLS server to report any session ID selected by the client -- whatever security value a TLS session ID might have had before RFC4507, it'd have none now. However, precisely because of this, what the server should do is substitute, in any APIs, a server-generated session ID stored in the ticket. The session ID that goes on the wire is pretty much irrelevant (though it's always possible that some application protocol references TLS session IDs on the wire, I rather doubt this). This would mean, possibly, changing TLS server implementations that support RFC4507, which is less advantageous than I'd hoped for. Nico -- From tom@ritter.vg Wed Sep 28 16:31:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6187511E8153 for ; Wed, 28 Sep 2011 16:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12cCbNwFktdy for ; Wed, 28 Sep 2011 16:31:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B723F11E8088 for ; Wed, 28 Sep 2011 16:31:45 -0700 (PDT) Received: by yxt33 with SMTP id 33so129016yxt.31 for ; Wed, 28 Sep 2011 16:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=joo9zcS47uSFHwrcIDqGgX2t1Oz7kAZ1GWTVxc5mOfA=; b=hVFTkY3KfYjYEppf9MDU+24+CXjRFUB7+rYFZripiV3wQFN5O7pjqIEiVpmydQ7kzY WD+FSWLcwI3fm2F7U8Jg63gRjPL6cCfxYXKY4OoQvOQ/MQEzGMfExZ6LW+sreh4HUQKL F2p0etPLM8M/MQYz+iyQC+741qiyr4uOaIECI= MIME-Version: 1.0 Received: by 10.68.33.163 with SMTP id s3mr45916020pbi.10.1317252874885; Wed, 28 Sep 2011 16:34:34 -0700 (PDT) Received: by 10.142.165.21 with HTTP; Wed, 28 Sep 2011 16:34:34 -0700 (PDT) Received: by 10.142.165.21 with HTTP; Wed, 28 Sep 2011 16:34:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 19:34:34 -0400 Message-ID: From: Tom Ritter To: tls@ietf.org Content-Type: multipart/alternative; boundary=bcaec520ecd3afdb1804ae08d593 Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 23:31:46 -0000 --bcaec520ecd3afdb1804ae08d593 Content-Type: text/plain; charset=ISO-8859-1 I don't think this would work in the (common) case of ssl accelerators/forwarders and reverse proxies. The app just sees HTTP, there's no ssl from the point of view of the framework/code a developer wrote. -tom --bcaec520ecd3afdb1804ae08d593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I don't think this would work in the (common) case of ssl accelerato= rs/forwarders and reverse proxies.=A0 The app just sees HTTP, there's n= o ssl from the point of view of the framework/code a developer wrote.

-tom

--bcaec520ecd3afdb1804ae08d593-- From nico@cryptonector.com Wed Sep 28 17:23:14 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0011E80FF for ; Wed, 28 Sep 2011 17:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo-zSJsB8bGx for ; Wed, 28 Sep 2011 17:23:13 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF211E8155 for ; Wed, 28 Sep 2011 17:23:13 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 07B38360065 for ; Wed, 28 Sep 2011 17:26:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=jv+UXXMUBDVlwRCvJcLXNufRMlVYUtSm6/mZXA8H/DmJ VYe7GWj+RkKb9TMKhZqCvpahBzykuCBuM6H8LU4jjeb3pqBzojO57DBUBtjMDWHN kIZKK/BHs5hFYzZrYylmHt7PMX6UuWMLRoxfdP5xMaFLF2arQIjQIvWsn9LSOaY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=dp/z2v2CdlW+6vDxO6ApFXb+5r4=; b=VcLsZjtL2/s KVpznCPLE7/UKltQpe2azRw26k2RbxMI7cc3vMbCiLeyCReq38e0FSXxYXZE4WI3 JhNc3hZ6PWykyQzgqLwBQzbV4NOQ006b0Zv4tJoWr77b22MRPYkQgZBSumMNp3Iy PuD0TBdsaCAHk1KJDa/Pan8h5JDcP1WU= Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id D9A37360064 for ; Wed, 28 Sep 2011 17:26:02 -0700 (PDT) Received: by iaby26 with SMTP id y26so81321iab.31 for ; Wed, 28 Sep 2011 17:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.103 with SMTP id d7mr22090114pbm.24.1317255962308; Wed, 28 Sep 2011 17:26:02 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Wed, 28 Sep 2011 17:26:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Sep 2011 19:26:02 -0500 Message-ID: From: Nico Williams To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 00:23:14 -0000 On Wed, Sep 28, 2011 at 6:34 PM, Tom Ritter wrote: > I don't think this would work in the (common) case of ssl > accelerators/forwarders and reverse proxies.=C2=A0 The app just sees HTTP= , > there's no ssl from the point of view of the framework/code a developer > wrote. They generally add headers to a request, and communicate details of the TLS connection via those headers. For example: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_conf= iguration_guide_10_0_0/ltm_ssl_profiles.html (search for "header"). Nico -- From mrex@sap.com Wed Sep 28 19:19:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC1B1F0C79 for ; Wed, 28 Sep 2011 19:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.062 X-Spam-Level: X-Spam-Status: No, score=-10.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKqOjYG3meMu for ; Wed, 28 Sep 2011 19:19:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3451F0C4B for ; Wed, 28 Sep 2011 19:19:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8T2MQwm003232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 04:22:26 +0200 (MEST) From: Martin Rex Message-Id: <201109290222.p8T2MP4j000987@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 29 Sep 2011 04:22:25 +0200 (MEST) In-Reply-To: <201109282257.p8SMv5P1019589@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 29, 11 00:57: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 Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 02:19:39 -0000 Martin Rex wrote: > > Yngve N. Pettersen wrote: > > > > - How easy would it be for a server or client implementor to get it wrong? > > Looking at the varying interpretations of what value the client_version > in RSA premaster secret should be checked against and the age of the > implementations that got this wrong -- EASY, I assume. > > But if you take that as a measure, we would have to shut down the IETF. > > If there is any hope at all (and I defy to give up that hope), let's > try to be clearer than the existing spec on _all_ details of the > version negotiation ("nanny spec"), and see how it works out. > > Compared to rfc5746 renego, this proposal is "simple" on my scorecard. The real issue is not whether an implementor gets something wrong (which can happen to every human being), but whether the implementor ships an incorrect implementation that would have been caught by sensible interop testing prior to shipment. Doing a superficial, black-box interop testing with all default settings is not much proof of anything and regularly insufficient. Some amount of testing methodology is advisable. (Maybe the IESG should require description of suitable interop test scenarios in protocol specifications--or an option to be removed from a spec?) For complex entire protocols, testing all possible combinations of options results in a combinatorial explosion (cartesian product of all options) and is frequently quite unpractical. But for testing individual protocol options (and negotiation thereof) for interop, a cartesian product may be quite practical _and_ necessary to get any meaningful results. I believe that the TLS version negotiation is a protocol option where a more thorough interop testing is fairly practical and extremely valuable. Basic complexity: 1. max client TLS version > max server TLS version 2. max client TLS version == max server TLS version 3. max client TLS version < max server TLS version Additional complexity: perform a renegotiation after (1), (2), (3). To interop test the original TLS version negotiation (i.e. Record.version, ClientHello.client_version and RSA PremasterSecret.client_version) the prerequisite for full coverage is that both implementations have at least two protocol versions in common. common support for SSLv3&TLSv1.0 is already sufficient for a meaningful interop test! One of (1), (2), (3) is going to be the result of the default install. The other two must be created by tweaking the configuration of TLS client or TLS server or both (enabling or disabling protocol versions) Example: interop testing openssl-1.0.0d client and and Win7+IIS 7.5 server default config: openssl-1.0.0d implements SSLv3/TLSv1.0, offers TLSv1.0 default config: Win7 implements SSLv3->TLSv1.2, TLSv1.2 disabled Configure IIS 7.5 to request a client certificate (in order to have renegotiation covered by the interop test) initial test after default install represents scenario (3) above. openssl s_client -connect win7iis:443 -no_ssl2 [--> ClientHello.client_version=TLSv1.0...] [<-- ServerHello.server_version=TLSv1.0...] [... initial handshake succeeds...] GET / HTTP/1.0 [<-- HelloRequest] [--> ClientHello.client_version=TLSv1.0...] [<-- ServerHello.server_version=TLSv1.0...] [...renegotiation handshake succeeds...] [...server reply for / ...] In order to test scenario (1) and (2), disable protocol versions TLSv1.0, TLSv1.1 and TLSv1.2 for Server of the SCHANNEL Security Provider on the Win7/IIS machine and reboot. testing scenario (1) from above: openssl s_client -connect win7iis:443 -no_ssl2 [--> ClientHello.client_version=TLSv1.0...] [<-- ServerHello.server_version=SSLv3...] [... initial handshake succeeds...] GET / HTTP/1.0 [<-- HelloRequest] [--> ClientHello.client_version=SSLv3...] [<-- ServerHello.server_version=SSLv3...] [--> ClientKeyExchange+ChangeCipherSpec+Finished] ***** Win7/IIS-7.5 unexpectedly closes network connection. testing scenario (2) from above: openssl s_client -connect win7iis:443 -no_ssl2 -ssl3 [--> ClientHello.client_version=SSLv3...] [<-- ServerHello.server_version=SSLv3...] [... initial handshake succeeds...] GET / HTTP/1.0 [<-- HelloRequest] [--> ClientHello.client_version=SSLv3...] [<-- ServerHello.server_version=SSLv3...] [...renegotiation handshake succeeds...] [...server reply for / ...] The unexpected termination of the network connection for interop scenario (1) indicates a TLS version negotiation problem. If you retry scenario (1) with other TLS/Web Servers, there is no such interop problem. Even Windows2003/IIS 6.0 works just fine in the same situation. The interop problem with Win7/IIS-7.5 appears like an incorrect check on the RSA premaster secret client_version on the renegotiation handshake. Win7 SChannel appears to check against ClientHello.client_version of the initial TLS handshake, while it ought to check (if at all) against the ClientHello.client_version of the current TLS handshake. This interop problem shows in exactly the same fashion when I use an openssl-0.9.7d (17-Mar-2004) client, such as included in SLES-9sp3. (btw. have I messed around too much with my Win7 machine, or does IIS-7.5 really _not_ have insecure renegotiation disabled by default?). An alternative TLS version negotiation scheme through SCSV for TLSv1.0 and above) results in a few more relevant test scenarios, as does additional support for TLSv1.1 and TLSv1.2. But I believe the interop testing effort is still fairly manageable. Would it be too much to ask implementors for interop-testing some 3 to 8 scenarios before shipping an implementation of the alternative TLS version negotiation scheme, to ensure that everyone gets this right before shipping this time? -Martin From mrex@sap.com Wed Sep 28 19:39:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B945C1F0D20 for ; Wed, 28 Sep 2011 19:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.063 X-Spam-Level: X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-QueSkU1Go0 for ; Wed, 28 Sep 2011 19:39:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 06F511F0D1E for ; Wed, 28 Sep 2011 19:39:02 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8T2fqKh006229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 04:41:52 +0200 (MEST) From: Martin Rex Message-Id: <201109290241.p8T2fp7J002311@fs4113.wdf.sap.corp> To: tom@ritter.vg (Tom Ritter) Date: Thu, 29 Sep 2011 04:41:51 +0200 (MEST) In-Reply-To: from "Tom Ritter" at Sep 28, 11 07:34:34 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] Addressing cookie theft (think BEAST) with channel bound X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 02:39:03 -0000 Tom Ritter wrote: > > I don't think this would work in the (common) case of ssl > accelerators/forwarders and reverse proxies. The app just sees HTTP, > there's no ssl from the point of view of the framework/code a developer > wrote. +1 I also do *NOT* want to see any server-side apps to mess/interfere with TLS session cache management (size and lifetime) on my server or on whichever backend border component (accelerator/forwarder/rev.proxy) the SSL session is "first opened". There is also no guarantee that all client components, that are part of an application client infrastructure and consciously sharing HTTP cookies, are accessing the same TLS client implementation and sharing the TLS session cache. -Martin From dispensa@phonefactor.com Wed Sep 28 20:06:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6081F0D3F for ; Wed, 28 Sep 2011 20:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC7+9yE5+BTQ for ; Wed, 28 Sep 2011 20:06:15 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with SMTP id 99CF01F0C3E for ; Wed, 28 Sep 2011 20:06:15 -0700 (PDT) Received: from pos-exch1.corp.positivenetworks.net ([204.13.120.8]) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKToPhSnIay5o9rqenfBQK4c7OVGgZAZth@postini.com; Wed, 28 Sep 2011 20:09:05 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: Wed, 28 Sep 2011 22:08:59 -0500 Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E061207044831@pos-exch1.corp.positivenetworks.net> In-Reply-To: <201109290241.p8T2fp7J002311@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Addressing cookie theft (think BEAST) with channel bound Thread-Index: Acx+UV20NXZ1GLFcSOW+3Ve2lvFE6wAAzFHg References: from "Tom Ritter" at Sep 28, 11 07:34:34 pm <201109290241.p8T2fp7J002311@fs4113.wdf.sap.corp> From: "Steve Dispensa" To: Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 03:06:16 -0000 > Martin Rex wrote: > > Tom Ritter wrote: > > > > I don't think this would work in the (common) case of ssl > > accelerators/forwarders and reverse proxies. The app just sees HTTP, > > there's no ssl from the point of view of the framework/code a developer > > wrote. >=20 > +1 >=20 > I also do *NOT* want to see any server-side apps to mess/interfere with > TLS session cache management (size and lifetime) on my server or on > whichever backend border component (accelerator/forwarder/rev.proxy) > the SSL session is "first opened". >=20 > There is also no guarantee that all client components, that are part > of an application client infrastructure and consciously sharing > HTTP cookies, are accessing the same TLS client implementation and > sharing the TLS session cache. >=20 > -Martin Apart from this objection, how would this proposal work with expiring (long-duration) cookies? There are plenty of apps with "remember me" checkboxes. But regarding the hardware accelerators, to whatever extent this idea is valid going directly to a server, they would be able to apply the same binding themselves without the cooperation of either server or client. Other problems have been noted, but accelerators don't represent a critical problem. I like the thinking in this idea, though. I wonder if there is a meaningful subset of cases for which this would work, or if Martin's concerns vis-a-vis the client side are fatal. From n.mavrogiannopoulos@gmail.com Wed Sep 28 23:35:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B73C21F8D50 for ; Wed, 28 Sep 2011 23:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyJ-yP5MAI1z for ; Wed, 28 Sep 2011 23:35:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B24321F8D56 for ; Wed, 28 Sep 2011 23:35:06 -0700 (PDT) Received: by wwf22 with SMTP id 22so336999wwf.13 for ; Wed, 28 Sep 2011 23:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4Scc93DCqekRPCJN4lsloJy7vG14r5FXOFb+4C7jbu8=; b=DDBS/yIlJHVaSDUHNoPbvZVy2e0Hw7yEWON3Dmt8czbguBzr9nUKNejQHnHS0/TizP YrfZ2kVMb9xj6tNtd3LKaI/YXHtBBPXwVjh9867HlNzkc++vUS8cx9bbTHQIrSyNzHio yCH46DHcJrnPuno+zi8+J9nIVQjWrnXfwTOvw= Received: by 10.227.3.4 with SMTP id 4mr11432740wbl.35.1317278275243; Wed, 28 Sep 2011 23:37:55 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be. [94.225.167.75]) by mx.google.com with ESMTPS id gg18sm905369wbb.26.2011.09.28.23.37.53 (version=SSLv3 cipher=OTHER); Wed, 28 Sep 2011 23:37:53 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E841258.8030407@gnutls.org> Date: Thu, 29 Sep 2011 08:38:16 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 06:35:07 -0000 On 09/28/2011 10:10 PM, Nico Williams wrote: > A while back Dirk Balfanz proposed something he called "origin bound > certificates" and "channel bound cookies". A lighter-weight > alternative (i.e., involving no protocol changes) would be nice. > Mine: use TLS session IDs as the channel binding. [...] > Disadvantages: One additional disadvantage I see is that you lose perfect forward secrecy. The usage of resumption ensures that the same keys are re-used for the same peer again and again. regards, Nikos From n.mavrogiannopoulos@gmail.com Wed Sep 28 23:35:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1B21F8D56 for ; Wed, 28 Sep 2011 23:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l9B7wa2oTdj for ; Wed, 28 Sep 2011 23:35:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 237B321F8D52 for ; Wed, 28 Sep 2011 23:35:05 -0700 (PDT) Received: by wwf22 with SMTP id 22so336995wwf.13 for ; Wed, 28 Sep 2011 23:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e70sjpivVZqeHEbnbQENaFnkTRyNWduiwwwPrCecKnw=; b=o1GZ3+St8jFF/2T6Cd2krb14blxfdgMzOw4gRqelGP3OUVE/aGDTFMxaOhRZxmFm3U LWpU2UKHBwgEKBlXKuNOJMvB7IaCbc/qnx8BS60GL5IIa3w7WpOkF9TAzRL2MRTpv/nG oyg8PVlIdhK4+HPo04b7bdlq8/SdsdvL7L6eg= Received: by 10.227.11.149 with SMTP id t21mr2883765wbt.39.1317278274727; Wed, 28 Sep 2011 23:37:54 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be. [94.225.167.75]) by mx.google.com with ESMTPS id fy13sm917665wbb.18.2011.09.28.23.37.53 (version=SSLv3 cipher=OTHER); Wed, 28 Sep 2011 23:37:53 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E841253.9060605@gnutls.org> Date: Thu, 29 Sep 2011 08:38:11 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: mrex@sap.com References: <201109282257.p8SMv5P1019589@fs4113.wdf.sap.corp> In-Reply-To: <201109282257.p8SMv5P1019589@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 06:35:07 -0000 On 09/29/2011 12:57 AM, Martin Rex wrote: >> - Forward compatibility. How does a X-year old server that support TLS 1.2 >> understand that that new cipher suite code point is not some new cipher it >> does not support, but an indication that the client support TLS 1.5? The >> codepoints would have to not just be predictable, but the codepoints would >> also have to work for TLS NG using protocol version 4.1. How far ahead do >> we reserve codepoints, how much of the ciphersuite codepoint space will >> this eat up? Or do we assume that any TLS 1.2+ server is version and >> extension tolerant, so TLS 1.2 is the highest version we will ever need to >> assign a code point for? > I do _not_ want to retire the original TLS version negotiation, > just like to see an alternative "hinting" being standardized to > accomodate a ~10 year transition period to get over TLS version-related > interop problems that exist in today's installed base. For what reason? Since more and more people demand TLS 1.1 support more and more servers will make sure that they interoperate with it. Creating a new approach to negotiate versions might even create more interoperability problems. Why do you think implementers that got wrong the original simple negotiation will get right this one? regards, Nikos From fweimer@bfk.de Thu Sep 29 03:49:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960CA21F8C9A for ; Thu, 29 Sep 2011 03:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yQfZ5EygF3n for ; Thu, 29 Sep 2011 03:49:22 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0FD21F8C82 for ; Thu, 29 Sep 2011 03:49:20 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R9EDo-0004Wj-Mt; Thu, 29 Sep 2011 10:52:08 +0000 Received: by bfk.de with local id 1R9EDo-0000gd-Iy; Thu, 29 Sep 2011 10:52:08 +0000 From: Florian Weimer To: Nico Williams References: Date: Thu, 29 Sep 2011 10:52:08 +0000 In-Reply-To: (Nico Williams's message of "Wed, 28 Sep 2011 15:10:11 -0500") Message-ID: <82mxdny61z.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 10:49:26 -0000 * Nico Williams: > A while back Dirk Balfanz proposed something he called "origin bound > certificates" and "channel bound cookies". A lighter-weight > alternative (i.e., involving no protocol changes) would be nice. > Mine: use TLS session IDs as the channel binding. If we're interested in working around the cookie issue (as opposed to fixing the protocol issue), I think it would be simpler to include a random prefix in the cookie, ignored by the server, and the server would change the prefix every few requests. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mrex@sap.com Thu Sep 29 06:41:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E021F84AB for ; Thu, 29 Sep 2011 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnOXh0j6QhQe for ; Thu, 29 Sep 2011 06:41:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 20C9421F8D3C for ; Thu, 29 Sep 2011 06:41:44 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8TDiVdv012601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 15:44:31 +0200 (MEST) From: Martin Rex Message-Id: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 29 Sep 2011 15:44:31 +0200 (MEST) In-Reply-To: <4E77FAF6.90707@extendedsubset.com> from "Marsh Ray" at Sep 19, 11 09:31:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 13:41:50 -0000 Marsh Ray wrote: > > > - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0 > > is negotiated), and use RC4-128 instead. > > Does TLS's use of RC4 still take the first bytes after initialization > with the key? Or does it discard the proper amount? > > I believe there was a mitigation put in place by OpenSSL: sending an > empty (just padding) message before each app data message. The document > at eprint.iacr.org/2006/136 suggests that this could be a server-side > only change. I don't see how that would work since the session cookie > recovery attack is clearly happening on the client->server channel. > > I read somewhere that this mitigation was off by default in OpenSSL > because it some software (an old MSIE IIRC). Why using a EMPTY (just padding) SSL record? That looks like an obvious untested border case. How about using an initial SSL record with one byte of real data for SSLv3 and TLSv1.0 SSL with CBC cipher suites? Since the (H)MAC is using a secret MAC key and directly following the data (the CBC padding is at the end), there will be significant unknown distortion in the resulting plaintext to make the BEAST attack impractical, I assume. And it could be done immediately on the browser side, without having to wait for the Servers to implement TLSv1.1. -Martin From mrex@sap.com Thu Sep 29 06:48:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D5221F8C37 for ; Thu, 29 Sep 2011 06:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgTTSuO15nLR for ; Thu, 29 Sep 2011 06:48:30 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2721F8C1B for ; Thu, 29 Sep 2011 06:48:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8TDpDhS015584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 15:51:18 +0200 (MEST) From: Martin Rex Message-Id: <201109291351.p8TDpD1C009420@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 29 Sep 2011 15:51:13 +0200 (MEST) In-Reply-To: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 29, 11 03:44:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 13:48:34 -0000 Martin Rex wrote: > > Marsh Ray wrote: > > > > > - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0 > > > is negotiated), and use RC4-128 instead. > > > > Does TLS's use of RC4 still take the first bytes after initialization > > with the key? Or does it discard the proper amount? > > > > I believe there was a mitigation put in place by OpenSSL: sending an > > empty (just padding) message before each app data message. The document > > at eprint.iacr.org/2006/136 suggests that this could be a server-side > > only change. I don't see how that would work since the session cookie > > recovery attack is clearly happening on the client->server channel. > > > > I read somewhere that this mitigation was off by default in OpenSSL > > because it some software (an old MSIE IIRC). > > Why using a EMPTY (just padding) SSL record? That looks like an > obvious untested border case. > > How about using an initial SSL record with one byte of real data > for SSLv3 and TLSv1.0 SSL with CBC cipher suites? > > Since the (H)MAC is using a secret MAC key and directly following the > data (the CBC padding is at the end), there will be significant > unknown distortion in the resulting plaintext to make the BEAST > attack impractical, I assume. And it could be done immediately > on the browser side, without having to wait for the Servers > to implement TLSv1.1. But this fragmentation should be done ONLY on protected application data SSL records. Fragmenting SSL records with handshake messages (e.g. on TLS renegotiation) is likely to cause significant interop problems in the installed base. (Yes, I'm aware that fragmenting handshake records is allowed by the spec, but a significant number of implementations will break if you do). -Martin From yngve@opera.com Thu Sep 29 06:53:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7588121F8D0F for ; Thu, 29 Sep 2011 06:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oavP4YAq55i8 for ; Thu, 29 Sep 2011 06:52:58 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0921F8D1C for ; Thu, 29 Sep 2011 06:52:58 -0700 (PDT) Received: from lessa-ii.oslo.os (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 p8TDtfFg006909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Sep 2011 13:55:44 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Marsh Ray" , "Martin Rex" References: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> Date: Thu, 29 Sep 2011 15:55:49 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.62 (Win32) Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 13:53:02 -0000 On Thu, 29 Sep 2011 15:44:31 +0200, Martin Rex wrote: > Marsh Ray wrote: >> >> > - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0 >> > is negotiated), and use RC4-128 instead. >> >> Does TLS's use of RC4 still take the first bytes after initialization >> with the key? Or does it discard the proper amount? >> >> I believe there was a mitigation put in place by OpenSSL: sending an >> empty (just padding) message before each app data message. The document >> at eprint.iacr.org/2006/136 suggests that this could be a server-side >> only change. I don't see how that would work since the session cookie >> recovery attack is clearly happening on the client->server channel. >> >> I read somewhere that this mitigation was off by default in OpenSSL >> because it some software (an old MSIE IIRC). > > Why using a EMPTY (just padding) SSL record? That looks like an > obvious untested border case. > > How about using an initial SSL record with one byte of real data > for SSLv3 and TLSv1.0 SSL with CBC cipher suites? According to my testing, this breaks about as many websites, unfortunately, approximately 0.15% of tested websites. There is some uncertainty in the numbers, as I have observed sites that has been reported as breaking still work with the patched versions, whil others doesn't work. At present I do not why this is happening. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mrex@sap.com Thu Sep 29 07:10:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B7621F8DBB for ; Thu, 29 Sep 2011 07:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9aSNxLOvGmE for ; Thu, 29 Sep 2011 07:10:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03521F8DBA for ; Thu, 29 Sep 2011 07:10:15 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8TED4TQ020213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 16:13:04 +0200 (MEST) From: Martin Rex Message-Id: <201109291413.p8TED3rn010850@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 29 Sep 2011 16:13:03 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Sep 29, 11 03:55:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 14:10:35 -0000 Yngve N. Pettersen wrote: > > Martin Rex wrote: > > > Marsh Ray wrote: > > > > > > I believe there was a mitigation put in place by OpenSSL: sending an > > > empty (just padding) message before each app data message. > > > > > > I read somewhere that this mitigation was off by default in OpenSSL > > > because it [breaks] some software (an old MSIE IIRC). > > > > Why using a EMPTY (just padding) SSL record? That looks like an > > obvious untested border case. > > > > How about using an initial SSL record with one byte of real data > > for SSLv3 and TLSv1.0 SSL with CBC cipher suites? > > According to my testing, this breaks about as many websites, > unfortunately, approximately 0.15% of tested websites. What exactly did you do? did you fragment the client's finished handshake message as well (which is the first protected message on a TLS connnection) ? As previously mentioned, I would expect this to cause interop problems, whereas I have a slight hope that fragmenting only application data might work. -Martin From nico@cryptonector.com Thu Sep 29 07:22:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8781F21F8C51 for ; Thu, 29 Sep 2011 07:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch1IV+0lSiDp for ; Thu, 29 Sep 2011 07:22:35 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0127021F8C37 for ; Thu, 29 Sep 2011 07:22:34 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 4363650807F for ; Thu, 29 Sep 2011 07:25:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XvV3q+8RdzqJxSAV6sqPBItTJfxF8oJ9yfj2QSvBbJSc NO3IUoXBEHSkF62t2nyF3QIbeQIi6EtTYjy7pDh0aL55zSLWXTRkTmhd9LY4Qyws WXygh4ltboHQ8PQObenDeH2CstrDkmSJJPyN6kbCJK+Lu9woNpWkb1K634yiHqU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=9PNlrmPozoLMasqABpV3vqP1S/o=; b=gHsmoU+V716 5VO3N2te3ItdqD59PbCsVyQnemPKht9J42V4RYzPkohv1lC9ht+ZkWaaHl7qPNkH q/mw1KJmj8Lr+Lj2rZnIcDJmzSLNsOrYKASQEVSI8sIJKrVErRZu/uFWtwP9tzYV /lngRdjJdMInx13lVjaTbWG7YkpFcwZc= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 169DD50807C for ; Thu, 29 Sep 2011 07:25:21 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so737594vcb.31 for ; Thu, 29 Sep 2011 07:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.103 with SMTP id d7mr26048126pbm.24.1317306320117; Thu, 29 Sep 2011 07:25:20 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Thu, 29 Sep 2011 07:25:20 -0700 (PDT) In-Reply-To: <82mxdny61z.fsf@mid.bfk.de> References: <82mxdny61z.fsf@mid.bfk.de> Date: Thu, 29 Sep 2011 09:25:20 -0500 Message-ID: From: Nico Williams To: Florian Weimer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 14:22:35 -0000 On Thu, Sep 29, 2011 at 5:52 AM, Florian Weimer wrote: > * Nico Williams: > >> A while back Dirk Balfanz proposed something he called "origin bound >> certificates" and "channel bound cookies". =C2=A0A lighter-weight >> alternative (i.e., involving no protocol changes) would be nice. >> Mine: use TLS session IDs as the channel binding. > > If we're interested in working around the cookie issue (as opposed to > fixing the protocol issue), I think it would be simpler to include a > random prefix in the cookie, ignored by the server, and the server would > change the prefix every few requests. I don't see how that would stop BEAST. And, in any case, would require changes to clients and servers both, which makes it much harder to deploy. Nico -- From yngve@opera.com Thu Sep 29 07:31:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5221F8D0D for ; Thu, 29 Sep 2011 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CacE+DvIJxZe for ; Thu, 29 Sep 2011 07:31:36 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA921F8DB7 for ; Thu, 29 Sep 2011 07:31:35 -0700 (PDT) Received: from lessa-ii.oslo.os (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 p8TEYKm7016780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Sep 2011 14:34:23 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <201109291413.p8TED3rn010850@fs4113.wdf.sap.corp> Date: Thu, 29 Sep 2011 16:34:29 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <201109291413.p8TED3rn010850@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.62 (Win32) Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 14:31:37 -0000 On Thu, 29 Sep 2011 16:13:03 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> Martin Rex wrote: >> >> > Marsh Ray wrote: >> > > >> > > I believe there was a mitigation put in place by OpenSSL: sending an >> > > empty (just padding) message before each app data message. >> > > >> > > I read somewhere that this mitigation was off by default in OpenSSL >> > > because it [breaks] some software (an old MSIE IIRC). >> > >> > Why using a EMPTY (just padding) SSL record? That looks like an >> > obvious untested border case. >> > >> > How about using an initial SSL record with one byte of real data >> > for SSLv3 and TLSv1.0 SSL with CBC cipher suites? >> >> According to my testing, this breaks about as many websites, >> unfortunately, approximately 0.15% of tested websites. > > What exactly did you do? did you fragment the client's > finished handshake message as well (which is the first protected > message on a TLS connnection) ? As previously mentioned, I would > expect this to cause interop problems, whereas I have a slight > hope that fragmenting only application data might work. The test only used a split record for application data, and was only performed if the server supported on of the CBC ciphersuites supported by the prober, and a successful HTTP request for / without split record had been sent earlier in the test. Determining failure required detecting two successive failures that either did not return a response at all, or a 400+ error code that was not the same as was received in the baseline request. (200/300 was considered a success regardless ) Five different split policies were tested (0, 1, 2, blocksize-1, blocksize -2 bytes), each with or without having the blocks in the same TCP record. The above number was with the two records in the same TCP record (as that had a significantly lower failure rate). The above numbers is the combined failure rate for servers that support AES, or only support 3DES. (AES is presumed to be selected by these servers). I have previously seen HTTPS servers mishandle two HTTP requests in the same record (the second was ignored); my guess is that this is the same thing: An assumption that a single SSL/TLS Application record contain just a single, complete HTTPS request. My guess is that the responsible servers are front-ends, firewalls or similar, not servers like Apache with modSSL or IIS. At least one server return "ET is not a recognized HTTP method", apparently having dropped the record with the "G" part of the request. BTW: 0.045% failed all 5 of the tests, so I consider it likely that there is no split policy that will work for all servers. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mrex@sap.com Thu Sep 29 07:40:00 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B276621F8D34 for ; Thu, 29 Sep 2011 07:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.767 X-Spam-Level: X-Spam-Status: No, score=-9.767 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rus5gkTCH9N for ; Thu, 29 Sep 2011 07:40:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E075621F8D5B for ; Thu, 29 Sep 2011 07:39:59 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8TEglNJ010131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 16:42:47 +0200 (MEST) From: Martin Rex Message-Id: <201109291442.p8TEgkoY012556@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 29 Sep 2011 16:42:46 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Sep 29, 11 04:34:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: asteingruebl@paypal-inc.com, tls@ietf.org Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 14:40:00 -0000 Thank you for the detailed and very helpful information! I also believe that fragmenting application data is likely to break brittle application design that silently assumes application data boundaries (network read&writes, respectively SSL_read()&SSL_write()) will be preserved. So _not_ upsetting the peers TLS stack might not be a sufficient precondition to make a mitigation work. :-( -Martin Yngve N. Pettersen wrote: > > The test only used a split record for application data, and was only > performed if the server supported on of the CBC ciphersuites supported by > the prober, and a successful HTTP request for / without split record had > been sent earlier in the test. > > Determining failure required detecting two successive failures that either > did not return a response at all, or a 400+ error code that was not the > same as was received in the baseline request. (200/300 was considered a > success regardless ) > > Five different split policies were tested (0, 1, 2, blocksize-1, blocksize > -2 bytes), each with or without having the blocks in the same TCP record. > The above number was with the two records in the same TCP record (as that > had a significantly lower failure rate). > > The above numbers is the combined failure rate for servers that support > AES, or only support 3DES. (AES is presumed to be selected by these > servers). > > I have previously seen HTTPS servers mishandle two HTTP requests in the > same record (the second was ignored); my guess is that this is the same > thing: An assumption that a single SSL/TLS Application record contain just > a single, complete HTTPS request. My guess is that the responsible servers > are front-ends, firewalls or similar, not servers like Apache with modSSL > or IIS. > > At least one server return "ET is not a recognized HTTP method", > apparently having dropped the record with the "G" part of the request. > > BTW: 0.045% failed all 5 of the tests, so I consider it likely that there > is no split policy that will work for all servers. From mrex@sap.com Thu Sep 29 07:58:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF2C21F8D16 for ; Thu, 29 Sep 2011 07:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.067 X-Spam-Level: X-Spam-Status: No, score=-10.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl8BHqTyhj-I for ; Thu, 29 Sep 2011 07:58:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 544FE21F8C9B for ; Thu, 29 Sep 2011 07:58:00 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8TF0TRJ013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 17:00:34 +0200 (MEST) From: Martin Rex Message-Id: <201109291500.p8TF0Spb013525@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 29 Sep 2011 17:00:28 +0200 (MEST) In-Reply-To: <4E841253.9060605@gnutls.org> from "Nikos Mavrogiannopoulos" at Sep 29, 11 08:38:11 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] One approach to rollback protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 14:58:01 -0000 Nikos Mavrogiannopoulos wrote: > > Martin Rex wrote: > > > > I do _not_ want to retire the original TLS version negotiation, > > just like to see an alternative "hinting" being standardized to > > accomodate a ~10 year transition period to get over TLS version-related > > interop problems that exist in today's installed base. > > For what reason? Since more and more people demand TLS 1.1 support more > and more servers will make sure that they interoperate with it. More and more browsers support reconnect fallbacks for version-intolerant and extension-intolerant servers -- and since it is impossible to protect against attackers forcing that fallback, a browser implementing and offering TLSv1.1 is *NOT* a solution to the problem at all. Firefox added the reconnect fallback although it supports at most TLSv1.0 and only has to deal with the comparatively small extension-intolerant servers. As soon as browsers start sending TLSv1.1 or TLSv1.1 in ClientHello.client_version, they will be faces with the much more serious TLS version intolerance problem, in particular with respect to incorrect RSA premaster secret client_version checks. So for browsers -- the only clients that are affected by BEAST-style attacks besides SSL-VPNs, there currently is no robust protection available. > > Creating a new approach to negotiate versions might even create more > interoperability problems. Why do you think implementers that got wrong > the original simple negotiation will get right this one? Lack of testing (methodology). -Martin From ynir@checkpoint.com Thu Sep 29 11:07:00 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A039821F8C55 for ; Thu, 29 Sep 2011 11:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXvZnAO1iZkY for ; Thu, 29 Sep 2011 11:07:00 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE6721F8C53 for ; Thu, 29 Sep 2011 11:06:59 -0700 (PDT) X-CheckPoint: {4E84C172-C-1B221DC2-FFFF} 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 p8TI9koa013145; Thu, 29 Sep 2011 21:09:46 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 29 Sep 2011 21:09:46 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 29 Sep 2011 21:09:46 +0300 From: Yoav Nir To: "mrex@sap.com" Date: Thu, 29 Sep 2011 21:09:45 +0300 Thread-Topic: [TLS] Rizzo claims implementation attach, should be interesting Thread-Index: Acx+0vgW7LkOazg8SnKdAN23S1aWXg== Message-ID: <9D258076-EDEF-48EA-95A9-E5F44103E710@checkpoint.com> References: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> In-Reply-To: <201109291344.p8TDiVcw009197@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "asteingruebl@paypal-inc.com" , "tls@ietf.org" Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 18:07:00 -0000 On Sep 29, 2011, at 4:44 PM, Martin Rex wrote: >> I believe there was a mitigation put in place by OpenSSL: sending an=20 >> empty (just padding) message before each app data message. The document= =20 >> at eprint.iacr.org/2006/136 suggests that this could be a server-side=20 >> only change. I don't see how that would work since the session cookie=20 >> recovery attack is clearly happening on the client->server channel. >>=20 >> I read somewhere that this mitigation was off by default in OpenSSL=20 >> because it some software (an old MSIE IIRC). >=20 > Why using a EMPTY (just padding) SSL record? That looks like an > obvious untested border case. >=20 > How about using an initial SSL record with one byte of real data > for SSLv3 and TLSv1.0 SSL with CBC cipher suites? Interesting idea. http://src.chromium.org/viewvc/chrome?view=3Drev&revision=3D97269 From joshua.davies.tx@gmail.com Fri Sep 30 07:20:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB53D21F8AF5 for ; Fri, 30 Sep 2011 07:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mranPi-ct3A7 for ; Fri, 30 Sep 2011 07:20:04 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7F21F8AD1 for ; Fri, 30 Sep 2011 07:20:04 -0700 (PDT) Received: by pzk37 with SMTP id 37so4467282pzk.9 for ; Fri, 30 Sep 2011 07:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D2fQ66sXgGt1LL8LlpSMV+DwowyWL6UktxPQTOS1Hps=; b=RY49IHKbG2PE6kuLWMTNzsSn/h03H1mjMEfRtyKB296FMFdy1ewlYeuz6OSeYXtCcA rCL1xvcOZAFPqTn1QvmIDICug0Yj0oVWWyFvmwUX4gzeaqbK4NNTg3dtRW5K94CoLhOF +iCKPEnl7ZFRlFQl1DecQpsZH2RhawGEm52Qw= MIME-Version: 1.0 Received: by 10.68.7.166 with SMTP id k6mr44302439pba.128.1317392578311; Fri, 30 Sep 2011 07:22:58 -0700 (PDT) Received: by 10.142.88.9 with HTTP; Fri, 30 Sep 2011 07:22:58 -0700 (PDT) In-Reply-To: References: <4E818EF3.4090206@netscout.com> Date: Fri, 30 Sep 2011 09:22:58 -0500 Message-ID: From: Joshua Davies To: "Tayade, Nilesh" Content-Type: multipart/alternative; boundary=bcaec5215c81a8f7ca04ae295c86 Cc: tls@ietf.org Subject: Re: [TLS] Query regarding generating client_write_key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 14:20:05 -0000 --bcaec5215c81a8f7ca04ae295c86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On the contrary - the entire SSL handshake is sent in the clear - this is why its important that both sides keep a running digest of the entire handshake sequence and compare notes at the end, after encryption keys have been exchanged (see RFC 2246, 7.4.9). The first encrypted message in the handshake is the "finished" message. If you're using Wireshark/Ethereal to sniff packets, it will decode the protocol details for you - if you're usin= g a non-standard port (say, testing on 8443), you'll need to select analyze->decode as->SSL. On Thu, Sep 29, 2011 at 12:50 PM, Tayade, Nilesh wrote: > Thanks a lot Davies. The source code was a lot helpful.**** > > ** ** > > Also I have another query =96 while observing the https packets on wire, = I > could see besides the SYN, SYN-ACK, ACK rest all the packets are encrypte= d. > **** > > So after the socket is created (ACK from client is sent) =96 the client-h= ello > is sent from client side in case of TLS/SSL. But what is this message > encrypted using? The certificates aren=92t exchanged yet, so we don=92t k= now > server=92s keys.**** > > ** ** > > *From:* Joshua Davies [mailto:joshua.davies.tx@gmail.com] > *Sent:* Wednesday, September 28, 2011 10:03 PM > *To:* Tayade, Nilesh > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Query regarding generating client_write_key.**** > > ** ** > > Are you implementing TLS 1.0/1.1 or TLS 1.2? The PRF changed in 1.2.**** > > ** ** > > The PRF is by far the most complex part of the implementation - if you > really want to understand it, I'd recommend chapter 6 of my book ; ) > However, you can download the companion source code for free from > http://media.wiley.com/product_ancillary/16/04709204/DOWNLOAD/920411%20im= plementing_ssl_gcc.zip; > take a look at the ch06/prf.c file. It was written to be as straightforw= ard > and self contained as possible, and it includes a standalone main routine > that you can use to pass in arbitrary secrets/seeds/labels and see exactl= y > what the PRF function generates.**** > > ** ** > > On Tue, Sep 27, 2011 at 3:53 AM, nilesh > wrote:**** > > Hi, > > I am new to the TLS/Cryptography and started working on decrypting the > packets over SSL/TLS. > I have followed the RFC2246, 5246. > > To start decoding the packets, I need to have symmetric keys > (client_write_key/server_write_key). > I have the key_block, IV and MAC. As per the rfc: > > client_write_key =3D PRF{key_block[32..36], client_random, server_random, > some_string}[0..31]; > And I have started writing PRF (pseudo-random function) somewhat like: > > > /* > input : has 5bytes data i.e. key_block[32..36]; > salt1 =3D=3D client_random, salt2 =3D=3D server_random, salt =3D 'A'. > */ > for (i =3D 0; i < 2; i++) > { > MD5_Init(&md5); > MD5_Update(&md5, (unsigned char *) &input[0], 3); > // MD5_Update(&md5, shasig, 20); > MD5_Final((unsigned char *)&md, &md5); > > SHA1_Init(&sha); > SHA1_Update(&sha, pad, i + 1); > SHA1_Update(&sha, (unsigned char *) &input[2], 3); > SHA1_Update(&sha, salt1, 32); > SHA1_Update(&sha, salt2, 32); > SHA1_Final(shasig, &sha); > } > > > Now, we need to XOR the md and shasig to get the bytes in client_write_ke= y. > > Queries: > 1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be > 20bytes. > But the key we expect should be 32bytes (iterated the MD5/SHA1 twice for > that). How could this be achieved? > 2. Any suggestions on if the PRF() is designed somewhere? Pointers on how > it could be designed? > > I tried several ways, but getting the wrong key. Could someone please > advice? > > -- > Thanks, > Nilesh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls**** > > ** ** > --bcaec5215c81a8f7ca04ae295c86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On the contrary - the entire SSL handshake is sent in the clear - this is w= hy its important that both sides keep a running digest of the entire handsh= ake sequence and compare notes at the end, after encryption keys have been = exchanged (see RFC 2246, 7.4.9). =A0The first encrypted message in the hand= shake is the "finished" message. =A0If you're using Wireshark= /Ethereal to sniff packets, it will decode the protocol details for you - i= f you're using a non-standard port (say, testing on 8443), you'll n= eed to select analyze->decode as->SSL.

On Thu, Sep 29, 2011 at 12:50 PM, Tayade, Ni= lesh <Ni= lesh.Tayade@netscout.com> wrote:

Thanks a lot Davies. The= source code was a lot helpful.

=A0=

Also = I have another query =96 while observing the https packets on wire, I could= see besides the SYN, SYN-ACK, ACK rest all the packets are encrypted.

So af= ter the socket is created (ACK from client is sent) =96 the client-hello is= sent from client side in case of TLS/SSL. But what is this message encrypt= ed using? The certificates aren=92t exchanged yet, so we don=92t know serve= r=92s keys.

=A0

From:= Joshua Davies [mailto:joshua.davies.tx@gmail.com= ]
Sent: Wednesday, September 28, 2011 10:03 PM
To: Tayade, N= ilesh
Cc: tls@i= etf.org
Subject: Re: [TLS] Query regarding generating client_= write_key.

=A0

Are you implementing TLS 1.0/1.1 or T= LS 1.2? =A0The PRF changed in 1.2.

=A0

The PRF is by far the most complex part o= f the implementation - if you really want to understand it, I'd recomme= nd chapter 6 of my book ; ) =A0However, you can download the companion sour= ce code for free from=A0= http://media.wiley.com/product_ancillary/16/04709204/DOWNLOAD/920411%20impl= ementing_ssl_gcc.zip; take a look at the ch06/prf.c file. =A0It was wri= tten to be as straightforward and self contained as possible, and it includ= es a standalone main routine that you can use to pass in arbitrary secrets/= seeds/labels and see exactly what the PRF function generates.=

=A0

On Tue, Sep 27, 2011 at 3:53 AM, nilesh <nilesh.tayade@netscout.com>= wrote:

Hi,

I am new to the TLS/Cryptography and star= ted working on decrypting the packets over SSL/TLS.
I have followed the = RFC2246, 5246.

To start decoding the packets, I need to have symmetr= ic keys (client_write_key/server_write_key).
I have the key_block, IV and MAC. As per the rfc:

client_write_key = =3D PRF{key_block[32..36], client_random, server_random, some_string}[0..31= ];
And I have started writing PRF (pseudo-random function) somewhat like= :

<snip>
/*
=A0input : has 5bytes data i.e. key_block[32..36]= ;
=A0salt1 =3D=3D client_random, salt2 =3D=3D server_random, salt =3D &#= 39;A'.
*/
for (i =3D 0; i < 2; i++)
{
=A0 =A0 =A0 =A0MD5= _Init(&md5);
=A0 =A0 =A0 =A0MD5_Update(&md5, (unsigned char *) &input[0], 3);=A0 =A0 =A0 =A0// MD5_Update(&md5, shasig, 20);
=A0 =A0 =A0 =A0MD5_= Final((unsigned char *)&md, &md5);
=A0 =A0 =A0 =A0
=A0 =A0 = =A0 =A0SHA1_Init(&sha);
=A0 =A0 =A0 =A0SHA1_Update(&sha, pad, i = + 1);
=A0 =A0 =A0 =A0SHA1_Update(&sha, (unsigned char *) &input[2], 3);=A0 =A0 =A0 =A0SHA1_Update(&sha, salt1, 32);
=A0 =A0 =A0 =A0SHA1_U= pdate(&sha, salt2, 32);
=A0 =A0 =A0 =A0SHA1_Final(shasig, &sha);=
}
</snip>

Now, we need to XOR the md and shasig to get the bytes in client_write_key.=

Queries:
1. The md5 generates 16bytes and SHA1 generates 20bytes= so xor will be 20bytes.
But the key we expect should be 32bytes (iterat= ed the MD5/SHA1 twice for that). How could this be achieved?
2. Any suggestions on if the PRF() is designed somewhere? Pointers on how i= t could be designed?

I tried several ways, but getting the wrong key= . Could someone please advice?

--
Thanks,
Nilesh
_______________________________________________
TLS= mailing list
TLS@ietf= .org
https://www.ietf.org/mailman/listinfo/tls=

=A0

<= /div>

--bcaec5215c81a8f7ca04ae295c86--